「OpenSSH」の版間の差分
細 |
|||
12行目: | 12行目: | ||
[[sr:Secure Shell]] |
[[sr:Secure Shell]] |
||
[[zh-CN:Secure Shell]] |
[[zh-CN:Secure Shell]] |
||
− | {{Related articles start |
+ | {{Related articles start}} |
{{Related|SSH keys}} |
{{Related|SSH keys}} |
||
{{Related|Pam abl}} |
{{Related|Pam abl}} |
||
35行目: | 35行目: | ||
=== OpenSSH のインストール === |
=== OpenSSH のインストール === |
||
− | [[official Repositories |
+ | [[official Repositories|公式リポジトリ]]から {{Pkg|openssh}} を[[pacman|インストール]]してください。 |
=== SSH の設定 === |
=== SSH の設定 === |
||
70行目: | 70行目: | ||
# systemctl enable sshd.service |
# systemctl enable sshd.service |
||
− | 詳しくは [[systemd |
+ | 詳しくは [[systemd#ユニットを使う|systemd#ユニットを使う]] を見て下さい。 |
− | {{Warning|Systemd は非同期にプロセスを実行します。SSH デーモンを特定の IP アドレス {{ic|ListenAddress 192.168.1.100}} に結びつけている場合、デフォルトの sshd.service ユニットファイルはネットワークインターフェイスが有効にされることに依存していないため、ブート中にロードが失敗する可能性があります。IP アドレスをバインドする時は、カスタムした sshd.service ユニットファイルに {{ic|1=After=network.target}} を追加してください。[[Systemd |
+ | {{Warning|Systemd は非同期にプロセスを実行します。SSH デーモンを特定の IP アドレス {{ic|ListenAddress 192.168.1.100}} に結びつけている場合、デフォルトの sshd.service ユニットファイルはネットワークインターフェイスが有効にされることに依存していないため、ブート中にロードが失敗する可能性があります。IP アドレスをバインドする時は、カスタムした sshd.service ユニットファイルに {{ic|1=After=network.target}} を追加してください。[[Systemd#ユニットファイルの編集|systemd#ユニットファイルの編集]] を参照。}} |
また SSH デーモンソケットを有効にすることで初めて接続があったときにデーモンが起動するようにすることもできます: |
また SSH デーモンソケットを有効にすることで初めて接続があったときにデーモンが起動するようにすることもできます: |
||
91行目: | 91行目: | ||
* わかりにくいアカウント名やパスワードを使う |
* わかりにくいアカウント名やパスワードを使う |
||
* 信頼できる国からの SSH 接続だけを許可する |
* 信頼できる国からの SSH 接続だけを許可する |
||
− | * [[fail2ban |
+ | * [[fail2ban|fail2ban]] や [[sshguard|sshguard]] をつかってブルートフォース攻撃を監視し、総当りを起こっている IP を閉め出す |
===== ブルートフォースアタックからの保護 ===== |
===== ブルートフォースアタックからの保護 ===== |
||
− | ブルートフォースは単純な攻撃方法です: ランダムなユーザー名とパスワードの組み合わせをとにかく沢山作ってウェブページや SSH などのサーバーログインプロンプトにログインを絶えず試行します。ブルートフォース攻撃からは [[fail2ban |
+ | ブルートフォースは単純な攻撃方法です: ランダムなユーザー名とパスワードの組み合わせをとにかく沢山作ってウェブページや SSH などのサーバーログインプロンプトにログインを絶えず試行します。ブルートフォース攻撃からは [[fail2ban|fail2ban]] や [[sshguard|sshguard]] などの自動スクリプトを使うことで攻撃者をブロックすることで身を守ることができます。 |
もしくは、公開鍵認証を使うことでブルートフォース攻撃を出来なくすることもできます。{{ic|sshd_config}} に次の設定を追加: |
もしくは、公開鍵認証を使うことでブルートフォース攻撃を出来なくすることもできます。{{ic|sshd_config}} に次の設定を追加: |
||
118行目: | 118行目: | ||
# systemctl restart sshd |
# systemctl restart sshd |
||
− | これで root で SSH を使ってログインすることはできなくなります。ただし、通常ユーザーでログインしてから [[su |
+ | これで root で SSH を使ってログインすることはできなくなります。ただし、通常ユーザーでログインしてから [[su|su]] や [[sudo|sudo]] を使ってシステム管理を行うことは依然として可能です。 |
===== root ログインを禁止する ===== |
===== root ログインを禁止する ===== |
||
150行目: | 150行目: | ||
Remote terminal application that allows roaming, supports intermittent connectivity, and provides intelligent local echo and line editing of user keystrokes. Mosh is a replacement for SSH. It's more robust and responsive, especially over Wi-Fi, cellular, and long-distance links. |
Remote terminal application that allows roaming, supports intermittent connectivity, and provides intelligent local echo and line editing of user keystrokes. Mosh is a replacement for SSH. It's more robust and responsive, especially over Wi-Fi, cellular, and long-distance links. |
||
− | [[official Repositories |
+ | [[official Repositories|公式リポジトリ]]から {{Pkg|mosh}} を[[pacman|インストール]]するか [[Arch User Repository|AUR]] にある最新版 {{AUR|mosh-git}} を使って下さい。 |
== Tips and tricks == |
== Tips and tricks == |
||
211行目: | 211行目: | ||
**{{ic|AllowTcpForwarding}} と {{ic|X11UseLocalhost}} オプションを ''yes'' に設定し、{{ic|X11DisplayOffset}} を ''10'' に設定 (何も変更を加えてなければこの値がデフォルトになっています、{{ic|man sshd_config}} を参照) |
**{{ic|AllowTcpForwarding}} と {{ic|X11UseLocalhost}} オプションを ''yes'' に設定し、{{ic|X11DisplayOffset}} を ''10'' に設定 (何も変更を加えてなければこの値がデフォルトになっています、{{ic|man sshd_config}} を参照) |
||
**{{ic|X11Forwarding}} を ''yes'' に設定 |
**{{ic|X11Forwarding}} を ''yes'' に設定 |
||
− | * [[#sshd デーモンの管理|''sshd'' デーモン]]を[[Systemd |
+ | * [[#sshd デーモンの管理|''sshd'' デーモン]]を[[Systemd#ユニットを使う|再起動]] |
クライアント側では、接続するたびにコマンドラインで {{ic|-X}} スイッチを指定して {{ic|ForwardX11}} オプションを有効にするか、[[#クライアント|openSSH クライアントの設定ファイル]]で {{ic|ForwardX11}} を ''yes'' に設定してください。 |
クライアント側では、接続するたびにコマンドラインで {{ic|-X}} スイッチを指定して {{ic|ForwardX11}} オプションを有効にするか、[[#クライアント|openSSH クライアントの設定ファイル]]で {{ic|ForwardX11}} を ''yes'' に設定してください。 |
||
234行目: | 234行目: | ||
where hostname is the name of the particular host you want to forward to. See {{ic|man xhost}} for more details. |
where hostname is the name of the particular host you want to forward to. See {{ic|man xhost}} for more details. |
||
− | Be careful with some applications as they check for a running instance on the local machine. [[Firefox |
+ | Be careful with some applications as they check for a running instance on the local machine. [[Firefox|Firefox]] is an example: either close the running Firefox instance or use the following start parameter to start a remote instance on the local machine: |
$ firefox -no-remote |
$ firefox -no-remote |
||
352行目: | 352行目: | ||
[[sshfs]] を組み合わせる: |
[[sshfs]] を組み合わせる: |
||
$ sshfs -o reconnect,compression=yes,transform_symlinks,ServerAliveInterval=45,ServerAliveCountMax=2,ssh_command='autossh -M 0' username@example.com: /mnt/example |
$ sshfs -o reconnect,compression=yes,transform_symlinks,ServerAliveInterval=45,ServerAliveCountMax=2,ssh_command='autossh -M 0' username@example.com: /mnt/example |
||
− | [[Proxy settings |
+ | [[Proxy settings|プロキシ設定]]で設定した SOCKS プロクシを使って接続: |
$ autossh -M 0 -o "ServerAliveInterval 45" -o "ServerAliveCountMax 2" -NCD 8080 username@example.com |
$ autossh -M 0 -o "ServerAliveInterval 45" -o "ServerAliveCountMax 2" -NCD 8080 username@example.com |
||
With the {{ic|-f}} option autossh can be made to run as a background process. Running it this way however means the passprase cannot be entered interactively. |
With the {{ic|-f}} option autossh can be made to run as a background process. Running it this way however means the passprase cannot be entered interactively. |
||
456行目: | 456行目: | ||
==== 接続をブロックするようなファイアウォールのルールが存在しないか? ==== |
==== 接続をブロックするようなファイアウォールのルールが存在しないか? ==== |
||
− | [[iptables |
+ | [[iptables|Iptables]] によってポート {{ic|22}} の接続がブロックされている可能性があります。次のコマンドで確認してください: |
{{bc|# iptables -nvL}} |
{{bc|# iptables -nvL}} |
||
{{ic|INPUT}} チェインのパケットを拒否するようなルールがないか見て下さい。そして、必要であれば、次のようなコマンドでポートのブロックを解除します: |
{{ic|INPUT}} チェインのパケットを拒否するようなルールがないか見て下さい。そして、必要であれば、次のようなコマンドでポートのブロックを解除します: |
||
462行目: | 462行目: | ||
# iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT |
# iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT |
||
}} |
}} |
||
− | ファイアウォールの設定に関する詳細は[[firewalls |
+ | ファイアウォールの設定に関する詳細は[[firewalls|ファイアウォール]]を見て下さい。 |
==== Is the traffic even getting to your computer? ==== |
==== Is the traffic even getting to your computer? ==== |
2015年1月14日 (水) 14:10時点における版
Secure Shell (SSH) は暗号技術を利用して、安全にリモートコンピュータと通信するためのネットワークプロトコルです。暗号によってデータの機密性と完全性が保証されます。SSH は公開鍵暗号を使ってリモートコンピュータを認証し、リモートコンピュータは必要に応じてユーザーを認証します。
基本的に SSH はリモートマシンにログインしてコマンドを実行するために使われますが、トンネリングや TCP ポートや X11 接続の任意のフォワーディングをサポートしており、SFTP や SCP プロトコルを使うことでファイル転送をすることも可能です。
デフォルトでは、SSH サーバーは標準の TCP 22番ポートを使います。通常は SSH クライアントプロトコルを使って sshd デーモンの接続を確立してリモート接続を承認します。Mac OS X, GNU/Linux, Solaris, OpenVMS など近代的なオペレーティングシステムのほとんどでサーバーとクライアントの両方が備わってします。複雑なもの・完全なものまで様々なレベルのバージョンがプロプライエタリ・フリーウェア・オープンソースを問わずに存在します。
(ソース: Wikipedia:ja:Secure Shell)
目次
- 1 OpenSSH
- 2 他の SSH クライアントとサーバー
- 3 Tips and tricks
- 4 ソケットアクティベーションで SSH ポート番号を変更する (sshd.socket)
- 5 トラブルシューティング
- 5.1 チェックリスト
- 5.2 電源オフ/再起動した後も SSH 接続が残ってしまう
- 5.3 接続が拒否されるまたはタイムアウトする
- 5.4 "[your shell]: No such file or directory" / ssh_exchange_identification problem
- 5.5 "Terminal unknown" や "Error opening terminal" エラーメッセージ
- 6 参照
OpenSSH
OpenSSH (OpenBSD Secure Shell) は ssh プロトコルを使ってコンピューターネットワークを介して暗号化通信セッションを提供するコンピュータープログラムのセットです。SSH Communications Security によるプロプライエタリの Secure Shell ソフトウェアスイートに代わるオープンのプログラムとして作成されました。OpenSSH は Theo de Raadt に率いられている OpenBSD プロジェクトの一環として開発されています。
同じような名前の OpenSSL と OpenSSH が混同されることがときどきありますが、プロジェクトの目的・開発チームは異なります。
OpenSSH のインストール
公式リポジトリから openssh をインストールしてください。
SSH の設定
クライアント
SSH クライアントの設定ファイルは /etc/ssh/ssh_config
もしくは ~/.ssh/config
です。
Protocol 2
を明示的に設定する必要はありません。デフォルトの設定ファイルではコメントアウトされています。つまり明示的に有効にされない限り Protocol 1
は使われません。 (ソース: http://www.openssh.org/txt/release-5.4)
デーモン
SSH デーモンの設定ファイルは /etc/ssh/sshd_config
です。
特定のユーザーにだけアクセスを許可するには次の行を追加してください:
AllowUsers user1 user2
特定のグループにだけアクセスを許可するには:
AllowGroups group1 group2
SSH による root ログインを無効にするには、PermitRootLogin 行を次のように変更してください:
PermitRootLogin no
ウェルカムメッセージを追加するには /etc/issue
ファイルを編集して Banner 行を次のように変更してください:
Banner /etc/issue
sshd デーモンの管理
次のコマンドで sshd デーモンを起動することができます:
# systemctl start sshd.service
次のコマンドで ssdh デーモンを起動時に有効にすることができます:
# systemctl enable sshd.service
詳しくは systemd#ユニットを使う を見て下さい。
また SSH デーモンソケットを有効にすることで初めて接続があったときにデーモンが起動するようにすることもできます:
# systemctl start sshd.socket # systemctl enable sshd.socket
デフォルトの22番以外のポートを使う場合、ユニットファイルの "ListenStream" を設定する必要があります。/lib/systemd/system/sshd.socket
を /etc/systemd/system/sshd.socket
にコピーして、アップグレードでユニットファイルが上書きされないようにしてください。/etc/systemd/system/sshd.socket
を編集して "ListenStream" を適当なポートに変更します。
サーバーに接続する
サーバーに接続するには、次を実行してください:
$ ssh -p port user@server-address
SSH の保護
管理業務のために SSH によるリモートログインを許可することは良いことですが、サーバーのセキュリティに脅威を及ぼすことにもなりえます。総当り攻撃の標的になりやすいので、SSH のアクセスは制限して、第三者がサーバーにアクセスできないようにする必要があります。
- わかりにくいアカウント名やパスワードを使う
- 信頼できる国からの SSH 接続だけを許可する
- fail2ban や sshguard をつかってブルートフォース攻撃を監視し、総当りを起こっている IP を閉め出す
ブルートフォースアタックからの保護
ブルートフォースは単純な攻撃方法です: ランダムなユーザー名とパスワードの組み合わせをとにかく沢山作ってウェブページや SSH などのサーバーログインプロンプトにログインを絶えず試行します。ブルートフォース攻撃からは fail2ban や sshguard などの自動スクリプトを使うことで攻撃者をブロックすることで身を守ることができます。
もしくは、公開鍵認証を使うことでブルートフォース攻撃を出来なくすることもできます。sshd_config
に次の設定を追加:
PasswordAuthentication no
上の設定を適用する前に、SSH アクセスが必要な全てのアカウントで authorized_keys
ファイルに公開鍵認証の設定をするようにしてください。
root ログインを制限する
It is generally considered bad practice to allow the root user to log in without restraint over SSH. There are two methods by which SSH root access can be restricted for increased security.
root ログインを拒否する
Sudo selectively provides root rights for actions requiring these without requiring authenticating against the root account. This allows locking the root account against access via SSH and potentially functions as a security measure agaist brute force attacks, since now an attacker must guess the account name in additition to the password.
SSH can be configured to deny remote logins with the root user by editing the "Authentication" section in /etc/ssh/sshd_config
. Simply change #PermitRootLogin yes
to no
and uncomment the line:
/etc/ssh/sshd_config
PermitRootLogin no ...
次に、SSH デーモンを再起動:
# systemctl restart sshd
これで root で SSH を使ってログインすることはできなくなります。ただし、通常ユーザーでログインしてから su や sudo を使ってシステム管理を行うことは依然として可能です。
root ログインを禁止する
Some automated tasks such as remote, full-system backup require full root access. To allow these in a secure way, instead of disabling root login via SSH, it is possible to only allow root logins for selected commands. This can be achieved by editing ~root/.ssh/authorized_keys
, by prefixing the desired key, e.g. as follows:
command="/usr/lib/rsync/rrsync -ro /" ssh-rsa …
This will allow any login with this specific key only to execute the command specified between the quotes.
The increased attack surface created by exposing the root user name at login can be compensated by adding the following to sshd_config
:
PermitRootLogin forced-commands-only
This setting will not only restrict the commands which root may execute via SSH, but it will also disable the use of passwords, forcing use of public key authentication for the root account.
A slightly less restrictive alternative will allow any command for root, but makes brute force attacks infeasible by enforcing public key authentication. For this option, set:
PermitRootLogin without-password
他の SSH クライアントとサーバー
OpenSSH の他にも、多数の SSH クライアント とサーバー が存在します。
Dropbear
Dropbear は SSH-2 クライアント・サーバーです。dropbear は公式リポジトリから利用可能です。
コマンドラインの ssh クライアントは dbclient という名前が付けられています。
SSH 代替: Mobile Shell - responsive, survives disconnects
Mosh の ウェブサイト より:
Remote terminal application that allows roaming, supports intermittent connectivity, and provides intelligent local echo and line editing of user keystrokes. Mosh is a replacement for SSH. It's more robust and responsive, especially over Wi-Fi, cellular, and long-distance links.
公式リポジトリから mosh をインストールするか AUR にある最新版 mosh-gitAUR を使って下さい。
Tips and tricks
暗号化 SOCKS トンネル
This is highly useful for laptop users connected to various unsafe wireless connections. The only thing you need is an SSH server running at a somewhat secure location, like your home or at work. It might be useful to use a dynamic DNS service like DynDNS so you do not have to remember your IP-address.
手順 1: 接続の開始
You only have to execute this single command to start the connection:
$ ssh -TND 4711 user@host
where user
is your username at the SSH server running at the host
. It will ask for your password, and then you are connected! The N
flag disables the interactive prompt, and the D
flag specifies the local port on which to listen on (you can choose any port number if you want). The T
flag disables pseudo-tty allocation.
It is nice to add the verbose (-v
) flag, because then you can verify that it is actually connected from that output.
手順 2: ブラウザ (やその他のプログラム) の設定
The above step is completely useless if you do not configure your web browser (or other programs) to use this newly created socks tunnel. Since the current version of SSH supports both SOCKS4 and SOCKS5, you can use either of them.
- For Firefox: Edit → Preferences → Advanced → Network → Connection → Setting:
- Check the Manual proxy configuration radio button, and enter
localhost
in the SOCKS host text field, and then enter your port number in the next text field (4711
in the example above).
Firefox does not automatically make DNS requests through the socks tunnel. This potential privacy concern can be mitigated by the following steps:
- Type about:config into the Firefox location bar.
- Search for network.proxy.socks_remote_dns
- Set the value to true.
- Restart the browser.
- For Chromium: You can set the SOCKS settings as environment variables or as command line options. I recommend to add one of the following functions to your
.bashrc
:
function secure_chromium { port=4711 export SOCKS_SERVER=localhost:$port export SOCKS_VERSION=5 chromium & exit }
OR
function secure_chromium { port=4711 chromium --proxy-server="socks://localhost:$port" & exit }
Now open a terminal and just do:
$ secure_chromium
Enjoy your secure tunnel!
X11 フォワーディング
X11 forwarding is a mechanism that allows graphical interfaces of X11 programs running on a remote system to be displayed on a local client machine. For X11 forwarding the remote host doesn't need to have a full X11 system installed, however it needs at least to have xauth installed. xauth is a utility that maintains Xauthority
configurations used by server and client for authentication of X11 session (source).
セットアップ
リモート側:
- 公式リポジトリから xorg-xauth と xorg-xhost をインストール
/etc/ssh/sshd_config
内:AllowTcpForwarding
とX11UseLocalhost
オプションを yes に設定し、X11DisplayOffset
を 10 に設定 (何も変更を加えてなければこの値がデフォルトになっています、man sshd_config
を参照)X11Forwarding
を yes に設定
- sshd デーモンを再起動
クライアント側では、接続するたびにコマンドラインで -X
スイッチを指定して ForwardX11
オプションを有効にするか、openSSH クライアントの設定ファイルで ForwardX11
を yes に設定してください。
使用方法
通常通りリモートマシンにログインします、クライアント側の設定ファイルで ForwardX11 を有効にしていない場合は -X
スイッチを指定します:
$ ssh -X user@host
グラフィカルなアプリケーションを実行しようとするとエラーが表示される場合、代わりに ForwardX11Trusted を試してみて下さい:
$ ssh -Y user@host
リモートサーバーで X プログラムが起動できるようになったら、出力がローカルセッションに転送されます:
$ xclock
If you get "Cannot open display" errors try the following command as the non root user:
$ xhost +
The above command will allow anybody to forward X11 applications. To restrict forwarding to a particular host type:
$ xhost +hostname
where hostname is the name of the particular host you want to forward to. See man xhost
for more details.
Be careful with some applications as they check for a running instance on the local machine. Firefox is an example: either close the running Firefox instance or use the following start parameter to start a remote instance on the local machine:
$ firefox -no-remote
If you get "X11 forwarding request failed on channel 0" when you connect (and the server /var/log/errors.log
shows "Failed to allocate internet-domain X11 display socket"), make sure package xorg-xauth is installed. If its installation is not working, try to either:
- enable the
AddressFamily any
option insshd_config
on the server, or - set the
AddressFamily
option insshd_config
on the server to inet.
Setting it to inet may fix problems with Ubuntu clients on IPv4.
For running X applications as other user on the SSH server you need to xauth add
the authentication line taken from xauth list
of the SSH logged in user.
他のポートのフォワーディング
In addition to SSH's built-in support for X11, it can also be used to securely tunnel any TCP connection, by use of local forwarding or remote forwarding.
Local forwarding opens a port on the local machine, connections to which will be forwarded to the remote host and from there on to a given destination. Very often, the forwarding destination will be the same as the remote host, thus providing a secure shell and, e.g. a secure VNC connection, to the same machine. Local forwarding is accomplished by means of the -L
switch and it's accompanying forwarding specification in the form of <tunnel port>:<destination address>:<destination port>
.
Thus:
$ ssh -L 1000:mail.google.com:25 192.168.0.100
will use SSH to login to and open a shell on 192.168.0.100, and will also create a tunnel from the local machine's TCP port 1000 to mail.google.com on port 25. Once established, connections to localhost:1000 will connect to the Gmail SMTP port. To Google, it will appear that any such connection (though not necessarily the data conveyed over the connection) originated from 192.168.0.100, and such data will be secure as between the local machine and 192.168.0.100, but not between 192.168.0.100, unless other measures are taken.
Similarly:
$ ssh -L 2000:192.168.0.100:6001 192.168.0.100
will allow connections to localhost:2000 which will be transparently sent to the remote host on port 6001. The preceding example is useful for VNC connections using the vncserver utility--part of the tightvnc package--which, though very useful, is explicit about its lack of security.
Remote forwarding allows the remote host to connect to an arbitrary host via the SSH tunnel and the local machine, providing a functional reversal of local forwarding, and is useful for situations where, e.g., the remote host has limited connectivity due to firewalling. It is enabled with the -R
switch and a forwarding specification in the form of <tunnel port>:<destination address>:<destination port>
.
Thus:
$ ssh -R 3000:irc.freenode.net:6667 192.168.0.200
will bring up a shell on 192.168.0.200, and connections from 192.168.0.200 to itself on port 3000 (remotely speaking, localhost:3000) will be sent over the tunnel to the local machine and then on to irc.freenode.net on port 6667, thus, in this example, allowing the use of IRC programs on the remote host to be used, even if port 6667 would normally be blocked to it.
Both local and remote forwarding can be used to provide a secure "gateway," allowing other computers to take advantage of an SSH tunnel, without actually running SSH or the SSH daemon by providing a bind-address for the start of the tunnel as part of the forwarding specification, e.g. <tunnel address>:<tunnel port>:<destination address>:<destination port>
. The <tunnel address>
can be any address on the machine at the start of the tunnel, localhost
, *
(or blank), which, respectively, allow connections via the given address, via the loopback interface, or via any interface. By default, forwarding is limited to connections from the machine at the "beginning" of the tunnel, i.e. the <tunnel address>
is set to localhost
. Local forwarding requires no additional configuration, however remote forwarding is limited by the remote server's SSH daemon configuration. See the GatewayPorts
option in sshd_config(5)
for more information.
マルチプレクス
The SSH daemon usually listens on port 22. However, it is common practice for many public internet hotspots to block all traffic that is not on the regular HTTP/S ports (80 and 443, respectively), thus effectively blocking SSH connections. The immediate solution for this is to have sshd
listen additionally on one of the whitelisted ports:
/etc/ssh/sshd_config
Port 22 Port 443
However, it is likely that port 443 is already in use by a web server serving HTTPS content, in which case it is possible to use a multiplexer, such as sslh, which listens on the multiplexed port and can intelligently forward packets to many services.
SSH の高速化
You can make all sessions to the same host use a single connection, which will greatly speed up subsequent logins, by adding these lines under the proper host in /etc/ssh/ssh_config
:
Host examplehost.com ControlMaster auto ControlPersist yes ControlPath ~/.ssh/socket-%r@%h:%p
See the ssh_config(5)
manual page for full description of these options.
Another option to improve speed is to enable compression with the -C
flag. A permanent solution is to add this line under the proper host in /etc/ssh/ssh_config
:
Compression yes
Login time can be shortened by using the -4
flag, which bypasses IPv6 lookup. This can be made permanent by adding this line under the proper host in /etc/ssh/ssh_config
:
AddressFamily inet
Changing the ciphers used by SSH to less cpu-demanding ones can improve speed. In this respect, the best choices are arcfour and blowfish-cbc.
To use alternative ciphers, run SSH with the -c
flag:
$ ssh -c arcfour,blowfish-cbc user@server-address
To use them permanently, add this line under the proper host in /etc/ssh/ssh_config
:
Ciphers arcfour,blowfish-cbc
SSHFS でリモートファイルシステムをマウントする
Please refer to the Sshfs article to use sshfs to mount a remote system - accessible via SSH - to a local folder, so you will be able to do any operation on the mounted files with any tool (copy, rename, edit with vim, etc.). Using sshfs instead of shfs is generally preferred as a new version of shfs hasn't been released since 2004.
Keep alive
一定時間操作がないと ssh セッションは自動的にログアウトします。接続を維持するには以下をクライアントの ~/.ssh/config
か /etc/ssh/ssh_config
に追加してください:
ServerAliveInterval 120
これで120秒ごとに "keep alive" シグナルがサーバーに送信されます。
反対に、外部からの接続を維持するには、次をサーバーの /etc/ssh/sshd_config
に設定します (数字は0より大きく):
ClientAliveInterval 120
ssh の設定で接続データを保存する
Whenever you want to connect to a ssh server, you usually have to type at least its address and the username. To save that typing work for servers you regularly connect to, you can use the personal ~/.ssh/config
or the global /etc/ssh/ssh_config
files as shown in the following example:
~/.ssh/config
Host myserver HostName 123.123.123.123 Port 12345 User bob Host other_server HostName test.something.org User alice CheckHostIP no Cipher blowfish
Now you can simply connect to the server by using the name you specified:
$ ssh myserver
To see a complete list of the possible options, check out ssh_config's manpage on your system or the ssh_config documentation on the official website.
Autossh - SSH セッションとトンネルの自動再起動
ネットワークの状態が悪かったりしてクライアントが切断してしまい、セッションやトンネルの接続を維持できない場合、Autossh を使って自動的にセッションとトンネルを再起動できます。Autossh は公式リポジトリからインストールできます。
使用例:
$ autossh -M 0 -o "ServerAliveInterval 45" -o "ServerAliveCountMax 2" username@example.com
sshfs を組み合わせる:
$ sshfs -o reconnect,compression=yes,transform_symlinks,ServerAliveInterval=45,ServerAliveCountMax=2,ssh_command='autossh -M 0' username@example.com: /mnt/example
プロキシ設定で設定した SOCKS プロクシを使って接続:
$ autossh -M 0 -o "ServerAliveInterval 45" -o "ServerAliveCountMax 2" -NCD 8080 username@example.com
With the -f
option autossh can be made to run as a background process. Running it this way however means the passprase cannot be entered interactively.
The session will end once you type exit
in the session, or the autossh process receives a SIGTERM, SIGINT of SIGKILL signal.
systemd を使ってブート時に自動的に Autossh を起動する
If you want to automatically start autossh, it is now easy to get systemd to manage this for you. For example, you could create a systemd unit file like this:
[Unit] Description=AutoSSH service for port 2222 After=network.target [Service] Environment="AUTOSSH_GATETIME=0" ExecStart=/usr/bin/autossh -M 0 -NL 2222:localhost:2222 -o TCPKeepAlive=yes foo@bar.com [Install] WantedBy=multi-user.target
Here AUTOSSH_GATETIME=0
is an environment variable specifying how long ssh must be up before autossh considers it a successful connection, setting it to 0 autossh also ignores the first run failure of ssh. This may be useful when running autossh at boot. Other environment variables are available on the manpage. Of course, you can make this unit more complex if necessary (see the systemd documentation for details), and obviously you can use your own options for autossh, but note that the -f
implying AUTOSSH_GATETIME=0
does not work with systemd.
Then place this in, for example, /etc/systemd/system/autossh.service. Afterwards, you can then enable your autossh tunnels with, e.g.:
$ systemctl start autossh
(or whatever you called the service file)
If this works OK for you, you can make this permanent by running
$ systemctl enable autossh
That way autossh will start automatically at boot.
It is also easy to maintain several autossh processes, to keep several tunnels alive. Just create multiple .service files with different names.
ソケットアクティベーションで SSH ポート番号を変更する (sshd.socket)
次の内容で /etc/systemd/system/sshd.socket.d/port.conf
ファイルを作成:
[Socket] # Disable default port ListenStream= # Set new port ListenStream=12345
リロードすれば systemd は自動的に新しいポートを開きます:
systemctl daemon-reload
トラブルシューティング
チェックリスト
This is a first-steps troubleshooting checklist. It is recommended to check these issues before you look any further:
1. The client and server ~/.ssh
folder and its content should be accessible by its user:
$ chmod 700 /home/USER/.ssh $ chmod 600 /home/USER/.ssh/*
2. Check that all files within client's and server's ~/.ssh
folder are owned by its user:
$ chown -R USER: ~/.ssh
3. Check that the client's public e.g. id_rsa.pub
key row is in the server's authorized_keys
file.
4. Check you did not limit SSH access via AllowUsers
in /etc/ssh/sshd_config
(space separated).
期限切れのキーを削除 (任意)
5. Delete old/invalid key rows in server's ~/.ssh/authorized_keys
file.
6. Delete old/invalid private and public keys within the clients ~/.ssh
folder.
推奨事項
7. Keep as less keys as possible in user's ~/.ssh/authorized_keys
file on the server.
電源オフ/再起動した後も SSH 接続が残ってしまう
systemd が sshd の前に network を停止してしまうと電源を切った後も SSH 接続が繋がったままになります。この問題を修正するには、After
ステートメントを修正してください:
/usr/lib/systemd/system/systemd-user-sessions.service
#After=remote-fs.target After=network.target
接続が拒否されるまたはタイムアウトする
Is your router doing port forwarding?
SKIP THIS STEP IF YOU ARE NOT BEHIND A NAT MODEM/ROUTER (eg, a VPS or otherwise publicly addressed host). Most home and small businesses will have a NAT modem/router.
The first thing is to make sure that your router knows to forward any incoming ssh connection to your machine. Your external IP is given to you by your ISP, and it is associated with any requests coming out of your router. So your router needs to know that any incoming ssh connection to your external IP needs to be forwarded to your machine running sshd.
Find your internal network address.
ip a
Find your interface device and look for the inet field. Then access your router's configuration web interface, using your router's IP (find this on the web). Tell your router to forward it to your inet IP. Go to [1] for more instructions on how to do so for your particular router.
Is SSH running and listening?
$ ss -tnlp
If the above command do not show SSH port is open, SSH is NOT running. Check /var/log/messages
for errors etc.
接続をブロックするようなファイアウォールのルールが存在しないか?
Iptables によってポート 22
の接続がブロックされている可能性があります。次のコマンドで確認してください:
# iptables -nvL
INPUT
チェインのパケットを拒否するようなルールがないか見て下さい。そして、必要であれば、次のようなコマンドでポートのブロックを解除します:
# iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT
ファイアウォールの設定に関する詳細はファイアウォールを見て下さい。
Is the traffic even getting to your computer?
Start a traffic dump on the computer you're having problems with:
# tcpdump -lnn -i any port ssh and tcp-syn
This should show some basic information, then wait for any matching traffic to happen before displaying it. Try your connection now. If you do not see any output when you attempt to connect, then something outside of your computer is blocking the traffic (e. g., hardware firewall, NAT router etc.).
ISP またはサードパーティによってデフォルトのポートがブロックされてないか?
In some cases, your ISP might block the default port (SSH port 22) so whatever you try (opening ports, hardening the stack, defending against flood attacks, et al) ends up useless. To confirm this, create a server on all interfaces (0.0.0.0) and connect remotely.
If you get an error message comparable to this:
ssh: connect to host www.inet.hr port 22: Connection refused
That means the port is not being blocked by the ISP, but the server does not run SSH on that port (See security through obscurity).
However, if you get an error message comparable to this:
ssh: connect to host 111.222.333.444 port 22: Operation timed out
That means that something is rejecting your TCP traffic on port 22. Basically that port is stealth, either by your firewall or 3rd party intervention (like an ISP blocking and/or rejecting incoming traffic on port 22). If you know you are not running any firewall on your computer, and you know that Gremlins are not growing in your routers and switches, then your ISP is blocking the traffic.
To double check, you can run Wireshark on your server and listen to traffic on port 22. Since Wireshark is a Layer 2 Packet Sniffing utility, and TCP/UDP are Layer 3 and above (see IP Network stack), if you do not receive anything while connecting remotely, a third party is most likely to be blocking the traffic on that port to your server.
Wireshark による問題診断
公式リポジトリにある wireshark-cli パッケージで Wireshark をインストールしてください。
And then run it using,
tshark -f "tcp port 22" -i NET_IF
where NET_IF is the network interface for a WAN connection (see ip a
to check). If you aren't receiving any packets while trying to connect remotely, you can be very sure that your ISP is blocking the incoming traffic on port 22.
解決方法
The solution is just to use some other port that the ISP isn't blocking. Open the /etc/ssh/sshd_config
and configure the file to use different ports. For example, add:
Port 22 Port 1234
Also make sure that other "Port" configuration lines in the file are commented out. Just commenting "Port 22" and putting "Port 1234" won't solve the issue because then sshd will only listen on port 1234. Use both lines to run the SSH server on both ports.
Restart the server systemctl restart sshd.service
and you're almost done. You still have to configure your client(s) to use the other port instead of the default port. There are numerous solutions to that problem, but let's cover two of them here.
Read from socket failed: connection reset by peer
最近の openssh のバージョンでは、楕円曲線暗号関連のバグのせいで、上記のエラーメッセージで接続が失敗することがあります。その場合 ~/.ssh/config
に次の行を追加してください:
HostKeyAlgorithms ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss
openssh 5.9 では、上記の修正方法は働きません。代わりに、~/.ssh/config
に以下の行を記述してください:
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc MACs hmac-md5,hmac-sha1,hmac-ripemd160
openssh バグフォーラムの 議論 も参照。
"[your shell]: No such file or directory" / ssh_exchange_identification problem
One possible cause for this is the need of certain SSH clients to find an absolute path (one returned by whereis -b [your shell]
, for instance) in $SHELL
, even if the shell's binary is located in one of the $PATH
entries.
"Terminal unknown" や "Error opening terminal" エラーメッセージ
With ssh it is possible to receive errors like "Terminal unknown" upon logging in. Starting ncurses applications like nano fails with the message "Error opening terminal". There are two methods to this problem, a quick one using the $TERM variable and a profound one using the terminfo file.
$TERM 変数を設定する解決策
After connecting to the remote server set the $TERM variable to "xterm" with the following command.
TERM=xterm
This method is a workaround and should be used on ssh servers you do seldomly connect to, because it can have unwanted side effects. Also you have to repeat the command after every connection, or alternatively set it in ~.bashrc .
terminfo ファイルを使う解決策
A profound solution is transferring the terminfo file of the terminal on your client computer to the ssh server. In this example we cover how to setup the terminfo file for the "rxvt-unicode-256color" terminal. Create the directory containing the terminfo files on the ssh server, while you are logged in to the server issue this command:
mkdir -p ~/.terminfo/r/
Now copy the terminfo file of your terminal to the new directory. Replace rxvt-unicode-256color
with your client's terminal in the following command and ssh-server
with the relevant user and server adress.
$ scp /usr/share/terminfo/r/rxvt-unicode-256color ssh-server:~/.terminfo/r/
After logging in and out from the ssh server the problem should be fixed.