「OpenSSH」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(→‎解決方法: 再翻訳)
(文字列「Tips and tricks」を「ヒントとテクニック」に置換)
(他の1人の利用者による、間の6版が非表示)
4行目: 4行目:
 
[[en:Secure Shell]]
 
[[en:Secure Shell]]
 
[[es:Secure Shell]]
 
[[es:Secure Shell]]
  +
[[fa:SSH]]
 
[[fr:ssh]]
 
[[fr:ssh]]
 
[[it:Secure Shell]]
 
[[it:Secure Shell]]
11行目: 12行目:
 
[[ru:Secure Shell]]
 
[[ru:Secure Shell]]
 
[[sr:Secure Shell]]
 
[[sr:Secure Shell]]
[[zh-CN:Secure Shell]]
+
[[zh-hans:Secure Shell]]
 
{{Related articles start}}
 
{{Related articles start}}
 
{{Related|SSH 鍵}}
 
{{Related|SSH 鍵}}
20行目: 21行目:
 
{{Related|syslog-ng}}
 
{{Related|syslog-ng}}
 
{{Related|SFTP chroot}}
 
{{Related|SFTP chroot}}
  +
{{Related|SCP と SFTP}}
 
{{Related articles end}}
 
{{Related articles end}}
 
Secure Shell (SSH) は暗号技術を利用して、安全にリモートコンピュータと通信するためのネットワークプロトコルです。暗号によってデータの機密性と完全性が保証されます。SSH は公開鍵暗号を使ってリモートコンピュータを認証し、リモートコンピュータは必要に応じてユーザーを認証します。
 
Secure Shell (SSH) は暗号技術を利用して、安全にリモートコンピュータと通信するためのネットワークプロトコルです。暗号によってデータの機密性と完全性が保証されます。SSH は公開鍵暗号を使ってリモートコンピュータを認証し、リモートコンピュータは必要に応じてユーザーを認証します。
25行目: 27行目:
 
基本的に SSH はリモートマシンにログインしてコマンドを実行するために使われますが、トンネリングや TCP ポートや X11 接続の任意のフォワーディングをサポートしており、SFTP や SCP プロトコルを使うことでファイル転送をすることも可能です。
 
基本的に SSH はリモートマシンにログインしてコマンドを実行するために使われますが、トンネリングや TCP ポートや X11 接続の任意のフォワーディングをサポートしており、SFTP や SCP プロトコルを使うことでファイル転送をすることも可能です。
   
デフォルトでは、SSH サーバーは標準の TCP 22番ポートを使います。通常は SSH クライアントプロトコルを使って ''sshd'' デーモンの接続を確立してリモート接続を承認します。Mac OS X, GNU/Linux, Solaris, OpenVMS など近代的なオペレーティングシステムのほとんどでサーバーとクライアントの両方が備わってします。複雑なもの・完全なものまで様々なレベルのバージョンがプロプライエタリ・フリーウェア・オープンソースを問わずに存在します。
+
デフォルトでは、SSH サーバーは標準の TCP 22番ポートを使います。通常は SSH クライアントプロトコルを使って ''sshd'' デーモンの接続を確立してリモート接続を承認します。macOS, GNU/Linux, Solaris, OpenVMS など近代的なオペレーティングシステムのほとんどでサーバーとクライアントの両方が備わってします。複雑なもの・完全なものまで様々なレベルのバージョンがプロプライエタリ・フリーウェア・オープンソースを問わずに存在します。
 
(ソース: [[Wikipedia:ja:Secure Shell]])
 
   
 
== OpenSSH ==
 
== OpenSSH ==
47行目: 47行目:
   
 
特定のユーザーにだけアクセスを許可するには次の行を追加してください:
 
特定のユーザーにだけアクセスを許可するには次の行を追加してください:
AllowUsers user1 user2
+
AllowUsers ''user1 user2''
   
 
特定のグループにだけアクセスを許可するには:
 
特定のグループにだけアクセスを許可するには:
AllowGroups group1 group2
+
AllowGroups ''group1 group2''
   
 
SSH による root ログインを無効にするには、PermitRootLogin 行を次のように変更してください:
 
SSH による root ログインを無効にするには、PermitRootLogin 行を次のように変更してください:
57行目: 57行目:
 
{{Note|1=バージョン 7.0p1 からは {{ic|PermitRootLogin prohibit-password}} がデフォルトになっています。{{ic|man sshd_config}} を参照。}}
 
{{Note|1=バージョン 7.0p1 からは {{ic|PermitRootLogin prohibit-password}} がデフォルトになっています。{{ic|man sshd_config}} を参照。}}
   
ウェルカムメッセージを追加するには {{ic|/etc/issue}} ファイルを編集して Banner 行を次のように変更してください:
+
ウェルカムメッセージを追加するには {{ic|/etc/issue}} ファイルを編集して {{ic|Banner}} 行を次のように変更してください:
 
Banner /etc/issue
 
Banner /etc/issue
   
97行目: 97行目:
 
=== サーバーに接続する ===
 
=== サーバーに接続する ===
 
サーバーに接続するには、次を実行してください:
 
サーバーに接続するには、次を実行してください:
$ ssh -p port user@server-address
+
$ ssh -p port ''port'' ''user''@''server-address''
   
 
=== SSH の保護 ===
 
=== SSH の保護 ===
106行目: 106行目:
   
 
==== ブルートフォースアタックからの保護 ====
 
==== ブルートフォースアタックからの保護 ====
ブルートフォースは単純な攻撃方法です: ランダムなユーザー名とパスワードの組み合わせをとにかく沢山作ってウェブページや SSH などのサーバーログインプロンプトにログインを絶えず試行します。ブルートフォース攻撃からは [[fail2ban]] や [[sshguard]] などの自動スクリプトを使うことで攻撃者をブロックすることで身を守ることができます。
+
ブルートフォースは単純な攻撃方法です: ランダムなユーザー名とパスワードの組み合わせをとにかく沢山作ってウェブページや SSH などのサーバーログインプロンプトにログインを絶えず試行します。ブルートフォース攻撃からは [[fail2ban]] や [[sshguard]] などの自動スクリプトを使うことで攻撃者をブロックすることで身を守ることができます。[[Uncomplicated Firewall#ufw によるレート制限]]も参照
   
 
もしくは、公開鍵認証を使うことでブルートフォース攻撃を出来なくすることもできます。{{ic|sshd_config}} に次の設定を追加:
 
もしくは、公開鍵認証を使うことでブルートフォース攻撃を出来なくすることもできます。{{ic|sshd_config}} に次の設定を追加:
   
 
PasswordAuthentication no
 
PasswordAuthentication no
  +
ChallengeResponseAuthentication no
   
 
上の設定を適用する前に、SSH アクセスが必要な全てのアカウントで {{ic|authorized_keys}} ファイルに公開鍵認証の設定をするようにしてください。詳しくは [[SSH 鍵#リモートサーバーに公開鍵をコピー]] を参照。
 
上の設定を適用する前に、SSH アクセスが必要な全てのアカウントで {{ic|authorized_keys}} ファイルに公開鍵認証の設定をするようにしてください。詳しくは [[SSH 鍵#リモートサーバーに公開鍵をコピー]] を参照。
125行目: 126行目:
 
Sudo を使うことで、root アカウントの認証を行うことなく、必要に応じて root 権限を選択的に付与することができます。このため SSH による root ログインを拒否して、攻撃者にパスワードに加えて (root でない) ユーザー名も推測させる必要を生じさせることで、ブルートフォース攻撃を困難にすることが可能です。
 
Sudo を使うことで、root アカウントの認証を行うことなく、必要に応じて root 権限を選択的に付与することができます。このため SSH による root ログインを拒否して、攻撃者にパスワードに加えて (root でない) ユーザー名も推測させる必要を生じさせることで、ブルートフォース攻撃を困難にすることが可能です。
   
{{ic|/etc/ssh/sshd_config}} の "Authentication" セクションを編集することで SSH からの root ログインを拒否するように設定できます。{{ic|#PermitRootLogin yes}} を {{ic|no}} に変更して行をアンコメントしてください:
+
{{ic|/etc/ssh/sshd_config}} の "Authentication" セクションを編集することで SSH からの root ログインを拒否するように設定できます。{{ic|#PermitRootLogin prohibit-password}} を {{ic|no}} に変更して行をアンコメントしてください:
   
 
{{hc|/etc/ssh/sshd_config|
 
{{hc|/etc/ssh/sshd_config|
141行目: 142行目:
 
command="/usr/lib/rsync/rrsync -ro /" ssh-rsa …
 
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.
 
   
  +
ログイン時に root ユーザーの名前を出すことで攻撃する対象が増えてしまうことに対しては {{ic|sshd_config}} に以下を追加することで埋め合わせができます:
The increased attack surface created by exposing the root user name at login can be compensated by adding the following to {{ic|sshd_config}}:
 
   
 
PermitRootLogin forced-commands-only
 
PermitRootLogin forced-commands-only
   
  +
上記の設定は root が SSH で実行できるコマンドを制限するだけでなく、パスワードの使用も無効化して、root アカウントでは強制的に公開鍵認証を使うようになります。
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.
 
   
  +
root で使えるコマンドは制限しないで公開鍵認証の強制だけをするという手もあり、それでもブルートフォース攻撃はほぼ不可能です。その場合、以下を設定:
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
 
PermitRootLogin without-password
161行目: 162行目:
 
コマンドラインの ssh クライアントは dbclient という名前が付けられています。
 
コマンドラインの ssh クライアントは dbclient という名前が付けられています。
   
=== Mosh: Mobile Shell ===
+
=== Mosh ===
 
Mosh の [http://mosh.mit.edu/ ウェブサイト] より:
 
Mosh の [http://mosh.mit.edu/ ウェブサイト] より:
   
170行目: 171行目:
 
Mosh にはドキュメントに記載されていないコマンドラインオプション {{ic|1=--predict=experimental}} が存在し、よりアグレッシブにローカルのキーストロークのエコーを生成します。キーボード入力が遅延なく確認できるのに興味があるのであればこの prediction モードを使ってみて下さい。
 
Mosh にはドキュメントに記載されていないコマンドラインオプション {{ic|1=--predict=experimental}} が存在し、よりアグレッシブにローカルのキーストロークのエコーを生成します。キーボード入力が遅延なく確認できるのに興味があるのであればこの prediction モードを使ってみて下さい。
   
  +
== ヒントとテクニック ==
== Tips and tricks ==
 
   
 
=== 暗号化 SOCKS トンネル ===
 
=== 暗号化 SOCKS トンネル ===
  +
暗号化トンネルは信頼ができない様々なワイヤレス接続を使用するノートパソコンなどで非常に有用です。必要なのは SSH サーバーが安全な場所 (家や仕事場など) で動作していることだけです。[http://www.dyndns.org/ DynDNS] などのダイナミック DNS サービスを利用すれば IP アドレスを覚える必要もありません。
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 [http://www.dyndns.org/ DynDNS] so you do not have to remember your IP-address.
 
   
 
==== 手順 1: 接続の開始 ====
 
==== 手順 1: 接続の開始 ====
  +
以下のコマンドを実行することで接続を開始できます:
You only have to execute this single command to start the connection:
 
 
$ ssh -TND 4711 ''user''@''host''
 
$ ssh -TND 4711 ''user''@''host''
  +
{{Ic|''user''}} はユーザー名に {{Ic|''host''}} は SSH サーバーが動作しているホストに置き換えてください。パスワードを入力すると接続が行われます。{{Ic|N}} フラグはインタラクティブプロンプトを無効化し、{{Ic|D}} フラグは listen するローカルポートを指定します (ポート番号は何でもかまいません)。{{Ic|T}} フラグは疑似 tty アロケーションを無効化します。
where {{Ic|''user''}} is your username at the SSH server running at the {{Ic|''host''}}. It will ask for your password, and then you are connected! The {{Ic|N}} flag disables the interactive prompt, and the {{Ic|D}} flag specifies the local port on which to listen on (you can choose any port number if you want). The {{Ic|T}} flag disables pseudo-tty allocation.
 
   
  +
verbose ({{Ic|-v}}) フラグを追加することで、接続が成功していることを出力から確認することができます。
It is nice to add the verbose ({{Ic|-v}}) flag, because then you can verify that it is actually connected from that output.
 
   
 
==== 手順 2: ブラウザ (やその他のプログラム) の設定 ====
 
==== 手順 2: ブラウザ (やその他のプログラム) の設定 ====
  +
新しく作成した socks トンネルを使用するようにウェブブラウザ (や他のプログラム) を設定しないと上記の作業は無意味です。最新バージョンの SSH は SOCKS4 と SOCKS5 に対応しているため、どちらかを使うことができます。
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'':
+
* Firefox の場合: ''編集 → 設定 → 詳細 → ネットワーク → 接続 → 接続設定'':
  +
: ラジオボタンの''手動でプロキシを設定する''にチェックを入れて、''SOCKS ホスト''テキストフィールドに {{ic|localhost}} と、次のテキストフィールドにポート番号を入力してください (上の例では {{ic|4711}})。
: Check the ''Manual proxy configuration'' radio button, and enter {{ic|localhost}} in the ''SOCKS host'' text field, and then enter your port number in the next text field ({{ic|4711}} in the example above).
 
   
  +
Firefox はデフォルトでは DNS リクエストの作成に socks トンネルを使用しません。以下の手順で設定することでプライバシーを守ることができます:
Firefox does not automatically make DNS requests through the socks tunnel. This potential privacy concern can be mitigated by the following steps:
 
   
  +
# Firefox のロケーションバーに about:config と入力。
# Type about:config into the Firefox location bar.
 
# Search for network.proxy.socks_remote_dns
+
# network.proxy.socks_remote_dns を検索。
  +
# 値を true に設定。
# Set the value to true.
 
  +
# ブラウザを再起動。
# Restart the browser.
 
   
  +
* Chromium の場合: 環境変数やコマンドラインオプションで SOCKS の設定ができます。以下の関数を {{ic|.bashrc}} に追加することを推奨します:
* 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 {{ic|.bashrc}}:
 
 
function secure_chromium {
 
function secure_chromium {
 
port=4711
 
port=4711
203行目: 204行目:
 
exit
 
exit
 
}
 
}
  +
もしくは:
OR
 
 
function secure_chromium {
 
function secure_chromium {
 
port=4711
 
port=4711
210行目: 211行目:
 
}
 
}
   
  +
ターミナルから以下のように実行してください:
Now open a terminal and just do:
 
 
$ secure_chromium
 
$ secure_chromium
 
Enjoy your secure tunnel!
 
   
 
=== X11 フォワーディング ===
 
=== X11 フォワーディング ===
219行目: 218行目:
 
X11 フォワーディングはリモートシステムで X11 プログラムを動作させて、グラフィカルインターフェイスをローカルのクライアントマシンで表示させるメカニズムです。X11 フォワーディングではリモートホストに X11 システムを完全にインストールさせる必要はなく、''xauth'' をインストールするだけで十分です。''xauth'' は、、X11 セッションの認証を行うために必要なサーバーとクライアントによって使用される {{ic|Xauthority}} の設定を管理するユーティリティです ([http://xmodulo.com/2012/11/how-to-enable-x11-forwarding-using-ssh.html ソース])。
 
X11 フォワーディングはリモートシステムで X11 プログラムを動作させて、グラフィカルインターフェイスをローカルのクライアントマシンで表示させるメカニズムです。X11 フォワーディングではリモートホストに X11 システムを完全にインストールさせる必要はなく、''xauth'' をインストールするだけで十分です。''xauth'' は、、X11 セッションの認証を行うために必要なサーバーとクライアントによって使用される {{ic|Xauthority}} の設定を管理するユーティリティです ([http://xmodulo.com/2012/11/how-to-enable-x11-forwarding-using-ssh.html ソース])。
   
{{Warning|X11 forwarding has important security implications which should be at least acknowledged by reading relevant sections of {{ic|ssh}}, {{ic|sshd_config}} and {{ic|ssh_config}} manual pages. See also [https://security.stackexchange.com/questions/14815/security-concerns-with-x11-forwarding a short writeup]}}
+
{{Warning|X11 フォワーディングにはセキュリティ的に重要な問題があります。{{ic|ssh}}, {{ic|sshd_config}}, {{ic|ssh_config}} のマニュアルページの該当するセクションを読んで最低限の知識をつけてください。[https://security.stackexchange.com/questions/14815/security-concerns-with-x11-forwarding こちらの記事] も参照。}}
   
 
==== セットアップ ====
 
==== セットアップ ====
234行目: 233行目:
 
クライアント側では、接続するたびにコマンドラインで {{ic|-X}} スイッチを指定して {{ic|ForwardX11}} オプションを有効にするか、[[#クライアント|openSSH クライアントの設定ファイル]]で {{ic|ForwardX11}} を ''yes'' に設定してください。
 
クライアント側では、接続するたびにコマンドラインで {{ic|-X}} スイッチを指定して {{ic|ForwardX11}} オプションを有効にするか、[[#クライアント|openSSH クライアントの設定ファイル]]で {{ic|ForwardX11}} を ''yes'' に設定してください。
   
{{Tip|You can enable the {{ic|ForwardX11Trusted}} option ({{ic|-Y}} switch on the command line) if GUI is drawing badly or you receive errors; this will prevent X11 forwardings from being subjected to the [http://www.x.org/wiki/Development/Documentation/Security/ X11 SECURITY extension] controls. Be sure you have read [[#X11 フォワーディング|the warning]] at the beginning of this section if you do so.}}
+
{{Tip|GUI の描画がおかしい場合やエラーが表示されるときは {{ic|ForwardX11Trusted}} オプションを有効にできます (コマンドラインでは {{ic|-Y}} スイッチ)X11 フォワーディングが [http://www.x.org/wiki/Development/Documentation/Security/ X11 SECURITY 拡張] の制御から外れるようになります。使用するときはセクション冒頭の[[#X11 フォワーディング|警告]]を読んでください。}}
   
 
==== 使用方法 ====
 
==== 使用方法 ====
248行目: 247行目:
 
$ xhost +
 
$ xhost +
   
  +
上記のコマンドは全てのユーザーに X11 アプリケーションの転送を許可します。特定のホストだけに転送を制限するには:
The above command will allow anybody to forward X11 applications. To restrict forwarding to a particular host type:
 
 
$ xhost +hostname
 
$ xhost +hostname
   
where hostname is the name of the particular host you want to forward to. See {{ic|man xhost}} for more details.
+
hostname は転送先のホストの名前に置き換えてください。詳しくは {{ic|man xhost}} を参照。
   
  +
特定のアプリケーションではローカルマシンでインスタンスが動作しているかチェックが実行されます。例えば [[Firefox]] は以下の起動パラメータを使用してローカルマシンでリモートインスタンスを起動する必要があります:
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
+
$ firefox --no-remote
   
If you get "X11 forwarding request failed on channel 0" when you connect (and the server {{ic|/var/log/errors.log}} shows "Failed to allocate internet-domain X11 display socket"), make sure package {{Pkg|xorg-xauth}} is installed. If its installation is not working, try to either:
+
接続時に "X11 forwarding request failed on channel 0" と表示される場合 (サーバーの {{ic|/var/log/errors.log}} "Failed to allocate internet-domain X11 display socket" と出力される場合){{Pkg|xorg-xauth}} パッケージがインストールされていることを確認してください。上手く機能しない場合、以下の設定を試してみてください:
   
* enable the {{ic|AddressFamily any}} option in {{ic|ssh'''d'''_config}} on the ''server'', or
+
* サーバーの {{ic|ssh'''d'''_config}} {{ic|AddressFamily any}} オプションを有効にする。
* set the {{ic|AddressFamily}} option in {{ic|ssh'''d'''_config}} on the ''server'' to inet.
+
* サーバーの {{ic|ssh'''d'''_config}} {{ic|AddressFamily}} オプションを inet に設定する。
  +
IPv4 で Ubuntu クライアントを使っている場合は inet に設定することで問題が解決します。
Setting it to inet may fix problems with Ubuntu clients on IPv4.
 
   
  +
SSH サーバーの他のユーザーで X アプリケーションを実行するには SSH でログインしているユーザーの {{Ic|xauth list}} の認証行を {{Ic|xauth add}} する必要があります。
For running X applications as other user on the SSH server you need to {{Ic|xauth add}} the authentication line taken from {{Ic|xauth list}} of the SSH logged in user.
 
   
 
=== 他のポートのフォワーディング ===
 
=== 他のポートのフォワーディング ===
  +
SSH は X11 をサポートしているだけでなく、TCP 接続のセキュアなトンネル化に使用することもできます。ローカルフォワーディングとリモートフォワーディングの両方が使えます。
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 {{Ic|-L}} switch and it's accompanying forwarding specification in the form of {{Ic|<tunnel port>:<destination address>:<destination port>}}.
 
   
  +
ローカルフォワーディングはローカルマシンのポートを開いて、リモートホストに接続が転送されます。転送先をリモートホストと同じにすることで、同一マシンでセキュアな VNC 接続などができます。ローカルフォワーディングは {{Ic|-L}} スイッチで利用することができ {{Ic|<tunnel port>:<destination address>:<destination port>}} という形式で転送先を指定します:
Thus:
 
   
 
$ ssh -L 1000:mail.google.com:25 192.168.0.100
 
$ ssh -L 1000:mail.google.com:25 192.168.0.100
   
  +
上記のコマンドは SSH で 192.168.0.100 にログインしてシェルを開きます。そしてローカルマシンの TCP ポート 1000 から mail.google.com のポート 25 にトンネルが作成されます。接続が確立すると localhost:1000 への通信は Gmail の SMTP ポートに接続されます。Google から見ると、192.168.0.100 から接続が来ているように見えます (必ずしも接続と一緒にデータが運ばれるとは限りません)。データはローカルマシンと 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.
 
   
  +
同じように以下のコマンドは localhost:2000 に接続することができ、リモートホストのポート 6001 に透過的に送信されます:
Similarly:
 
   
 
$ ssh -L 2000:192.168.0.100:6001 192.168.0.100
 
$ ssh -L 2000:192.168.0.100:6001 192.168.0.100
   
  +
前者の例はセキュリティ上問題がある ({{AUR|tightvnc}} パッケージに含まれている) vncserver ユーティリティによる VNC 接続などで有用です。
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.
 
   
  +
リモートフォワーディングは SSH トンネルとローカルマシンを通してリモートホストから任意のホストに接続できるようにします。ローカルフォワーディングとは逆の機能であり、ファイアウォールによってリモートホストの接続が限られている場合などに有用です。リモートフォワーディングは {{Ic|-R}} スイッチで使うことができ {{Ic|<tunnel port>:<destination address>:<destination port>}} という形式で転送先を指定します:
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 {{Ic|-R}} switch and a forwarding specification in the form of {{Ic|<tunnel port>:<destination address>:<destination port>}}.
 
 
Thus:
 
   
 
$ ssh -R 3000:irc.freenode.net:6667 192.168.0.200
 
$ ssh -R 3000:irc.freenode.net:6667 192.168.0.200
   
  +
上記のコマンドは 192.168.0.200 にシェルを立ち上げて、192.168.0.200 からローカルホストの3000番ポートへの接続をトンネルを通して送信し、それから irc.freenode.net のポート 6667 に転送します。ポート 6667 がブロックされている場合でもリモートホストから IRC プログラムを利用することができるようになります。
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.
 
  +
  +
ローカルフォワーディングとリモートフォワーディングはどちらもセキュアなゲートウェイとして使用することができます。{{Ic|<tunnel address>:<tunnel port>:<destination address>:<destination port>}} のようにバインドアドレスをつかうことで、SSH や SSH デーモンを動かしていなくても他のコンピュータが SSH トンネルを利用することが可能です。{{Ic|<tunnel address>}} はトンネルの入り口となるマシンのアドレスです: {{Ic|localhost}}, {{Ic|*}} (あるいは空)。特定のアドレス経由の接続、ループバックインターフェイス経由の接続、全てのインターフェイス経由の接続を許可します。デフォルトでは、フォワーディングはトンネルの入り口のマシンからの接続だけに制限されており {{Ic|<tunnel address>}} は {{Ic|localhost}} に設定されています。ローカルフォワーディングは特に設定が必要ありませんが、リモートフォワーディングはリモートサーバーの SSH デーモンの設定によって制限を受けます。詳しくは {{Ic|sshd_config(5)}} の {{Ic|GatewayPorts}} オプションを見てください。
  +
  +
=== 踏み台ホスト ===
  +
  +
場合によっては、接続先の SSH デーモンに直接接続できず、踏み台サーバー (ジャンプサーバー) を使わざるを得ないことがあります。ふたつ以上の SSH トンネルを接続して、それぞれのサーバーに対してローカルの鍵で認証します。SSH エージェントの転送 ({{ic|-A}}) と疑似端末の割当 ({{ic|-t}}) を使って以下のようにローカルの鍵を転送します:
  +
  +
$ ssh -A -t -l user1 bastion1 \
  +
ssh -A -t -l user2 intermediate2 \
  +
ssh -A -t -l user3 target
  +
  +
以下のように {{ic|-J}} フラグを使用することもできます:
  +
  +
$ ssh -J user1@bastion1,user2@intermediate2 user3@target
   
  +
{{ic|-J}} ディレクティブで指定するホストはカンマで区切り、指定された順番で接続されます。{{ic|user...@}} の部分は必須ではありません。{{ic|-J}} で指定したホストは ssh の設定ファイルを使うため、必要であればホスト毎にオプションを設定することが可能です。
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. {{Ic|<tunnel address>:<tunnel port>:<destination address>:<destination port>}}. The {{Ic|<tunnel address>}} can be any address on the machine at the start of the tunnel, {{Ic|localhost}}, {{Ic|*}} (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 {{Ic|<tunnel address>}} is set to {{Ic|localhost}}. Local forwarding requires no additional configuration, however remote forwarding is limited by the remote server's SSH daemon configuration. See the {{Ic|GatewayPorts}} option in {{Ic|sshd_config(5)}} for more information.
 
   
 
=== マルチプレクス ===
 
=== マルチプレクス ===
303行目: 312行目:
   
 
=== SSH の高速化 ===
 
=== SSH の高速化 ===
  +
  +
{{Tip|SSH を SFTP や SCP で使用する場合、{{AUR|openssh-hpn-git}} をインストールすることで転送速度を劇的に上げることができます [https://www.psc.edu/index.php/hpn-ssh]。}}
   
 
同一のホストのセッションは全て単一の接続を使うようにすることで、後のログインを劇的に高速化することができます。{{ic|/etc/ssh/ssh_config}} や {{ic|$HOME/.ssh/config}} の適当なホストの下に以下の行を追加してください:
 
同一のホストのセッションは全て単一の接続を使うようにすることで、後のログインを劇的に高速化することができます。{{ic|/etc/ssh/ssh_config}} や {{ic|$HOME/.ssh/config}} の適当なホストの下に以下の行を追加してください:
  +
ControlMaster auto
Host examplehost.com
 
  +
ControlPersist yes
ControlMaster auto
 
  +
ControlPath ~/.ssh/sockets/socket-%r@%h:%p
ControlPersist yes
 
  +
ControlPath ~/.ssh/socket-%r@%h:%p
 
  +
{{ic|~/.ssh/sockets}} は他のユーザーが書き込めないディレクトリなら何でもかまいません。
  +
  +
{{ic|ControlPersist}} はクライアントとの接続を閉じるまでにどれくらい待機するか指定します。{{ic|yes}} で永遠に待ち続け、{{ic|no}} で接続を即座に終了します。秒数で指定することもできます。
   
  +
{{Warning|{{ic|ControlPersist}} を {{ic|yes}} に設定すると接続が自動的に終了しなくなるので注意してください。}}
上記のオプションの詳しい説明は {{ic|ssh_config(5)}} マニュアルページを見て下さい。
 
   
 
速度を向上させる別のオプションとして圧縮を有効化する {{ic|-C}} フラグがあります。{{ic|/etc/ssh/ssh_config}} の適切なホストの下に次の行を追加することで永続的に設定することができます:
 
速度を向上させる別のオプションとして圧縮を有効化する {{ic|-C}} フラグがあります。{{ic|/etc/ssh/ssh_config}} の適切なホストの下に次の行を追加することで永続的に設定することができます:
 
Compression yes
 
Compression yes
{{Warning|{{ic|man ssh}} states that "''Compression is desirable on modem lines and other slow connections, but will only slow down things on fast networks''". This tip might be counterproductive depending on your network configuration.}}
 
   
  +
{{Warning|{{man|1|ssh}} には「モデム接続など接続速度が遅い場合は圧縮の効果がありますが、高速なネットワークではむしろ通信が遅くなります」と書かれています。ネットワーク環境によっては圧縮は逆効果です。}}
Login time can be shortened by using the {{ic|-4}} flag, which bypasses IPv6 lookup. This can be made permanent by adding this line under the proper host in {{ic|/etc/ssh/ssh_config}}:
 
AddressFamily inet
 
   
  +
ログイン時刻は {{ic|AddressFamily inet}} オプションや {{ic|-4}} フラグを使って IPv6 ルックアップを迂回することで短くできます。
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.
 
 
{{Warning|Please do not do this unless you know what you are doing; arcfour has a number of known weaknesses.}}
 
 
To use alternative ciphers, run SSH with the {{ic|-c}} flag:
 
$ ssh -c arcfour,blowfish-cbc user@server-address
 
 
To use them permanently, add this line under the proper host in {{ic|/etc/ssh/ssh_config}}:
 
Ciphers arcfour,blowfish-cbc
 
   
 
=== SSHFS でリモートファイルシステムをマウントする ===
 
=== SSHFS でリモートファイルシステムをマウントする ===
 
sshfs を使って (SSH でアクセスした) リモートのファイルシステムをローカルフォルダにマウントする方法は [[Sshfs]] の記事を参照してください。マウントしたファイルは様々なツールであらゆる操作することができます (コピー、名前の変更、vim で編集など)。基本的に shfs よりも sshfs を使用することを推奨します。sshfs は shfs の新しいバージョンであり、元の shfs は2004年から更新されていません。
 
sshfs を使って (SSH でアクセスした) リモートのファイルシステムをローカルフォルダにマウントする方法は [[Sshfs]] の記事を参照してください。マウントしたファイルは様々なツールであらゆる操作することができます (コピー、名前の変更、vim で編集など)。基本的に shfs よりも sshfs を使用することを推奨します。sshfs は shfs の新しいバージョンであり、元の shfs は2004年から更新されていません。
  +
  +
{{Tip|ログイン時に自動的に autosshfs を実行する {{AUR|autosshfs-git}} パッケージも存在します。}}
   
 
=== Keep alive ===
 
=== Keep alive ===
337行目: 343行目:
 
ServerAliveInterval 120
 
ServerAliveInterval 120
   
これで120秒ごとに "keep alive" シグナルがサーバーに送信されます。
+
これで120秒ごとに "keep alive" シグナルがサーバーに送信されます。{{ic|ServerAliveCountMax}} や {{ic|TCPKeepAlive}} オプションも参照してください
   
 
反対に、外部からの接続を維持するには、次をサーバーの {{ic|/etc/ssh/sshd_config}} に設定します (数字は0より大きく):
 
反対に、外部からの接続を維持するには、次をサーバーの {{ic|/etc/ssh/sshd_config}} に設定します (数字は0より大きく):
 
 
 
ClientAliveInterval 120
 
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 {{ic|~/.ssh/config}} or the global {{ic|/etc/ssh/ssh_config}} files as shown in the following example:
 
 
{{hc|~/.ssh/config|
 
Host myserver
 
HostName 123.123.123.123
 
Port 12345
 
User bob
 
IdentityFile ~/.ssh/some_key_file
 
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 [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh_config ssh_config documentation] on the official website.
 
   
 
=== systemd で SSH トンネルを自動的に再起動 ===
 
=== systemd で SSH トンネルを自動的に再起動 ===
385行目: 369行目:
   
 
=== Autossh - SSH セッションとトンネルの自動再起動 ===
 
=== Autossh - SSH セッションとトンネルの自動再起動 ===
ネットワークの状態が悪かったりしてクライアントが切断してしまい、セッションやトンネルの接続を維持できない場合、[http://www.harding.motd.ca/autossh/ Autossh] を使って自動的にセッションとトンネルを再起動できます。Autossh は[[公式リポジトリ]]からインストールできます。
+
ネットワークの状態が悪かったりしてクライアントが切断してしまい、セッションやトンネルの接続を維持できない場合、{{Pkg|autossh}} を使って自動的にセッションとトンネルを再起動できます。
   
 
使用例:
 
使用例:
393行目: 377行目:
 
[[プロキシ設定]]で設定した SOCKS プロクシを使って接続:
 
[[プロキシ設定]]で設定した 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
  +
{{ic|-f}} オプションで autossh をバックグラウンドプロセスとして実行することができます。ただし対話式でパスフレーズを入力することができなくなります。
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.
 
   
The session will end once you type {{ic|exit}} in the session, or the autossh process receives a SIGTERM, SIGINT of SIGKILL signal.
+
セッション中に {{ic|exit}} と入力したり autossh プロセスに SIGTERM, SIGINT, SIGKILL 信号が送られるとセッションは終了します。
   
==== systemd を使ってブート時に自動的に Autossh を起動する ====
+
==== systemd を使ってブート時に自動的に autossh を起動する ====
  +
autossh を自動的に起動したい場合、以下の systemd ユニットファイルを作成します:
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:
 
   
  +
{{hc|/etc/systemd/system/autossh.service|2=
[Unit]
 
  +
[Unit]
Description=AutoSSH service for port 2222
 
  +
Description=AutoSSH service for port 2222
After=network.target
 
  +
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
 
   
  +
[Service]
Here {{ic|1=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 {{ic|-f}} implying {{ic|1=AUTOSSH_GATETIME=0}} does not work with systemd.
 
  +
Environment="AUTOSSH_GATETIME=0"
  +
ExecStart=/usr/bin/autossh -M 0 -NL 2222:localhost:2222 -o TCPKeepAlive=yes foo@bar.com
   
  +
[Install]
Then place this in, for example, /etc/systemd/system/autossh.service. Afterwards, you can then enable your autossh tunnels with, e.g.:
 
  +
WantedBy=multi-user.target
  +
}}
   
  +
{{ic|1=AUTOSSH_GATETIME=0}} は接続が成功して ssh が立ち上がったと autossh が認識する秒数です。0に設定すると autossh は ssh の最初の起動失敗を無視します。起動時に autossh を実行する場合は設定するべきです。他の環境変数は man ページを見てください。必要であればもっと複雑に設定することもできますが、{{ic|1=AUTOSSH_GATETIME=0}} を含む {{ic|-f}} は systemd では機能しません。
$ systemctl start autossh
 
(or whatever you called the service file)
 
   
  +
設定後はサービスを[[起動]]・[[有効化]]してください。
If this works OK for you, you can make this permanent by running
 
   
  +
以下のように ControlMaster を無効化する必要もあるかもしれません:
$ systemctl enable autossh
 
   
  +
ExecStart=/usr/bin/autossh -M 0 -o ControlMaster=no -NL 2222:localhost:2222 -o TCPKeepAlive=yes foo@bar.com
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.
+
{{Tip|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) ==
 
== ソケットアクティベーションで SSH ポート番号を変更する (sshd.socket) ==
445行目: 426行目:
 
以下は最初に行うべきトラブルシューティングのチェックリストです。何かする前に以下の問題をチェックすることを推奨します。
 
以下は最初に行うべきトラブルシューティングのチェックリストです。何かする前に以下の問題をチェックすることを推奨します。
   
  +
# 設定ディレクトリ {{ic|~/.ssh}} の中身がユーザーからアクセスできることを確認する (クライアントとサーバーの両方で確認してください): {{bc|<nowiki>
==== SSH の設定を確認 ====
 
  +
$ chmod 700 ~/.ssh
 
  +
$ chmod 600 ~/.ssh/*
1. クライアントとサーバーの {{ic|~/.ssh}} フォルダにユーザーがアクセスできるようにする:
 
  +
$ chown -R $USER ~/.ssh
 
  +
</nowiki>}}
$ chmod 700 /home/USER/.ssh
 
  +
# クライアントの公開鍵 (例: {{ic|id_rsa.pub}}) がサーバーの {{ic|~/.ssh/authorized_keys}} に存在することを確認する。
$ chmod 600 /home/USER/.ssh/*
 
  +
# [[#デーモン|サーバーの設定]]で {{ic|AllowUsers}} や {{ic|AllowGroups}} によって SSH によるアクセスが制限されていることを確認する。
 
  +
# ユーザーにパスワードが設定されていることを確認する。新しいユーザーにはパスワードが設定されていない可能性があります。
2. ライアントとサーバーの {{ic|~/.ssh}} フォルダにある全てのファイルの所有者がユーザーになっていることを確認:
 
  +
# {{ic|sshd}} を再起動してクライアントとサーバーの両方で一度ログアウトをしてみる。
 
$ chown -R USER: /home/USER/.ssh
 
 
3. クライアントの公開鍵を確認。サーバーの {{ic|authorized_keys}} やユーザーの {{ic|~/.ssh/}} ファイルにある {{ic|id_rsa.pub}} ファイルなど。
 
 
4. {{ic|/etc/ssh/sshd_config}} の {{ic|AllowUsers or AllowGroups}} オプションで SSH のアクセスが制限されていないか確認。
 
 
5. ユーザーにパスワードが設定されていることを確認。新しいユーザーを追加したあとパスワードが設定されていなかったり一度もログインされてなかったりすることがあります。
 
 
==== SSH を再起動 + ユーザーの再ログイン ====
 
 
6. {{ic|sshd}} (サーバー) を[[再起動]]。
 
 
7. クライアントとホスト、両方でユーザー (シェル) の再ログイン。
 
 
==== 期限切れのキーを削除 (任意) ====
 
 
8. Delete old/invalid key rows in server's {{ic|~/.ssh/authorized_keys}} file.
 
 
9. Delete old/invalid private and public keys within the clients {{ic|~/.ssh}} folder.
 
 
==== 推奨事項 ====
 
 
10. Keep as few keys as possible in user's {{ic|~/.ssh/authorized_keys}} file on the server.
 
 
11. Secure server's {{ic|/home/USER/.ssh/authorized_keys}} file against manipulation:
 
 
$ chmod 400 /home/USER/.ssh/authorized_keys
 
   
 
=== 電源オフ/再起動した後も SSH 接続が残ってしまう ===
 
=== 電源オフ/再起動した後も SSH 接続が残ってしまう ===
 
systemd が sshd の前に network を停止してしまうと電源を切った後も SSH 接続が繋がったままになります。この問題を修正するには、{{ic|After}} ステートメントを修正してください:
 
systemd が sshd の前に network を停止してしまうと電源を切った後も SSH 接続が繋がったままになります。この問題を修正するには、{{ic|After}} ステートメントを修正してください:
{{hc|/usr/lib/systemd/system/systemd-user-sessions.service|2=
+
{{hc|# systemctl edit systemd-user-sessions.service|2=
  +
[Unit]
#After=remote-fs.target
 
 
After=network.target}}
 
After=network.target}}
   
492行目: 446行目:
 
==== ルーターがポートフォワーディングをしていないか? ====
 
==== ルーターがポートフォワーディングをしていないか? ====
   
  +
NAT モードやルーターを使っている場合、ルーターが ssh 接続を転送していないか確認してください。サーバーの内部 IP アドレスは {{ic|$ ip addr}} で確認することができるので、SSH ポートの TCP をその IP に転送するようにルーターを設定してください。[http://portforward.com portforward.com] も役に立ちます。
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 [http://portforward.com/] for more instructions on how to do so for your particular router.
 
   
 
==== SSH が動作しているか? ====
 
==== SSH が動作しているか? ====
517行目: 463行目:
 
ファイアウォールの設定に関する詳細は[[ファイアウォール]]を見て下さい。
 
ファイアウォールの設定に関する詳細は[[ファイアウォール]]を見て下さい。
   
  +
==== トラフィックがコンピュータにまで到達しているか? ====
==== 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
 
# tcpdump -lnn -i any port ssh and tcp-syn
   
  +
上記は基本的な情報を表示します。トラフィックが表示されるまで待ってください。その後、接続を試行してみてください。何も出力がされない場合、コンピュータの外側にある何かがトラフィックを妨害しています (例: ハードウェアファイアウォールや NAT ルーターなど)。
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 またはサードパーティによってデフォルトのポートがブロックされてないか? ====
 
==== ISP またはサードパーティによってデフォルトのポートがブロックされてないか? ====
{{Note|このステップは次のことを確認した後で実行してください。ファイアーウォールを何も起動していないこと。DMZ へのルータを正しく設定している、またはコンピュータへポートを転送していること。それでもまだ動かない場合ここで診断のステップと解決法が見つかるでしょう。}}
+
{{Note|このステップは次のことを確認した後で実行してください。ファイアーウォールを何も起動していないこと。DMZ へのルータを正しく設定している、またはコンピュータへポートを転送していること。それでもまだ動かない場合ここで診断のステップと解決法が見つかるでしょう。}}
   
ときどき ISP(インターネット・サービス・プロバイダが SSH のデフォルトポート(22をブロックしている場合があります。この場合はあなたが何をしてもポートを開ける、スタックを強化する、フラッドアタックを防御する、など無意味になります。確認するために、全てのインターフェイス(0.0.0.0)をリッスンする sshd を立ち上げ、リモートから接続してみます。
+
ときどき ISP (インターネット・サービス・プロバイダ) が SSH のデフォルトポート (22) をブロックしている場合があります。この場合はあなたが何をしても (ポートを開ける、スタックを強化する、フラッドアタックを防御する、など) 無意味になります。ブロックさているかどうか確認するために、全てのインターフェイス (0.0.0.0) をリッスンする sshd を立ち上げ、リモートから接続してみます。
   
 
このようなエラーメッセージが出る場合:
 
このようなエラーメッセージが出る場合:
 
ssh: connect to host www.inet.hr port 22: Connection refused
 
ssh: connect to host www.inet.hr port 22: Connection refused
   
これはそのポートが ISP にブロックされていないが、サーバのそのポートで SSH が起動していないことを意味します
+
これはそのポートが ISP にブロックされていないが、そのポートでサーバーの SSH が起動していないことを意味します ([[wikipedia:Security_through_obscurity|security through obscurity]] を参照)。
([[wikipedia:Security_through_obscurity|security through obscurity]] を参照)。
 
   
 
しかし、次のようなエラーメッセージが出る場合:
 
しかし、次のようなエラーメッセージが出る場合:
 
ssh: connect to host 111.222.333.444 port 22: Operation timed out
 
ssh: connect to host 111.222.333.444 port 22: Operation timed out
   
これは何かがポート 22 での TCP トラフィックを拒否(reject)していることを意味します。そのポートはあなたのサーバ上のファイアーウォールか第三者(ISP などのどちらかによってステルスされています。自分のサーバでファイアーウォールが起動していないことが確かなら、またルータやスイッチの中でグレムリンが育っていないことが確かなら、ISP がトラフィックをブロックしています。
+
これは何かがポート 22 での TCP トラフィックを拒否 (reject) していることを意味します。そのポートはあなたのサーバ上のファイアーウォールか第三者 (ISP など) のどちらかによってステルスされています。自分のサーバでファイアーウォールが起動していないことが確かなら、またルータやスイッチの中でグレムリンが育っていないことが確かなら、ISP がトラフィックをブロックしています。
   
ダブルチェックのために、サーバ上で Wireshark を起動を起動してポート 22 でのトラフィックをリッスンしてみましょう。Wireshark はレイヤ 2 のパケット・スニファリング・ユーティリティであり、TCP/UDP はレイヤ 3 以上なので[[wikipedia:Internet protocol suite|IP Network stack]]を参照、もしリモートから接続するときに何も受け取っていなければ、十中八九、第三者がブロックしています。
+
ダブルチェックのために、サーバ上で Wireshark を起動してポート 22 でのトラフィックをリッスンしてみましょう。Wireshark はレイヤ 2 のパケット・スニファリング・ユーティリティであり、TCP/UDP はレイヤ 3 以上なので ([[wikipedia:ja:インターネット・プロトコル・スイート|IP ネットワークスタック]]を参照)、もしリモートから接続するときに何も受け取っていなければ、十中八九、第三者がブロックしています。
   
 
===== 問題診断 =====
 
===== 問題診断 =====
561行目: 506行目:
 
そしてこのファイル中の他の Port 設定をコメントアウトします。「Port 22」をコメントにして「Port 1234」を追加するだけでは、sshd がポート 1234 しかリッスンしなくなるので、この問題は解決しません。この 2 行どちらも使用し、sshd が両方のポートをリッスンするようにします。
 
そしてこのファイル中の他の Port 設定をコメントアウトします。「Port 22」をコメントにして「Port 1234」を追加するだけでは、sshd がポート 1234 しかリッスンしなくなるので、この問題は解決しません。この 2 行どちらも使用し、sshd が両方のポートをリッスンするようにします。
   
あとは {{ic|systemctl restart sshd.service}} で sshd を起動するだけです。そして ssh クライアントでも同じポートに変更します。問題に対する解決方法は多数存在しますが、ここでは2つの解決方法を紹介します。
+
あとは {{ic|systemctl restart sshd.service}} で sshd を起動するだけです。そして ssh クライアントでも同じポートに変更します。
   
 
==== Read from socket failed: connection reset by peer ====
 
==== Read from socket failed: connection reset by peer ====
575行目: 520行目:
 
openssh バグフォーラムの [http://www.gossamer-threads.com/lists/openssh/dev/51339 議論] も参照。
 
openssh バグフォーラムの [http://www.gossamer-threads.com/lists/openssh/dev/51339 議論] も参照。
   
=== "[your shell]: No such file or directory" / ssh_exchange_identification problem ===
+
=== "[your shell]: No such file or directory" / ssh_exchange_identification 問題 ===
  +
シェルのバイナリに {{Ic|$PATH}} が通っている場合でも、特定の SSH クライアントは {{Ic|$SHELL}} に絶対パスを設定する必要があります (パスは {{Ic|whereis -b [your shell]}} で確認できます)。
One possible cause for this is the need of certain SSH clients to find an absolute path (one returned by {{Ic|whereis -b [your shell]}}, for instance) in {{Ic|$SHELL}}, even if the shell's binary is located in one of the {{Ic|$PATH}} entries.
 
   
 
==="Terminal unknown" や "Error opening terminal" エラーメッセージ===
 
==="Terminal unknown" や "Error opening terminal" エラーメッセージ===
ssh でログイン時に "Terminal unknown" のようなエラーが表示されることがあります。nano などの ncurses アプリケーションを実行すると "Error opening terminal" というメッセージが表示されます。この問題を解決する方法は2つあります。{{ic|$TERM}} 変数を使って簡単に修正する方法と terminfo ファイルを使って根本的に解決する方法です。
+
ssh でログイン時に "Terminal unknown" のようなエラーが表示されることがあります。これはサーバーがターミナルを認識できていないことを意味します。また、nano などの ncurses アプリケーションを実行すると "Error opening terminal" というメッセージが表示されます。
   
  +
クライアントで使用しているターミナルの terminfo ファイルをサーバーにインストールするのが正しい解決方法です。これによってサーバーのコンソールプログラムがターミナルを正しく扱えるようになります。{{ic|infocmp}} を実行してから[[Pacman#パッケージ・データベースに問い合わせる|パッケージを確認]]することで terminfo に関する情報を取得できます。
====$TERM 変数を設定する解決策====
 
リモートサーバーに接続した後に以下のコマンドを使って {{ic|$TERM}} 変数を "xterm" に設定してください:
 
   
  +
通常の方法でファイルを[[インストール]]できない場合、サーバーのホームディレクトリに terminfo をコピーしてください:
$ TERM&#61;xterm
 
   
  +
$ ssh myserver mkdir -p ~/.terminfo/${TERM:0:1}
この方法はあくまで次善策であり、たまにしか接続しない ssh サーバーで使うようにしてください。良くない副作用があるからです。また、接続するたびにコマンドを実行する必要があります。もしくは {{ic|~.bashrc}} で設定してください。
 
  +
$ scp /usr/share/terminfo/${TERM:0:1}/$TERM myserver:~/.terminfo/${TERM:0:1}/
   
  +
サーバーから一度ログアウトしてからログインしなおすと問題が解決しているはずです。
====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:
 
   
  +
====$TERM 変数を設定する解決策====
$ mkdir -p ~/.terminfo/r/
 
   
  +
{{Warning|この方法はあくまで次善策であり、たまにしか接続しない ssh サーバーで使うようにしてください。}}
Now copy the terminfo file of your terminal to the new directory. Replace {{ic|rxvt-unicode-256color}} with your client's terminal in the following command and {{ic|ssh-server}} with the relevant user and server adress.
 
   
  +
{{ic|.bash_profile}} などで {{ic|1=TERM=xterm}} と設定することでもエラーが表示されなくなり、ncurses アプリケーションが動作するようになります。ただし副作用があり、ターミナルの制御シーケンスが xterm と異なっている場合グラフィックがおかしくなります。
$ 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.
 
   
 
=== Connection closed by x.x.x.x [preauth] ===
 
=== Connection closed by x.x.x.x [preauth] ===
606行目: 547行目:
 
=== OpenSSH 7.0 によって id_dsa が拒否される ===
 
=== OpenSSH 7.0 によって id_dsa が拒否される ===
   
OpenSSH 7.0 では ssh-dss が無効になっており、http://www.openssh.com/legacy.html には id_dsa 鍵が使われている場合にサーバーにアクセスする方法が書かれていません:
+
OpenSSH 7.0 ではセキュリティ上の理由から ssh-dss が無効になっています。どうしても有効にする必要がある場合クライアントの設定オプションを使用してください ([http://www.openssh.com/legacy.html] には書かれていない方法です):
   
 
PubkeyAcceptedKeyTypes +ssh-dss
 
PubkeyAcceptedKeyTypes +ssh-dss
   
  +
=== OpenSSH 7.0 で No matching key exchange method found ===
While this can be added a per host basis or with -o, to make sure "ProxyCommand ssh" still works, add it to ssh_config.
 
 
=== no matching key exchange method found by OpenSSH 7.0 ===
 
 
OpenSSH 7.0 also deprecated the key algorithm diffie-hellman-group1-sha1, as we could see in http://www.openssh.com/legacy.html.
 
 
If the client and server are unable to agree on a mutual set of parameters then the connection will fail. OpenSSH (7.0 and greater) will produce an error message like this:
 
 
Unable to negotiate with 127.0.0.1: no matching key exchange method found.
 
Their offer: diffie-hellman-group1-sha1
 
   
  +
OpenSSH 7.0 では Logjam 攻撃からの(理論上の)脆弱性を理由に diffie-hellman-group1-sha1 鍵アルゴリズムが無効になっています (http://www.openssh.com/legacy.html を参照)。特定のホストで鍵アルゴリズムが必要な場合、ssh は以下のようなエラーメッセージを吐きます:
In this case, the client and server were unable to agree on the key exchange algorithm. The server offered only a single method diffie-hellman-group1-sha1. OpenSSH supports this method, but does not enable it by default because is weak and within theoretical range of the so-called Logjam attack.
 
   
  +
Unable to negotiate with 127.0.0.1: no matching key exchange method found.
The best resolution for these failures is to upgrade the software at the other end. OpenSSH only disables algorithms that we actively recommend against using because they are known to be weak. In some cases, this might not be immediately possible so you may need to temporarily re-enable the weak algorithms to retain access.
 
  +
Their offer: diffie-hellman-group1-sha1
   
  +
古いアルゴリズムを使用しないようにサーバーをアップグレード・設定することで上記のエラーは解決します。サーバー側の設定を変更できない場合、クライアント設定で {{ic|KexAlgorithms +diffie-hellman-group1-sha1}} オプションを使うことでアルゴリズムを有効化できます。
For the case of the above error message, OpenSSH can be configured to enable the diffie-hellman-group1-sha1 key exchange algorithm (or any other that is disabled by default) using the KexAlgorithm option - either on the command-line:
 
   
  +
=== SSH から切断したときに tmux/screen セッションが終了する ===
ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 user@127.0.0.1
 
   
  +
セッションの最後にプロセスが終了する場合、ソケットアクティベーションを使っているために SSH セッションプロセスが終了したときに {{Pkg|systemd}} によって終了されている可能性があります。{{ic|ssh.socket}} の代わりに {{ic|ssh.service}} を使用してソケットアクティベーションを使わないことで解決できます。もしくは {{ic|ssh@.service}} の Service セクションで {{ic|1=KillMode=process}} を設定してください。
or in the ~/.ssh/config file:
 
   
  +
{{ic|1=KillMode=process}} は古典的な {{ic|ssh.service}} でも役に立つことがあります。サーバーが停止したり再起動したときに SSH セッションプロセスや {{Pkg|screen}} や {{Pkg|tmux}} のプロセスが終了されることを防ぐことができます。
Host somehost.example.org
 
KexAlgorithms +diffie-hellman-group1-sha1
 
   
 
== 参照 ==
 
== 参照 ==

2017年10月12日 (木) 23:16時点における版

関連記事

Secure Shell (SSH) は暗号技術を利用して、安全にリモートコンピュータと通信するためのネットワークプロトコルです。暗号によってデータの機密性と完全性が保証されます。SSH は公開鍵暗号を使ってリモートコンピュータを認証し、リモートコンピュータは必要に応じてユーザーを認証します。

基本的に SSH はリモートマシンにログインしてコマンドを実行するために使われますが、トンネリングや TCP ポートや X11 接続の任意のフォワーディングをサポートしており、SFTP や SCP プロトコルを使うことでファイル転送をすることも可能です。

デフォルトでは、SSH サーバーは標準の TCP 22番ポートを使います。通常は SSH クライアントプロトコルを使って sshd デーモンの接続を確立してリモート接続を承認します。macOS, GNU/Linux, Solaris, OpenVMS など近代的なオペレーティングシステムのほとんどでサーバーとクライアントの両方が備わってします。複雑なもの・完全なものまで様々なレベルのバージョンがプロプライエタリ・フリーウェア・オープンソースを問わずに存在します。

目次

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
ノート: バージョン 7.0p1 からは PermitRootLogin prohibit-password がデフォルトになっています。man sshd_config を参照。

ウェルカムメッセージを追加するには /etc/issue ファイルを編集して Banner 行を次のように変更してください:

Banner /etc/issue

ホスト鍵は sshd の systemd サービスによって自動的に生成されます。sshd に特定の鍵を使用させたい場合、手動で設定します:

HostKey /etc/ssh/ssh_host_rsa_key

サーバーに WAN からアクセスできる場合、デフォルトのポートである 22 から別のランダムなポートに変更することが推奨されています:

Port 39901
ノート: OpenSSH では設定ファイルに Port x 行を複数記述することで複数のポートを使うことができます。

パスワードによるログインを使わないようにすればセキュリティは大幅に向上します。詳しくは SSH 鍵#パスワードログインの無効化 を見て下さい。

sshd デーモンの管理

次のコマンドで sshd デーモンを起動することができます:

# systemctl start sshd.service

次のコマンドで sshd デーモンを起動時に有効にすることができます:

# systemctl enable sshd.service

詳しくは systemd#ユニットを使う を見て下さい。

警告: Systemd は非同期にプロセスを実行します。SSH デーモンを特定の IP アドレス ListenAddress 192.168.1.100 に結びつけている場合、デフォルトの sshd.service ユニットファイルはネットワークインターフェイスが有効にされることに依存していないため、ブート中にロードが失敗する可能性があります。IP アドレスをバインドする時は、カスタムした sshd.service ユニットファイルに After=network.target を追加してください。systemd#ユニットファイルの編集 を参照。

また SSH デーモンソケットを有効にすることで初めて接続があったときにデーモンが起動するようにすることもできます:

# systemctl start sshd.socket
# systemctl enable sshd.socket

デフォルトの22番以外のポートを使う場合、ユニットファイルを編集する必要があります:

# systemctl edit sshd.socket
[Socket]
ListenStream=
ListenStream=12345
警告: sshd.socket を使用すると ListenAddress の設定が打ち消されて、どのアドレスからでも接続できるようになってしまいます。ListenAddress の設定を適用するには、ListenStream でポートと IP を指定する必要があります (例: ListenStream=192.168.1.100:22)。また、[Socket] の下に FreeBind=true を追加するようにしてください。そうしないと IP アドレスの設定が ListenAddress の設定と同じように無効になってしまいます: ネットワークが立ち上がっていない場合にソケットの起動が失敗します。
ヒント: ソケットアクティベーションを使う場合、sshd.socket でもデーモンの標準の sshd.service でもログの接続試行を監視することはできません。ただし # journalctl /usr/bin/sshd を実行することで監視できます。

サーバーに接続する

サーバーに接続するには、次を実行してください:

$ ssh -p port port user@server-address

SSH の保護

管理業務のために SSH によるリモートログインを許可することは良いことですが、サーバーのセキュリティに脅威を及ぼすことにもなりえます。総当り攻撃の標的になりやすいので、SSH のアクセスは制限して、第三者がサーバーにアクセスできないようにする必要があります。

  • わかりにくいアカウント名やパスワードを使う
  • 信頼できる国からの SSH 接続だけを許可する
  • fail2bansshguard をつかってブルートフォース攻撃を監視し、総当りを起こっている IP を閉め出す

ブルートフォースアタックからの保護

ブルートフォースは単純な攻撃方法です: ランダムなユーザー名とパスワードの組み合わせをとにかく沢山作ってウェブページや SSH などのサーバーログインプロンプトにログインを絶えず試行します。ブルートフォース攻撃からは fail2bansshguard などの自動スクリプトを使うことで攻撃者をブロックすることで身を守ることができます。Uncomplicated Firewall#ufw によるレート制限も参照。

もしくは、公開鍵認証を使うことでブルートフォース攻撃を出来なくすることもできます。sshd_config に次の設定を追加:

PasswordAuthentication no
ChallengeResponseAuthentication no

上の設定を適用する前に、SSH アクセスが必要な全てのアカウントで authorized_keys ファイルに公開鍵認証の設定をするようにしてください。詳しくは SSH 鍵#リモートサーバーに公開鍵をコピー を参照。

2段階認証

SSH 鍵のペアによる認証を使用していてパスワードによろうログインを無効化している場合に、2段階認証を使いたいときは Google AuthenticatorSSH 鍵#2段階認証と公開鍵 を見て下さい。

root ログインを制限する

一般的に、SSH で無制限に root ログインを許可することは推奨されません。セキュリティの向上のために、SSH での root ログインを制限する方法は2つ存在します。

root ログインを拒否する

Sudo を使うことで、root アカウントの認証を行うことなく、必要に応じて root 権限を選択的に付与することができます。このため SSH による root ログインを拒否して、攻撃者にパスワードに加えて (root でない) ユーザー名も推測させる必要を生じさせることで、ブルートフォース攻撃を困難にすることが可能です。

/etc/ssh/sshd_config の "Authentication" セクションを編集することで SSH からの root ログインを拒否するように設定できます。#PermitRootLogin prohibit-passwordno に変更して行をアンコメントしてください:

/etc/ssh/sshd_config
PermitRootLogin no
...

そして、SSH デーモンを再起動してください。

これで、SSH を使って root でログインすることはできなくなります。ただし、通常ユーザーでログインしてから susudo を使ってシステム管理を行うことは依然として可能です。

root ログインを限定する

自動的な作業の中にも、リモートによるフルシステムバックアップなど、root 権限を必要とするものがあります。セキュアな方法で root を許可したい場合、SSH による root ログインを無効化する代わりに、特定のコマンドだけ root ログインを許可することができます。~root/.ssh/authorized_keys を編集して、以下のように特定のキーの前にコマンドを記述します:

command="/usr/lib/rsync/rrsync -ro /" ssh-rsa …

上記の設定で、特定の鍵を使ってログインした場合はクォートで囲ったコマンドを実行できるようになります。

ログイン時に root ユーザーの名前を出すことで攻撃する対象が増えてしまうことに対しては sshd_config に以下を追加することで埋め合わせができます:

PermitRootLogin forced-commands-only

上記の設定は root が SSH で実行できるコマンドを制限するだけでなく、パスワードの使用も無効化して、root アカウントでは強制的に公開鍵認証を使うようになります。

root で使えるコマンドは制限しないで公開鍵認証の強制だけをするという手もあり、それでもブルートフォース攻撃はほぼ不可能です。その場合、以下を設定:

PermitRootLogin without-password

他の SSH クライアントとサーバー

OpenSSH の他にも、多数の SSH クライアントサーバーが存在します。

Dropbear

Dropbear は SSH-2 クライアント・サーバーです。dropbear公式リポジトリから利用可能です。

コマンドラインの ssh クライアントは dbclient という名前が付けられています。

Mosh

Mosh の ウェブサイト より:

ローミングが可能で、断続的な接続もサポートしているリモート端末アプリケーションです。ユーザーのキーストロークのローカルエコーと行編集を提供します。Mosh は SSH の代替です。SSH よりも強固でレスポンスが早く、特に Wi-Fi や携帯端末からの接続、長距離通信など通信速度が遅い場合に役に立ちます。

公式リポジトリから moshインストールするか AUR にある最新版 mosh-gitAUR を使って下さい。

Mosh にはドキュメントに記載されていないコマンドラインオプション --predict=experimental が存在し、よりアグレッシブにローカルのキーストロークのエコーを生成します。キーボード入力が遅延なく確認できるのに興味があるのであればこの prediction モードを使ってみて下さい。

ヒントとテクニック

暗号化 SOCKS トンネル

暗号化トンネルは信頼ができない様々なワイヤレス接続を使用するノートパソコンなどで非常に有用です。必要なのは SSH サーバーが安全な場所 (家や仕事場など) で動作していることだけです。DynDNS などのダイナミック DNS サービスを利用すれば IP アドレスを覚える必要もありません。

手順 1: 接続の開始

以下のコマンドを実行することで接続を開始できます:

$ ssh -TND 4711 user@host

user はユーザー名に host は SSH サーバーが動作しているホストに置き換えてください。パスワードを入力すると接続が行われます。N フラグはインタラクティブプロンプトを無効化し、D フラグは listen するローカルポートを指定します (ポート番号は何でもかまいません)。T フラグは疑似 tty アロケーションを無効化します。

verbose (-v) フラグを追加することで、接続が成功していることを出力から確認することができます。

手順 2: ブラウザ (やその他のプログラム) の設定

新しく作成した socks トンネルを使用するようにウェブブラウザ (や他のプログラム) を設定しないと上記の作業は無意味です。最新バージョンの SSH は SOCKS4 と SOCKS5 に対応しているため、どちらかを使うことができます。

  • Firefox の場合: 編集 → 設定 → 詳細 → ネットワーク → 接続 → 接続設定:
ラジオボタンの手動でプロキシを設定するにチェックを入れて、SOCKS ホストテキストフィールドに localhost と、次のテキストフィールドにポート番号を入力してください (上の例では 4711)。

Firefox はデフォルトでは DNS リクエストの作成に socks トンネルを使用しません。以下の手順で設定することでプライバシーを守ることができます:

  1. Firefox のロケーションバーに about:config と入力。
  2. network.proxy.socks_remote_dns を検索。
  3. 値を true に設定。
  4. ブラウザを再起動。
  • Chromium の場合: 環境変数やコマンドラインオプションで SOCKS の設定ができます。以下の関数を .bashrc に追加することを推奨します:
function secure_chromium {
    port=4711
    export SOCKS_SERVER=localhost:$port
    export SOCKS_VERSION=5
    chromium &
    exit
}

もしくは:

function secure_chromium {
    port=4711
    chromium --proxy-server="socks://localhost:$port" &
    exit
}

ターミナルから以下のように実行してください:

$ secure_chromium

X11 フォワーディング

X11 フォワーディングはリモートシステムで X11 プログラムを動作させて、グラフィカルインターフェイスをローカルのクライアントマシンで表示させるメカニズムです。X11 フォワーディングではリモートホストに X11 システムを完全にインストールさせる必要はなく、xauth をインストールするだけで十分です。xauth は、、X11 セッションの認証を行うために必要なサーバーとクライアントによって使用される Xauthority の設定を管理するユーティリティです (ソース)。

警告: X11 フォワーディングにはセキュリティ的に重要な問題があります。ssh, sshd_config, ssh_config のマニュアルページの該当するセクションを読んで最低限の知識をつけてください。こちらの記事 も参照。

セットアップ

リモート側:

  • 公式リポジトリから xorg-xauthxorg-xhostインストール
  • /etc/ssh/sshd_config 内:
    • AllowTcpForwardingX11UseLocalhost オプションを yes に設定し、X11DisplayOffset10 に設定 (何も変更を加えてなければこの値がデフォルトになっています、man sshd_config を参照)
    • X11Forwardingyes に設定
  • sshd デーモン再起動
  • リモートシステムでも X サーバーを動作させる必要があります。

クライアント側では、接続するたびにコマンドラインで -X スイッチを指定して ForwardX11 オプションを有効にするか、openSSH クライアントの設定ファイルForwardX11yes に設定してください。

ヒント: GUI の描画がおかしい場合やエラーが表示されるときは ForwardX11Trusted オプションを有効にできます (コマンドラインでは -Y スイッチ)。X11 フォワーディングが X11 SECURITY 拡張 の制御から外れるようになります。使用するときはセクション冒頭の警告を読んでください。

使用方法

通常通りリモートマシンにログインします、クライアント側の設定ファイルで ForwardX11 を有効にしていない場合は -X スイッチを指定します:

$ ssh -X user@host

グラフィカルなアプリケーションを実行しようとするとエラーが表示される場合、代わりに ForwardX11Trusted を試してみて下さい:

$ ssh -Y user@host

リモートサーバーで X プログラムが起動できるようになったら、出力がローカルセッションに転送されます:

$ xclock

"Cannot open display" エラーが表示される場合、root 以外のユーザーで以下のコマンドを実行してみてください:

$ xhost +

上記のコマンドは全てのユーザーに X11 アプリケーションの転送を許可します。特定のホストだけに転送を制限するには:

$ xhost +hostname

hostname は転送先のホストの名前に置き換えてください。詳しくは man xhost を参照。

特定のアプリケーションではローカルマシンでインスタンスが動作しているかチェックが実行されます。例えば Firefox は以下の起動パラメータを使用してローカルマシンでリモートインスタンスを起動する必要があります:

$ firefox --no-remote

接続時に "X11 forwarding request failed on channel 0" と表示される場合 (サーバーの /var/log/errors.log に "Failed to allocate internet-domain X11 display socket" と出力される場合)、xorg-xauth パッケージがインストールされていることを確認してください。上手く機能しない場合、以下の設定を試してみてください:

  • サーバーの sshd_configAddressFamily any オプションを有効にする。
  • サーバーの sshd_configAddressFamily オプションを inet に設定する。

IPv4 で Ubuntu クライアントを使っている場合は inet に設定することで問題が解決します。

SSH サーバーの他のユーザーで X アプリケーションを実行するには SSH でログインしているユーザーの xauth list の認証行を xauth add する必要があります。

他のポートのフォワーディング

SSH は X11 をサポートしているだけでなく、TCP 接続のセキュアなトンネル化に使用することもできます。ローカルフォワーディングとリモートフォワーディングの両方が使えます。

ローカルフォワーディングはローカルマシンのポートを開いて、リモートホストに接続が転送されます。転送先をリモートホストと同じにすることで、同一マシンでセキュアな VNC 接続などができます。ローカルフォワーディングは -L スイッチで利用することができ <tunnel port>:<destination address>:<destination port> という形式で転送先を指定します:

$ ssh -L 1000:mail.google.com:25 192.168.0.100

上記のコマンドは SSH で 192.168.0.100 にログインしてシェルを開きます。そしてローカルマシンの TCP ポート 1000 から mail.google.com のポート 25 にトンネルが作成されます。接続が確立すると localhost:1000 への通信は Gmail の SMTP ポートに接続されます。Google から見ると、192.168.0.100 から接続が来ているように見えます (必ずしも接続と一緒にデータが運ばれるとは限りません)。データはローカルマシンと 192.168.0.100 の間は安全に運ばれます。

同じように以下のコマンドは localhost:2000 に接続することができ、リモートホストのポート 6001 に透過的に送信されます:

$ ssh -L 2000:192.168.0.100:6001 192.168.0.100

前者の例はセキュリティ上問題がある (tightvncAUR パッケージに含まれている) vncserver ユーティリティによる VNC 接続などで有用です。

リモートフォワーディングは SSH トンネルとローカルマシンを通してリモートホストから任意のホストに接続できるようにします。ローカルフォワーディングとは逆の機能であり、ファイアウォールによってリモートホストの接続が限られている場合などに有用です。リモートフォワーディングは -R スイッチで使うことができ <tunnel port>:<destination address>:<destination port> という形式で転送先を指定します:

$ ssh -R 3000:irc.freenode.net:6667 192.168.0.200

上記のコマンドは 192.168.0.200 にシェルを立ち上げて、192.168.0.200 からローカルホストの3000番ポートへの接続をトンネルを通して送信し、それから irc.freenode.net のポート 6667 に転送します。ポート 6667 がブロックされている場合でもリモートホストから IRC プログラムを利用することができるようになります。

ローカルフォワーディングとリモートフォワーディングはどちらもセキュアなゲートウェイとして使用することができます。<tunnel address>:<tunnel port>:<destination address>:<destination port> のようにバインドアドレスをつかうことで、SSH や SSH デーモンを動かしていなくても他のコンピュータが SSH トンネルを利用することが可能です。<tunnel address> はトンネルの入り口となるマシンのアドレスです: localhost, * (あるいは空)。特定のアドレス経由の接続、ループバックインターフェイス経由の接続、全てのインターフェイス経由の接続を許可します。デフォルトでは、フォワーディングはトンネルの入り口のマシンからの接続だけに制限されており <tunnel address>localhost に設定されています。ローカルフォワーディングは特に設定が必要ありませんが、リモートフォワーディングはリモートサーバーの SSH デーモンの設定によって制限を受けます。詳しくは sshd_config(5)GatewayPorts オプションを見てください。

踏み台ホスト

場合によっては、接続先の SSH デーモンに直接接続できず、踏み台サーバー (ジャンプサーバー) を使わざるを得ないことがあります。ふたつ以上の SSH トンネルを接続して、それぞれのサーバーに対してローカルの鍵で認証します。SSH エージェントの転送 (-A) と疑似端末の割当 (-t) を使って以下のようにローカルの鍵を転送します:

$ ssh -A -t -l user1 bastion1 \
  ssh -A -t -l user2 intermediate2 \
  ssh -A -t -l user3 target

以下のように -J フラグを使用することもできます:

$ ssh -J user1@bastion1,user2@intermediate2 user3@target

-J ディレクティブで指定するホストはカンマで区切り、指定された順番で接続されます。user...@ の部分は必須ではありません。-J で指定したホストは ssh の設定ファイルを使うため、必要であればホスト毎にオプションを設定することが可能です。

マルチプレクス

SSH デーモンは通常はポート 22 番をリッスンします。しかし、公共のインターネット・ホットスポットでは HTTP/HTTPS のポート(80 と 443)以外のトラフィックをブロックしていることが一般的です。そのため SSH 接続がブロックされてしまいます。すぐできる解決策として、許可されているポートで sshd を起動するという方法があります:

/etc/ssh/sshd_config
Port 22
Port 443

しかしポート 443 番は HTTPS を提供する Web サーバにすでに使われていることが多いです。その場合は sslh のようなマルチプレクサを使います。これは指定ポートをリッスンし、そこに来るパケットを複数のサービスに賢く振り分けることができます。

SSH の高速化

ヒント: SSH を SFTP や SCP で使用する場合、openssh-hpn-gitAUR をインストールすることで転送速度を劇的に上げることができます [1]

同一のホストのセッションは全て単一の接続を使うようにすることで、後のログインを劇的に高速化することができます。/etc/ssh/ssh_config$HOME/.ssh/config の適当なホストの下に以下の行を追加してください:

ControlMaster auto
ControlPersist yes
ControlPath ~/.ssh/sockets/socket-%r@%h:%p

~/.ssh/sockets は他のユーザーが書き込めないディレクトリなら何でもかまいません。

ControlPersist はクライアントとの接続を閉じるまでにどれくらい待機するか指定します。yes で永遠に待ち続け、no で接続を即座に終了します。秒数で指定することもできます。

警告: ControlPersistyes に設定すると接続が自動的に終了しなくなるので注意してください。

速度を向上させる別のオプションとして圧縮を有効化する -C フラグがあります。/etc/ssh/ssh_config の適切なホストの下に次の行を追加することで永続的に設定することができます:

Compression yes
警告: ssh(1) には「モデム接続など接続速度が遅い場合は圧縮の効果がありますが、高速なネットワークではむしろ通信が遅くなります」と書かれています。ネットワーク環境によっては圧縮は逆効果です。

ログイン時刻は AddressFamily inet オプションや -4 フラグを使って IPv6 ルックアップを迂回することで短くできます。

SSHFS でリモートファイルシステムをマウントする

sshfs を使って (SSH でアクセスした) リモートのファイルシステムをローカルフォルダにマウントする方法は Sshfs の記事を参照してください。マウントしたファイルは様々なツールであらゆる操作することができます (コピー、名前の変更、vim で編集など)。基本的に shfs よりも sshfs を使用することを推奨します。sshfs は shfs の新しいバージョンであり、元の shfs は2004年から更新されていません。

ヒント: ログイン時に自動的に autosshfs を実行する autosshfs-gitAUR パッケージも存在します。

Keep alive

一定時間操作がないと ssh セッションは自動的にログアウトします。接続を維持するには以下をクライアントの ~/.ssh/config/etc/ssh/ssh_config に追加してください:

ServerAliveInterval 120

これで120秒ごとに "keep alive" シグナルがサーバーに送信されます。ServerAliveCountMaxTCPKeepAlive オプションも参照してください。

反対に、外部からの接続を維持するには、次をサーバーの /etc/ssh/sshd_config に設定します (数字は0より大きく):

ClientAliveInterval 120

systemd で SSH トンネルを自動的に再起動

systemd を使ってブート時/ログイン時に SSH 接続を自動的に開始して、接続が失敗した時に再起動させることができます。SSH トンネルの管理に役立つツールとなります。

以下のサービスでは、ssh の設定に保存された接続設定を使って、ログイン時に SSH トンネルを開始します。接続が何らかの理由で閉じられた場合、10秒待機してから再起動します:

~/.config/systemd/user/tunnel.service
[Unit]
Description=SSH tunnel to myserver

[Service]
Type=simple
Restart=always
RestartSec=10
ExecStart=/usr/bin/ssh -F %h/.ssh/config -N myserver

上記のユーザーサービスを有効化して起動してください。トンネルがタイムアウトするのを防ぐ方法は #Keep alive を見て下さい。起動時にトンネルを開始したい場合、ユニットをシステムサービスとして書きなおして下さい。

Autossh - SSH セッションとトンネルの自動再起動

ネットワークの状態が悪かったりしてクライアントが切断してしまい、セッションやトンネルの接続を維持できない場合、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 

-f オプションで autossh をバックグラウンドプロセスとして実行することができます。ただし対話式でパスフレーズを入力することができなくなります。

セッション中に exit と入力したり autossh プロセスに SIGTERM, SIGINT, SIGKILL 信号が送られるとセッションは終了します。

systemd を使ってブート時に自動的に autossh を起動する

autossh を自動的に起動したい場合、以下の systemd ユニットファイルを作成します:

/etc/systemd/system/autossh.service
[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

AUTOSSH_GATETIME=0 は接続が成功して ssh が立ち上がったと autossh が認識する秒数です。0に設定すると autossh は ssh の最初の起動失敗を無視します。起動時に autossh を実行する場合は設定するべきです。他の環境変数は man ページを見てください。必要であればもっと複雑に設定することもできますが、AUTOSSH_GATETIME=0 を含む -f は systemd では機能しません。

設定後はサービスを起動有効化してください。

以下のように ControlMaster を無効化する必要もあるかもしれません:

ExecStart=/usr/bin/autossh -M 0 -o ControlMaster=no -NL 2222:localhost:2222 -o TCPKeepAlive=yes foo@bar.com
ヒント: 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

トラブルシューティング

チェックリスト

以下は最初に行うべきトラブルシューティングのチェックリストです。何かする前に以下の問題をチェックすることを推奨します。

  1. 設定ディレクトリ ~/.ssh の中身がユーザーからアクセスできることを確認する (クライアントとサーバーの両方で確認してください):
    $ chmod 700 ~/.ssh
    $ chmod 600 ~/.ssh/*
    $ chown -R $USER ~/.ssh
    
  2. クライアントの公開鍵 (例: id_rsa.pub) がサーバーの ~/.ssh/authorized_keys に存在することを確認する。
  3. サーバーの設定AllowUsersAllowGroups によって SSH によるアクセスが制限されていることを確認する。
  4. ユーザーにパスワードが設定されていることを確認する。新しいユーザーにはパスワードが設定されていない可能性があります。
  5. sshd を再起動してクライアントとサーバーの両方で一度ログアウトをしてみる。

電源オフ/再起動した後も SSH 接続が残ってしまう

systemd が sshd の前に network を停止してしまうと電源を切った後も SSH 接続が繋がったままになります。この問題を修正するには、After ステートメントを修正してください:

# systemctl edit systemd-user-sessions.service
[Unit]
After=network.target

接続が拒否されるまたはタイムアウトする

ルーターがポートフォワーディングをしていないか?

NAT モードやルーターを使っている場合、ルーターが ssh 接続を転送していないか確認してください。サーバーの内部 IP アドレスは $ ip addr で確認することができるので、SSH ポートの TCP をその IP に転送するようにルーターを設定してください。portforward.com も役に立ちます。

SSH が動作しているか?

$ ss -tnlp

上記のコマンドで SSH ポートが開いていると表示されない場合、SSH は動作していません。/var/log/messages にエラーがないか確認してください。

接続をブロックするようなファイアウォールのルールが存在しないか?

iptables によってポート 22 の接続がブロックされている可能性があります。次のコマンドで確認してください:

# iptables -nvL

INPUT チェインのパケットを拒否するようなルールがないか見て下さい。そして、必要であれば、次のようなコマンドでポートのブロックを解除します:

# iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT

ファイアウォールの設定に関する詳細はファイアウォールを見て下さい。

トラフィックがコンピュータにまで到達しているか?

以下のように問題のコンピュータのトラフィックを収集してみてください:

# tcpdump -lnn -i any port ssh and tcp-syn

上記は基本的な情報を表示します。トラフィックが表示されるまで待ってください。その後、接続を試行してみてください。何も出力がされない場合、コンピュータの外側にある何かがトラフィックを妨害しています (例: ハードウェアファイアウォールや NAT ルーターなど)。

ISP またはサードパーティによってデフォルトのポートがブロックされてないか?

ノート: このステップは次のことを確認した後で実行してください。ファイアーウォールを何も起動していないこと。DMZ へのルーターを正しく設定している、またはコンピュータへポートを転送していること。それでもまだ動かない場合、ここで診断のステップと解決法が見つかるでしょう。

ときどき ISP (インターネット・サービス・プロバイダ) が SSH のデフォルトポート (22番) をブロックしている場合があります。この場合はあなたが何をしても (ポートを開ける、スタックを強化する、フラッドアタックを防御する、など) 無意味になります。ブロックされているかどうか確認するために、全てのインターフェイス (0.0.0.0) をリッスンする sshd を立ち上げ、リモートから接続してみます。

このようなエラーメッセージが出る場合:

ssh: connect to host www.inet.hr port 22: Connection refused

これはそのポートが ISP にブロックされていないが、そのポートでサーバーの SSH が起動していないことを意味します (security through obscurity を参照)。

しかし、次のようなエラーメッセージが出る場合:

ssh: connect to host 111.222.333.444 port 22: Operation timed out 

これは何かがポート 22 での TCP トラフィックを拒否 (reject) していることを意味します。そのポートはあなたのサーバー上のファイアーウォールか第三者 (ISP など) のどちらかによってステルスされています。自分のサーバーでファイアーウォールが起動していないことが確かなら、また、ルーターやスイッチの中でグレムリンが育っていないことが確かなら、ISP がトラフィックをブロックしています。

ダブルチェックのために、サーバ上で Wireshark を起動してポート 22 でのトラフィックをリッスンしてみましょう。Wireshark はレイヤ 2 のパケット・スニファリング・ユーティリティであり、TCP/UDP はレイヤ 3 以上なので (IP ネットワークスタックを参照)、もしリモートから接続するときに何も受け取っていなければ、十中八九、第三者がブロックしています。

問題診断

tcpdump または wireshark-cli パッケージの Wireshark をインストールしてください。

tcpdump の場合:

# tcpdump -ni interface "port 22"

Wireshark の場合:

$ tshark -f "tcp port 22" -i interface

interface は WAN 接続に使っているネットワークインターフェイスに置き換えてください (確認したいときは ip a を実行)。リモートで接続を試行してもパケットが全く受け取れない場合、ISP によってポート 22 のトラフィックがブロックされている可能性があります。

解決方法

解決方法は、単に ISP がブロックしていない他のポートを使うことです。/etc/ssh/sshd_config を編集して他のポートを使うようにしましょう。例えば次を追加します:

Port 22
Port 1234

そしてこのファイル中の他の Port 設定をコメントアウトします。「Port 22」をコメントにして「Port 1234」を追加するだけでは、sshd がポート 1234 しかリッスンしなくなるので、この問題は解決しません。この 2 行どちらも使用し、sshd が両方のポートをリッスンするようにします。

あとは systemctl restart sshd.service で sshd を起動するだけです。そして ssh クライアントでも同じポートに変更します。

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 問題

シェルのバイナリに $PATH が通っている場合でも、特定の SSH クライアントは $SHELL に絶対パスを設定する必要があります (パスは whereis -b [your shell] で確認できます)。

"Terminal unknown" や "Error opening terminal" エラーメッセージ

ssh でログイン時に "Terminal unknown" のようなエラーが表示されることがあります。これはサーバーがターミナルを認識できていないことを意味します。また、nano などの ncurses アプリケーションを実行すると "Error opening terminal" というメッセージが表示されます。

クライアントで使用しているターミナルの terminfo ファイルをサーバーにインストールするのが正しい解決方法です。これによってサーバーのコンソールプログラムがターミナルを正しく扱えるようになります。infocmp を実行してからパッケージを確認することで terminfo に関する情報を取得できます。

通常の方法でファイルをインストールできない場合、サーバーのホームディレクトリに terminfo をコピーしてください:

$ ssh myserver mkdir -p  ~/.terminfo/${TERM:0:1}
$ scp /usr/share/terminfo/${TERM:0:1}/$TERM myserver:~/.terminfo/${TERM:0:1}/

サーバーから一度ログアウトしてからログインしなおすと問題が解決しているはずです。

$TERM 変数を設定する解決策

警告: この方法はあくまで次善策であり、たまにしか接続しない ssh サーバーで使うようにしてください。

.bash_profile などで TERM=xterm と設定することでもエラーが表示されなくなり、ncurses アプリケーションが動作するようになります。ただし副作用があり、ターミナルの制御シーケンスが xterm と異なっている場合グラフィックがおかしくなります。

Connection closed by x.x.x.x [preauth]

sshd のログでこのエラーが確認できる場合、HostKey が正しく設定されているか確認してください:

HostKey /etc/ssh/ssh_host_rsa_key

OpenSSH 7.0 によって id_dsa が拒否される

OpenSSH 7.0 ではセキュリティ上の理由から ssh-dss が無効になっています。どうしても有効にする必要がある場合、クライアントの設定オプションを使用してください ([2] には書かれていない方法です):

PubkeyAcceptedKeyTypes +ssh-dss

OpenSSH 7.0 で No matching key exchange method found

OpenSSH 7.0 では Logjam 攻撃からの(理論上の)脆弱性を理由に diffie-hellman-group1-sha1 鍵アルゴリズムが無効になっています (http://www.openssh.com/legacy.html を参照)。特定のホストで鍵アルゴリズムが必要な場合、ssh は以下のようなエラーメッセージを吐きます:

Unable to negotiate with 127.0.0.1: no matching key exchange method found.
Their offer: diffie-hellman-group1-sha1

古いアルゴリズムを使用しないようにサーバーをアップグレード・設定することで上記のエラーは解決します。サーバー側の設定を変更できない場合、クライアント設定で KexAlgorithms +diffie-hellman-group1-sha1 オプションを使うことでアルゴリズムを有効化できます。

SSH から切断したときに tmux/screen セッションが終了する

セッションの最後にプロセスが終了する場合、ソケットアクティベーションを使っているために SSH セッションプロセスが終了したときに systemd によって終了されている可能性があります。ssh.socket の代わりに ssh.service を使用してソケットアクティベーションを使わないことで解決できます。もしくは ssh@.service の Service セクションで KillMode=process を設定してください。

KillMode=process は古典的な ssh.service でも役に立つことがあります。サーバーが停止したり再起動したときに SSH セッションプロセスや screentmux のプロセスが終了されることを防ぐことができます。

参照