SSH(1)

FreeBSD General Commands Manual

SSH(1)

名称

ssh — OpenSSH SSH クライアント (リモートログインプログラム)

書式

ssh

[ -1246AaCfgKkMNnqsTtVvXxYy][ -b bind_address][ -c cipher_spec][ -D [ bind_address:] port][ -E log_file][ -e escape_char][ -F configfile][ -I pkcs11][ -i identity_file][ -L [ bind_address:] port: host: hostport][ -l login_name][ -m mac_spec][ -O ctl_cmd][ -o option][ -p port][ -R [ bind_address:] port: host: hostport][ -S ctl_path][ -W host: port][ -w local_tun[ : remote_tun]][ user@] hostname [ command]

ssh	-Q protocol_feature

解説

ssh (SSH クライアント) は、リモートマシンにログインするため、そしてリモートマシンでコマンドを実行するためのプログラムです。それは、rlogin と rsh を置き換え、安全でないネットワークを越えて、 2 つの信頼されていないホストの間で安全で暗号化された通信を提供することを目的としています。 X11 の接続や任意の TCP ポートなども安全な通信路を通して転送できます。

ssh は、指定された hostname (ホスト名) に (オプションの user (ユーザ名) を付けて) 接続し、ログインします。ユーザは、プロトコルのバージョンの使用に応じて、いくつかある方法からひとつを使用して、リモートマシンに対して、本人であることを証明しなければなりません (下記参照)。

command が指定されたなら、ログインシェルのかわりにリモートホストでそのコマンドが実行されます。

オプションは、次の通りです:

-1

ssh がプロトコルバージョン 1 のみを使用するように強制します。

-2

ssh がプロトコルバージョン 2 のみを使用するように強制します。

-4

ssh が IPv4 アドレスのみを使用するように強制します。

-6

ssh が IPv6 アドレスのみを使用するように強制します。

-A

認証エージェントの転送を許可します。これは設定ファイルによってホストごとに指定することも可能です。

認証エージェントの転送には注意が必要です。リモートホスト上で (エージェントの UNIX ドメインソケットに対する) ファイルアクセス権限を無視できてしまうユーザがいる場合は、転送された接続を介してローカル側の認証エージェントにアクセスできてしまうことになります。攻撃側は認証エージェントから鍵そのものを盗むことはできませんが、認証エージェントがもっている鍵に認証をおこなわせることはできます。

-a

認証エージェントの転送を禁止します。

-b bind_address

接続のソース側のインタフェースとして、 bind_address を使います。これが有用なのは、複数の IP アドレスをもつマシン上のみです。

-C

すべてのデータを圧縮するように指示します (標準入力、標準出力、標準エラー出力、転送された X11 や TCP 接続を含む)。圧縮に使われるアルゴリズムは、 gzip(1) と同じもので、プロトコルバージョン 1 の場合“level”が CompressionLevel 設定項目によって変更できます。圧縮は、モデムその他の遅い接続においては望ましいものですが、高速なネットワークでは速度が低下するだけです。このデフォルト値はホスト間ごとに設定ファイルに書くことができます。 Compression 設定項目を参照してください。

-c cipher_spec

このセッションで使われる暗号化の方式を指定します。

プロトコルバージョン 1 の場合、指定できる方式はひとつで“3des”, “blowfish”と“des”がサポートされています。 3des (トリプル des) は、3 つの異なる鍵を使って暗号化-復号化-暗号化を行います。これは安全であると考えられているためです。 blowfish は、高速なブロック暗号化方式で、かなり安全であり、 3des よりもずっと高速です。 des は、 3des 暗号化をサポートしていない、古いプロトコル 1 の実装で相互運用するために ssh クライアントでのみサポートされています。暗号化の弱点のために、その使用は、強くお勧めできません。デフォルトは、“3des”です。

プロトコルバージョン 2 では、 cipher_spec は、コンマで区切られたリストになっており、暗号方式の優先順位を指定できます。詳しい情報については、 ssh_config(5) の Ciphers キーワードを参照してください。

-D [ bind_address:] port

ローカルホスト側における、アプリケーションレベルの“動的な”ポート転送を指定します。これは、オプションで指定された bind_address をバインドするローカル側で port を listen するためのソケットを割り付けることによって働きます。このポートに接続されるときはいつも、その接続は、安全なチャネルで転送され、次に、アプリケーションプロトコルは、リモートマシンからどこに接続するかを決定するために使用されます。今のところ SOCKS4 および SOCKS5 プロトコルがサポートされており、 ssh は、SOCKS サーバのようにふるまいます。特権ポートを転送できるのは、root だけです。ダイナミックポート転送は設定ファイルでも指定できます。

角括弧でアドレスを囲むことによって、IPv6 アドレスを指定することができます。スーパユーザだけが特権ポートを転送することができます。デフォルトで、ローカルポートは、 GatewayPorts 設定に従って、bind されます。しかしながら、明白な bind_address は、特定のアドレスに接続を bind するために使用されます。“localhost”の bind_address は、listen ポートがローカルの使用のみに bind されていることを示し、一方、空のアドレスまたは‘*’は、ポートがすべてのインタフェースから利用可能であることを示します。

-E log_file

標準エラーの代わりに log_file にデバッグのログ記録を追加します。

-e escape_char

仮想端末を使うセッションにおけるエスケープ文字を指定します (デフォルトは、‘ ~)’。エスケープ文字は行頭に来たときのみ認識されます。エスケープ文字のあとにドット (‘ .’) がきた場合その接続は閉じられ、 control-Z がきた場合にはその接続はサスペンドされます。このエスケープ文字自身が続いたときには、この文字が 1 回だけ送られます。エスケープ文字を“none”に指定するとあらゆるエスケープ機能が禁止され、セッションは完全に透過になります。

-F configfile

ユーザ毎の設定ファイルに別のファイルを指定します。設定ファイルがコマンドラインから与えられた場合、システム全体の設定ファイル ( /etc/ssh/ssh_config) は、無視されます。デフォルトでは、ユーザ毎の設定ファイルは、 ~/.ssh/config になっています。

-f

ssh がコマンドを実行する直前に、バックグラウンドに移行するよう指示します。これは、 ssh にパスワードあるいはパスフレーズを入力する必要はあるものの、そのコマンド自体はバックグラウンドで実行させたいときに便利です。これは、 -n オプションも含んでいます。リモートサイトで X11 プログラムを起動させる場合には、 ssh -f host xterm などとやるのがおすすめです。

ExitOnForwardFailure 設定オプションが“yes”に設定されるなら、 -f で始まるクライアントは、それ自体をバックグラウンドに置く前に、成功して確立されたすべてのリモートポート転送をウェートし (待ち) ます。

-g

リモートホストが転送されたローカルなポートに接続することを許可します。

-I pkcs11

PKCS#11 共有ライブラリを指定します。 ssh は、ユーザの RSA 秘密鍵を提供する PKCS#11 トークンで通信するために使用するはずです。

-i identity_file

公開鍵認証のために identity (秘密鍵) が読み込まれるファイルを選択します。デフォルトは、プロトコルバージョン 1 に関して、 ~/.ssh/identity であり、プロトコルバージョン 2 に関して、 ~/.ssh/id_dsa, ~/.ssh/id_ecdsa と ~/.ssh/id_rsa です。 identity ファイルは設定ファイルによって、ホストごとに指定することもできます。複数の -i オプションを指定することも可能です (設定ファイルで複数の鍵を指定することもできます)。また、 ssh は、 -cert.pub を追加することによって取得されたファイル名から識別ファイル名まで証明書情報をロードしようとします。

-K

GSSAPI ベースの認証とサーバへの GSSAPI 資格証明の転送を有効にします。

-k

サーバに GSSAPI の資格証明 (委託証明) を転送することを無効にします。

-L [ bind_address:] port: host: hostport

与えられたローカル (クライアント) ホスト上のポートが、与えられたリモートホスト上のポートに転送されるようにします (ローカル ->リモートのポート転送)。これは、オプションで指定された bind_address に bind されたローカル側で port を listen (接続受け付け) するためにソケットを割り付けることによって動作します。このポートに接続されるときはいつも、その接続は、安全なチャネルで転送され、接続は、リモートマシンからホスト host のポート hostport は行われます。ポート転送は、設定ファイルによっても指定できます。角括弧でアドレスを囲むことによって、IPv6 アドレスを指定することができます。スーパユーザだけが特権ポートを転送することができます。デフォルトで、ローカルポートは、 GatewayPorts 設定に従って、bind されます。しかしながら、明白な bind_address は、特定のアドレスに接続を bind するために使用されます。“localhost”の bind_address は、listen ポートがローカルの使用のみに bind されていることを示し、一方、空のアドレスまたは‘*’は、ポートがすべてのインタフェースから利用可能であることを示します。

-l login_name

リモートマシンでログインするユーザを指定します。これは、設定ファイルによって、ホストごとに指定することもできます。

-M

ssh を、接続を共有するための“master”モードにします。複数の -M オプションは、 ssh をスレーブ接続が受け付けられるの前に要求される確認がある“master”モードにします。詳細については、 ssh_config(5) の ControlMaster の項を参照してください。

-m mac_spec

プロトコルバージョン 2 では、コンマで区切ったリストにより、使用する MAC (message authentication code, メッセージ認証コード) を優先順位をつけて指定することができます。 MAC についての詳しい情報は、 MAC の項をご覧ください。

-N

リモートコマンドを実行しません。これは、ポート転送のみを行いたい場合に便利です (プロトコルバージョン 2 のみ)。

-n

標準入力を /dev/null からリダイレクトするように (つまり標準入力からの読み込みを禁止した状態に) します。 ssh をバックグラウンドで走らせるときには、このオプションが不可欠です。よくある手としては、リモートマシン上で X11 のプログラムを走らせるときにこれを使うことです。たとえば、 ssh -n shadows.cs.hut.fi emacs & で emacs を立ち上げると、X11 接続は、暗号化された経路を介して自動的に転送されます。 ssh プログラムは、この後バックグラウンドに移行するでしょう (これは、 ssh がパスワードあるいはパスフレーズを訊いてくるときには使えません。 -f オプションを参照してください)。

-O ctl_cmd

アクティブな接続マルチプレクシングマスタプロセスを制御します。 -O オプションが指定されるとき、 ctl_cmd 引数は、解釈されて、マスタプロセスに渡されます。有効なコマンドは、次の通りです: “check” (マスタプロセスが実行しているかチェックします)、“forward” (コマンド実行なしで転送を要求します)、“cancel” (転送をキャンセルします)、“exit” (マスタを終了するように要求します) と“stop” (さらなるマルチプレクシング要求の受け付けを停止するようにマスタに要求します)。

-o option

設定ファイルと同じ形式でオプションを与えたいときに使用します。これは、コマンドラインオプションでは、指定できないオプションを指定したいときに便利です。以下にリストされたオプションの詳細ととりうる値については、 ssh_config(5) を参照してください。

AddressFamily
BatchMode
BindAddress
ChallengeResponseAuthentication
CheckHostIP
Cipher
Ciphers
ClearAllForwardings
Compression
CompressionLevel
ConnectionAttempts
ConnectTimeout
ControlMaster
ControlPath
ControlPersist
DynamicForward
EscapeChar
ExitOnForwardFailure
ForwardAgent
ForwardX11
ForwardX11Timeout
ForwardX11Trusted
GatewayPorts
GlobalKnownHostsFile
GSSAPIAuthentication
GSSAPIDelegateCredentials
HashKnownHosts
Host
HostbasedAuthentication
HostKeyAlgorithms
HostKeyAlias
HostName
IdentityFile
IdentitiesOnly
IPQoS
KbdInteractiveAuthentication
KbdInteractiveDevices
KexAlgorithms
LocalCommand
LocalForward
LogLevel
MACs
NoHostAuthenticationForLocalhost
NumberOfPasswordPrompts
PasswordAuthentication
PermitLocalCommand
PKCS11Provider
Port
PreferredAuthentications
Protocol
ProxyCommand
PubkeyAuthentication
RekeyLimit
RemoteForward
RequestTTY
RhostsRSAAuthentication
RSAAuthentication
SendEnv
ServerAliveInterval
ServerAliveCountMax
StrictHostKeyChecking
TCPKeepAlive
Tunnel
TunnelDevice
UsePrivilegedPort
User
UserKnownHostsFile
VerifyHostKeyDNS
VersionAddendum
VisualHostKey
XAuthLocation

-p port

リモートホストに接続するポートを指定します。これは、設定ファイルによって、ホストごとに指定することもできます。

-Q protocol_feature

指定されたバージョン 2 protocol_feature のためにサポートされたアルゴリズムについて ssh に問い合わせます。問い合わせ可能な機能は、次の通りです: “cipher” (サポートされた対称な暗号)、“MAC” (サポートされたメッセージ整合性コード)、“KEX” (鍵交換アルゴリズム)、“key” (鍵のタイプ)。プロトコルの機能は、大文字小文字を区別せずに扱われます。

-q

静かなモード。ほとんどの警告メッセージと診断メッセージは、抑制されます。

-R [ bind_address:] port: host: hostport

与えられたリモート (サーバ) ホスト上のポートが、与えられたローカルホスト上のポートに転送されるようにします (リモート ->ローカルのポート転送)。これは、リモート側で port に listen (接続受け付け) 用のソケットを割り当てることによりおこなわれます。このポートに向けておこなわれた接続は、つねに安全な通信路を経由してローカルマシン上に到達し、ここから host のポート hostport (ホスト側ポート番号) に接続されるようになります。

ポート転送は、設定ファイルによっても指定できます。特権ポートを転送できるのは、リモートマシン上に root としてログインしているときだけです。角括弧でアドレスを囲むことによって、IPv6 アドレスを指定することができます。

デフォルトでは、サーバでソケットを listen することは、ループバックインタフェースのみに bind されます。これは、 bind_address を指定することによって、上書きされます。空の bind_address またはアドレス‘ *’は、リモートソケットがすべてのインタフェースで listen することを示します。リモートの bind_address を指定することは、サーバの GatewayPorts オプションが有効 ( sshd_config(5) 参照) にされる場合のみ成功します。

port 引数が‘ 0’であるなら、listen (接続を受け付け) するポートは、サーバで動的に割り付けられ、実行時にクライアントに報告されます。 -O forward と共に使用されるとき、割り付けられたポートは、標準出力に印刷 (表示) されます。

-S ctl_path

接続共有のための制御ソケットの位置、または接続共有を無効にするために文字列“none”を指定します。詳細については、 ssh_config(5) の ControlPath と ControlMaster の説明を参照してください。

-s

リモート側でサブシステムの実行を要求するときに使われます。サブシステムは、SSH2 プロトコルで実現された機能であり、これを使うと SSH を他のアプリケーション (例えば sftp(1) など) への安全な通信路として利用することができます。この場合、サブシステム名は、リモートコマンドとして指定します。

-T

仮想端末の割り当てを禁止します。

-t

強制的に仮想端末を割り当てます。これは、リモートマシン上で任意の画面ベースのプログラムを実行するとき (たとえば、メニューサービスを実装するときなど) に非常に便利です。複数の -t をつけると、たとえ ssh がローカル側での端末を持っていない場合でも強制的に仮想端末を割り当てます。

-V

バージョン番号を表示して終了します。

-v

冗長表示モード。 ssh が進行中のデバッグメッセージを表示するようにします。これは、接続や認証、設定の問題をデバッグするときに助けとなります。複数の -v オプションをつけると出力が増えます。最大は、3 個です。

-W host: port

クライアントの標準入出力が安全なチャンネル上の port で host に転送されることを要求します。 -N, -T, ExitOnForwardFailure と ClearAllForwardings という意味を含みます。プロトコルのバージョン 2 だけで動作します。

-w local_tun[ : remote_tun]

クライアントの ( local_tun) とサーバの ( remote_tun) の間の指定された tun(4) デバイスでトンネルデバイス転送を要求します。

このデバイスには、次に利用可能なトンネルデバイスに使用される、数値 ID またはキーワード“any”によって指定されます。 remote_tun が指定されないなら、“any”をデフォルトとします。また、 ssh_config(5) の Tunnel と TunnelDevice 指示も参照してください。 Tunnel 指示が設定されていないなら、“point-to-point”である、デフォルトのトンネルモードに設定されます。

-X

X11 の転送を許可します。これは、設定ファイルによって、ホストごとに指定することもできます。

X11 の転送には注意が必要です。リモートホスト上で (そのユーザの X 認証のための) ファイルアクセス権限を無視できてしまうユーザがいる場合は、転送された接続を介してローカル側の X11 ディスプレイにアクセスできてしまうことになります。すると攻撃側は、キーストロークを盗み見るなどの行為が可能になってしまうかもしれません。

このため、X11 転送は、デフォルトで X11 SECURITY 拡張制限に支配されています。詳細については、 ssh の -Y オプションと ssh_config(5) の ForwardX11Trusted 指示を参照してください。

-x

X11 の転送を禁止します。

-Y

信頼された X11 の転送を許可します。信頼された X11 転送は、X11 SECURITY 拡張制御に支配されません。

-y

syslog(3) システムモジュールを使用して、ログ情報を送信します。デフォルトで、この情報は、stderr (標準エラー) に送られます。

さらに ssh は、設定情報をユーザごとの設定ファイルおよび、システム全体にわたる設定ファイルから取得します。このファイルの形式と設定項目は、 ssh_config(5) で説明されています。

認証

OpenSSH SSH クライアントは、SSH プロトコル 1 と 2 をサポートします。デフォルトは、プロトコル 2 だけを使用することですが、 ssh_config(5) の Protocol オプション、または -1 と -2 オプション (上記参照) によってこれを変えることができます。両方のプロトコルは、同じような認証メソッドをサポートしますが、秘密性 (トラフィックは、AES、3DES、Blowfish、CAST128、または Arcfour を使用して暗号化されています) と整合性 (hmac-md5, hmac-sha1, hmac-sha2-256, hmac-sha2-512, umac-64, umac-128, hmac-ripemd160) のために追加メカニズムを提供しているので、プロトコル 2 は、デフォルトです。プロトコル 1 は、接続の整合性を確実にするための強いメカニズムを欠いています。

認証のために利用可能なメソッドは、次の通りです: GSSAPI ベース認証 (GSSAPI-based authentication) ホストベースド認証 (host-based authentication) 公開鍵認証 (public key authentication) チャレンジレスポンス認証 (challenge-response authentication) とパスワード認証 (password authentication) です。認証方法は、上で指定された順序で試みられますが、プロトコル 2 には、デフォルト順序を変更するための次の設定オプションがあります: PreferredAuthentications です。

ホストベースド認証は、次のように動作します: ユーザがログインするマシンが、リモートマシンの /etc/hosts.equiv または /etc/shosts.equiv にリストされていて、ユーザ名が両方で同じであるか、または、リモートマシン上のユーザのホームディレクトリにファイル ~/.rhosts または ~/.shosts が存在していて、そのマシン上のクライアントマシンの名前とユーザの名前を含む行を含んでいるなら、ユーザは、ログインの対象となります。さらに、サーバは、ログインが許されるクライアントのホスト鍵 (下記の /etc/ssh/ssh_known_hosts と ~/.ssh/known_hosts の説明を参照) を検証できなければなりません。この認証メソッドは、IP スプーフィング (なりすまし)、DNS スプーフィング、とルーティングスプーフィングのためのセキュリティホールを閉じます。 [管理者に対する注: セキュリティ (安全性) が望まれているなら、一般的に /etc/hosts.equiv, ~/.rhosts と rlogin/rsh プロトコルは、本質的に安全でなく、無効にされるべきです。]

公開鍵認証は、次のように動作します: 方式は、暗号システムを使用して、公開鍵暗号に基づいており、暗号化と復号化は、別々の鍵を使用して行われ、暗号化鍵から復号化鍵を導き出すのは実現不可能です。この考えは、各ユーザが認証のために公開鍵/秘密鍵のペアを作成するということです。サーバは、公開鍵を知っており、ユーザだけが秘密鍵を知っています。 ssh は、RSA、ECDSA または DSA アルゴリズムの 1 つを使用する自動的に公開鍵認証プロトコルを実装しています。プロトコル 1 は、RSA 鍵だけを使用するように制限されていますが、プロトコル 2 は、いずれも使用することができます。 ssl(8) の「歴史」セクションは、DSA と RSA アルゴリズムの簡潔な説明を含んでいます。

ファイル ~/.ssh/authorized_keys は、ログインするために許可された公開鍵のリストを含んでいます。ユーザがログインするとき、 ssh プログラムは、認証のためにどの鍵のペアを使用したいかをサーバに伝えます。クライアントは、秘密鍵にアクセスできるかを検証し、サーバは、対応する公開鍵がアカウントを受け付けることが認可されるかをチェックします。

ユーザは、 ssh-keygen(1) を実行することによって、その人の鍵のペアを作成します。これは、ユーザのホームディレクトリの ~/.ssh/identity (プロトコル 1)、 ~/.ssh/id_dsa (プロトコル 2 DSA)、 ~/.ssh/id_ecdsa (プロトコル 2 ECDSA)、または ~/.ssh/id_rsa (プロトコル 2 RSA) に秘密鍵を格納して、 ~/.ssh/identity.pub (プロトコル 1)、 ~/.ssh/id_dsa.pub (プロトコル 2 DSA)、 ~/.ssh/id_ecdsa.pub (プロトコル 2 ECDSA)、または ~/.ssh/id_rsa.pub (プロトコル 2 RSA) に公開鍵を格納します。ユーザは、リモートマシンのその人のホームディレクトリの ~/.ssh/authorized_keys に公開鍵をコピーするべきです。 authorized_keys ファイルは、従来の ~/.rhosts ファイルに対応していて、行は、非常に長い場合がありますが、1 行ごとに 1 つの鍵があります。これから、ユーザは、パスワードを与えなくてもログインすることができます。

公開鍵認証の変異は、証明書認証の形で利用可能です: 1 組の公開/秘密鍵の代わりに、署名された証明書が使用されます。これには、多くの公開/秘密鍵の代わりに単一の信頼されている認証機関を使用することができるという利点があります。詳しい情報については、 ssh-keygen(1) の「証明書」セクションを参照してください。

公開鍵または証明書認証を使用する最も便利な方法は、認証エージェントかもしれません。詳細については、 ssh-agent(1) を参照してください。

チャレンジレスポンス認証は、次のように動作します: サーバは、任意の“challenge” (チャレンジ) テキストを送信し、応答のためのプロンプトを出します。プロトコル 2 は、複数のチャレンジとレスポンスを許可します。プロトコル 1 は、たった 1 つのチャレンジ/レスポンスに制限されます。チャレンジレスポンス認証に関する例には、BSD 認証 ( login.conf(5) 参照) と PAM (いくつかの OpenBSD でないシステム) があります。

最後に、他の認証方法が失敗するなら、 ssh は、ユーザにパスワードのためのプロンプトを出します。パスワードは、チェックのためにリモートホストに送信されます。しかしながら、すべての通信は、暗号化されているので、ネットワークを盗聴しているだれかはパスワードを見ることができません。

ssh は、今までに使用されたすべてのホストのための識別を含むデータベースを自動的に維持管理して、チェックします。ホスト鍵は、ユーザのホームディレクトリの ~/.ssh/known_hosts に格納されます。さらに、ファイル /etc/ssh/ssh_known_hosts は、既知のホストかどうか自動的にチェックされます。すべての新しいホストは、自動的にユーザのファイルに追加されます。ホストの識別がこれまでに変更されるなら、 ssh は、これについて警告し、サーバのなりすまし、または介入者攻撃を防ぐためにパスワード認証を無効にします。そうでなければ、暗号化を回避するために使用されるかもしれません。 StrictHostKeyChecking オプションは、ホスト鍵が知られていないか、または変更されていたマシンへのログインを制御するために使用することができます。

サーバによってユーザが本人であることが承認されたとき、サーバは、与えられたコマンドを実行するか、またはそのマシンにログインして、ユーザがリモートマシンで通常のシェルを実行できるようにします。リモートコマンドまたはシェルとのすべての通信は、自動的に暗号化されます。

(通常のログインセッションとして) 疑似端末が割り付けられたなら、ユーザは、下記のようなエスケープ文字を使用すことができます。

疑似 tty が割り付けられなかったなら、セッションは、透過的であり、バイナリデータを確実に転送するためにに使用することができます。ほとんどのシステムでは、エスケープ文字に“none”を設定することによって、tty が使用されていても、セッションは、透過的になります。

リモートマシンでコマンドまたはシェルが終了し、すべての X11 と TCP 接続がクローズされたとき、セッションは、終了します。

エスケープ文字

疑似端末が要求されたとき、 ssh は、エスケープ文字を使用した多くの機能をサポートしています。

~~ または以下で説明されたもの以外の文字をチルダに続けることによって、単一のチルダ文字を送ることができます。エスケープ文字は、特別であると解釈されるために常に改行の後に続かなければなりません。設定ファイルの EscapeChar 設定指示を使用するか、または -e オプションによってコマンドラインで、エスケープ文字を変更することができます。

サポートされているエスケープ (デフォルトの‘ ~’) と仮定します) は、次の通りです:

TCP 転送

コマンドラインで、または、設定ファイルのいずれかで安全なチャネルを使用して任意の TCP 接続の転送を指定することができます。 TCP 転送の有効なアプリケーションの 1 つは、メールサーバへの安全な接続です。別のものとしてファイアウォールを通り抜けることです。

以下の例では、IRC サーバが直接暗号化された通信をサポートしていなくても、 IRC クライアントとサーバとの通信を暗号化することを検討します。これは、次のように動作します: ユーザは、リモートサーバへの接続を転送するために使用されるためのポートを指定して、 ssh を使用してリモートホストに接続します。それ以後、同じローカルポートに接続して、クライアントマシンで暗号化されたサービスを開始でき、 ssh は、接続を暗号化して転送します。

次の例は、クライアントマシン“127.0.0.1” (localhost) からリモートサーバ“server.example.com”への IRC セッションをトンネル化します:

$ ssh -f -L 1234:localhost:6667 server.example.com sleep 10 
$ irc -c '#users' -p 1234 pinky 127.0.0.1

これは、ポート 1234 を使用してチャネル“#users”でニックネーム“pinky”に接合する IRC サーバへの接続をトンネル化します。 1023 以上であり、(root だけが特権があるポートのソケットをオープンできることを思い出してください) 既に使用中の任意のポートと衝突しない限り、どのポートが使用されているかは重要ではありません。この接続は、それが IRC サービスのための標準のポートであるので、リモートサーバのポート 6667 に転送されます。

ssh をバックグラウンドにする -f オプションとリモートコマンド“sleep 10”は、トンネル化されたサービスを開始する時間の合計 (この例では、10 秒) を許可するために指定されます。接続が指定されたこの時間内に行われないなら、 ssh は、終了します。

X11 転送

ForwardX11 変数が“yes”に設定され (上記の -X, -x, と -Y オプションの説明を参照)、ユーザが、X11 ( DISPLAY 環境変数は、設定されています) を使用しているなら、X11 ディスプレイとの接続は、シェル (または、コマンド) から開始された任意の X11 プログラムが暗号化されたチャネルを通して行われるような方法で、自動的にリモート側に転送されます、そして、実際の X サーバへの接続は、ローカルマシンから行われます。ユーザは、手動で DISPLAY を設定するべきではありません。コマンドラインで、または、設定ファイルで X11 接続の転送を設定することができます。

ssh によって設定された DISPLAY 値は、サーバマシンを指しますが、0 以上のディスプレイ番号となります。これは、正常であり、 ssh が、暗号化されたチャネルで接続を転送するためにサーバマシンで“proxy” X サーバを作成するために起こります。

また、 ssh は、サーバマシンで Xauthority データを自動的に設定します。このために、ランダムな認証クッキーを生成し、サーバの Xauthority にそれを格納し、接続がオープンされたとき、任意の転送された接続がこのクッキーを運び、実際のクッキーによってそれを置き換えることを検証します。本当の認証クッキーは、サーバマシンに決して送信されません (そして、クッキーがそのまま暗号化されず送信されることもありません)。

ForwardAgent 変数が“yes”に設定され (上記の -A と -a オプションの説明を参照)、ユーザが認証エージェントを使用しているなら、エージェントへの接続は、自動的にリモート側に転送されます。

ホスト鍵の検証

初めてサーバに接続するとき、サーバの公開鍵の指紋 (fingerprint) は、 (オプション StrictHostKeyChecking が無効にされていないなら) ユーザに提示されます。指紋は、 ssh-keygen(1) を使用して決定することができます:

$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key

指紋が既に知られているなら、それと適合することができ、鍵を受け付けるか、または拒否することができます。 16 進数文字列を見るだけによってホストキーを比較するという困難のために、 random art (ランダム art) を使用して、視覚的にホストキーを比較するためのサポートもあります。 VisualHostKey オプションを“yes”に設定することによって、たとえ、セッション自体が対話的であっても、そうでなくても、小さい ASCII グラフィックは、サーバへのあらゆるログインで、表示されたものを取得します。知られているサーバが作成するパターンを学ぶことによって、ユーザは、完全に異なったパターンが表示されるとき、ホストキーが、変更されたことを容易に見つけることができます。しかしながら、これらのパターンが明白でないので、覚えていたパターンと同様に見えるパターンは、証拠を保証するのではなく、ホスト鍵が同じであるという良い確率を与えるだけです。

すべての知られているホストのための、それらのランダム art とともに指紋のリストを取得するためには、次のコマンドラインを使用することができます:

$ ssh-keygen -lv -f ~/.ssh/known_hosts

指紋が未知であるなら、検証の別の方法が利用可能です: DNS によって検証された SSH 指紋。追加リソースレコード (RR)、SSHFP は、ゾーンファイル (zonefile) に追加され、接続クライアントは、提示された鍵で指紋と照合することができます。

この例では、サーバ“host.example.com”にクライアントを接続します。 SSHFP リソースレコードは、最初に、host.example.com のゾーンフィイルに追加されるべきです:

$ ssh-keygen -r host.example.com.

出力行は、ゾーンファイルに追加されなければなりません。ゾーンが指紋の問い合わせに応答するかどうかをチェックするためには、次のように行います:

$ dig -t SSHFP host.example.com

最終的にクライアントは、次のように接続します:

$ ssh -o "VerifyHostKeyDNS ask" host.example.com 
[...] 
Matching host key fingerprint found in DNS. 
Are you sure you want to continue connecting (yes/no)?

詳細については、 ssh_config(5) の VerifyHostKeyDNS オプションを参照してください。

SSH ベースの仮想プライベートネットワーク

ssh は、安全に結びつけられた 2 つのネットワークを可能とし、 tun(4) ネットワーク疑似デバイス使用して仮想プライベートネットワーク (VPN) トンネル化のサポートを含みます。 sshd_config(5) 設定オプション PermitTunnel は、サーバが、これとどんなレベル (レイヤ 2 または 3 のトラフィック) をサポートするかどうかを制御します。

次の例は、SSH サーバが 192.168.1.15 でリモートネットワークへのゲートウェイで実行されていて、それが許可されているという条件で、 10.1.1.1 から 10.1.1.2 までの point-to-point を使用してリモートネットワーク 10.0.99.0/24 でクライアントネットワーク 10.0.50.0/24 に接続しています。

クライアントでは:

# ssh -f -w 0:1 192.168.1.15 true 
# ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252 
# route add 10.0.99.0/24 10.1.1.2

サーバでは:

# ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.252 
# route add 10.0.50.0/24 10.1.1.1

クライアントアクセス制御は、 /root/.ssh/authorized_keys ファイル (下記参照) と PermitRootLogin サーバオプションによってより細かく調整できます。次のエントリは、 PermitRootLogin が“forced-commands-only”に設定されるなら、ユーザ“jane”から tun(4) デバイス 1 で接続を許可し、ユーザ“john”から tun デバイス 2 で接続を許可します。

tunnel="1",command="sh /etc/netstart tun1" ssh-rsa ... jane 
tunnel="2",command="sh /etc/netstart tun2" ssh-rsa ... john

SSH ベースの設定は、かなりの量のオーバヘッドを伴うので、無線 VPN などのような、一時的な設定により都合がよいでしょう。より永続的な VPN は、 ipsecctl(8) と isakmpd(8) のようなツールによって提供されるほうが優れています。

環境変数

ssh は、通常次の環境変数を設定します:

DISPLAY: 環境変数 DISPLAY は、X11 サーバの場所を示しています。形式“hostname:n”の値を指すために ssh によって自動的に設定されます。ここで、“hostname”シェルが実行されるホストを示し、‘n’は、≥ 1 の整数です。 ssh は、X11 接続を安全な通信路で転送するために、この特別な値を使います。 X11 の接続が安全でなくなってしまうため、ユーザは、環境変数 DISPLAY を自分で設定すべきではありません (また、それをやってしまうとユーザは、認証に必要なクッキーを手でコピーしなければならなくなります)。
HOME: ユーザのホームディレクトリのパス名が設定されます。
LOGNAME: 環境変数 USER と同じです。これは、この変数を使うシステムで互換性を保つために設定されます。
MAIL: ユーザのメールボックスのパス名が設定されます。
PATH: デフォルトの PATH です。これは、 ssh のコンパイル時に指定されます。
SSH_ASKPASS: パスフレーズを入力する際、 ssh が端末から起動されているとパスフレーズをその端末から要求します。 ssh が制御できる端末を持っておらず、環境変数 DISPLAY および SSH_ASKPASS が設定されている場合、 SSH_ASKPASS によって指定されるプログラムを起動し、X11 ウィンドウを使ってパスフレーズを要求します。これは、 ssh を .xsession やそれに類するスクリプトから呼び出す際にとくに役に立ちます (マシンによっては、これがうまく動くためには、標準入力を /dev/null にリダイレクトする必要があるかもしれません)。
SSH_AUTH_SOCK: エージェントと通信するために使用される UNIX-ドメインソケットのパスを特定します。
SSH_CONNECTION: 接続の両端にあるクライアントとサーバの識別子です。この変数には、スペースで区切られた 4 つの値が入っています: クライアントの IP アドレス、クライアントのポート番号、サーバの IP アドレスおよびサーバのポート番号です。
SSH_ORIGINAL_COMMAND: 強制コマンドが実行されると、この変数には、元々指定されていたコマンドラインの値が入ります。ここから本来の引数を取り出すことができます。
SSH_TTY: 現在のシェルあるいはコマンドに割り当てられている tty の名前 (端末装置へのパス) に設定されます。現在のセッションが端末を持たない場合、この変数は、設定されません。
TZ: デーモンが起動したとき、現在の時間帯を表すタイムゾーン変数が設定されていると、それがここに入ります (つまりデーモンは、その値を新規の接続に渡します)。
USER: ログインしているユーザ名に設定されます。

これらに加えて、 ssh は、 ~/.ssh/environment ファイルが存在してユーザがその変更を許可されていればそれを読み込み、“VARNAME=value”という形式の行を環境変数に追加します。より詳しい情報については、 sshd_config(5) の PermitUserEnvironment 設定項目を参照してください。

終了ステータス

ssh は、エラーが起こったなら、リモートコマンドの終了ステータスまたは 255 で終了します。

規格

S. Lehtinen and C. Lonvick, The Secure Shell (SSH) Protocol Assigned Numbers, RFC 4250, January 2006.

T. Ylonen and C. Lonvick, The Secure Shell (SSH) Protocol Architecture, RFC 4251, January 2006.

T. Ylonen and C. Lonvick, The Secure Shell (SSH) Authentication Protocol, RFC 4252, January 2006.

T. Ylonen and C. Lonvick, The Secure Shell (SSH) Transport Layer Protocol, RFC 4253, January 2006.

T. Ylonen and C. Lonvick, The Secure Shell (SSH) Connection Protocol, RFC 4254, January 2006.

J. Schlyter and W. Griffin, Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints, RFC 4255, January 2006.

F. Cusack and M. Forssen, Generic Message Exchange Authentication for the Secure Shell Protocol (SSH), RFC 4256, January 2006.

J. Galbraith and P. Remaker, The Secure Shell (SSH) Session Channel Break Extension, RFC 4335, January 2006.

M. Bellare, T. Kohno, and C. Namprempre, The Secure Shell (SSH) Transport Layer Encryption Modes, RFC 4344, January 2006.

B. Harris, Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol, RFC 4345, January 2006.

M. Friedl, N. Provos, and W. Simpson, Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol, RFC 4419, March 2006.

J. Galbraith and R. Thayer, The Secure Shell (SSH) Public Key File Format, RFC 4716, November 2006.

D. Stebila and J. Green, Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer, RFC 5656, December 2009.

A. Perrig and D. Song, Hash Visualization: a New Technique to improve Real-World Security, 1999, International Workshop on Cryptographic Techniques and E-Commerce (CrypTEC '99).

作者

OpenSSH は、Tatu Ylonen によってリリースされたオリジナルのフリーな ssh 1.2.12 の派生物です。 Aaron Campbell、Bob Beck、Markus Friedl、Niels Provos、 Theo de Raadt と Dug Song は、多くのバグを取り除き、新しい機能を再び追加し、OpenSSH を作成しました。 Markus Friedl は、SSH プロトコルバージョン 1.5 と 2.0 のためのサポートを寄贈しました。

July 18, 2013

FreeBSD

YOS OPENSONAR

名称

書式

解説

認証