/usr/bin/ssh

From Azupedia
(Redirected from /usr/bin/slogin)
Jump to navigation Jump to search

ssh — OpenSSH remote login client

SYNOPSIS

ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B bind_interface] [-b bind_address] [-c cipher_spec]
[-D [bind_address:]port] [-E log_file] [-e escape_char] [-F configfile] [-I pkcs11]
[-i identity_file] [-J destination] [-L address] [-l login_name] [-m mac_spec] [-O ctl_cmd]
[-o option] [-p port] [-Q query_option] [-R address] [-S ctl_path] [-W host:port]
[-w local_tun[:remote_tun]] destination [command]

DESCRIPTION

ssh (SSH クライアント) は、リモートマシンにログインし、リモートマシン上でコマンドを実行するためのプログラムである。これは、安全でないネットワーク上の信頼できない2つのホスト間で、安全な暗号化通信を提供することを目的としている。X11 接続、任意の TCP ポート、および UNIX ドメインソケットも、安全なチャネルを介して転送することがでる。

ssh は、指定された宛先に接続し、ログインする。宛先は、[user@]ホスト名、または ssh://[user@]hostname[:port] という形式の URI として指定することができる。ユーザは、いくつかの方法（下記参照）のいずれかを使用して、リモートマシンに対して自分の身元を証明する必要がある。

コマンドが指定された場合、ログインシェルの代わりにそのコマンドがリモートホストで実行される。

オプションは以下のとおり。

-4
ssh が IPv4 アドレスのみを使用するように強制する。
-6
ssh が IPv6 アドレスのみを使用するように強制する。
-A

ssh-agent(1) などの認証エージェントからの接続の転送を有効にします。 これは、構成ファイルでホストごとに指定することもできます。

エージェントの転送を有効にする際は、注意が必要です。 リモートホストのファイルパーミッションを回避する能力を持つユーザ (エージェントの UNIX ドメインソケットの場合) は、転送された接続を介してローカルエージェントにアクセスすることができます。 攻撃者はエージェントから鍵の材料を得ることはできませんが、エージェントに読み込まれたIDを使用して認証できるように、鍵の操作を実行することができます。 より安全な代替案として、ジャンプホストを使用することができます (-J を参照)。

-a

認証エージェント接続の転送を無効にします。

-B bind_interface
接続先のホストに接続する前に、bind_interface のアドレスにバインドする。 これは、複数のアドレスを持つシステムにおいてのみ有効である。
-b bind_address
ローカルマシンの bind_address を接続元アドレスとして使用する。 複数のアドレスを持つシステムでのみ有効である。
-C
すべてのデータ (stdin, stdout, stderr, および転送された X11, TCP, UNIX ドメイン接続のデータを含む) の圧縮を要求する。 圧縮アルゴリズムは、gzip で使用されているものと同じである。 圧縮はモデム回線やその他の遅い接続では望ましいが、高速なネットワークでは遅くなるだけである。 デフォルト値は、設定ファイルでホストごとに設定することができる。
-c cipher_spec
セッションを暗号化するための暗号仕様を選択する。cipher_spec は、優先順位の高い順に並べた暗号のカンマ区切りの一覧である。 詳細については、ssh_config の Ciphers キーワードを参照。
-D [bind_address:]port
ローカルな "動的 "アプリケーションレベルのポートフォワーディングを指定する。 これは、ローカル側でポートをリッスンするソケットを割り当てることで動作し、オプションで指定した bind_address にバインドされます。 このポートに接続が行われるたびに、接続は安全な経路で転送され、アプリケーションプロトコルはリモートマシンからどこに接続するかを決定するために使用されます。 現在、SOCKS4 および SOCKS5 プロトコルに対応しており、ssh は SOCKS サーバとして動作する。 特権ポートを転送できるのはrootのみである。 また、設定ファイルで動的なポートフォワーディングを指定することも可能である。
IPv6 アドレスは角括弧で囲むことで指定できる。特権ポートを転送できるのはスーパーユーザのみである。 デフォルトでは、ローカルポートはGatewayPortsの設定にしたがってバインドされる。ただし、明示的に bind_address を指定して、特定のアドレスに接続を束縛することができる。 bind_addressに "localhost"を指定すると、リスニングポートをローカルにのみ割り当てることを示し、空のアドレスまたは'*'を指定すると、そのポートがすべてのインタフェースから利用可能であることを示す。
-E log_file
スタンダードエラーの代わりにlog_fileにデバッグログを追加する。
-e escape_char
ptyを使用するセッションのエスケープ文字を設定する（デフォルト：'~')。 エスケープ文字は、行頭でのみ認識される。 エスケープ文字の後にドット ('.') を付けると接続を閉じ、control-Z を付けると接続を中断し、それ自体を付けるとエスケープ文字を一回送信する。 この文字を"none"に設定すると、エスケープ文字が無効になり、セッションが完全に透過的になる。
-F configfile
ユーザごとの代替コンフィグファイルを指定する。 コマンドラインで構成ファイルが指定された場合、システム全体の構成ファイル (/etc/ssh/ssh_config) は無視される。 ユーザごとの構成ファイルの既定値は ~/.ssh/config である。 "none"に設定すると、構成ファイルは一切読み込まれない。
-f
コマンドを実行する直前にバックグラウンドに移行するよう ssh に要求する。 これは、ssh がパスワードやパスフレーズを要求するけれども、ユーザがバックグラウ ンドで実行することを望む場合に便利である。 これは、-n を意味する。リモートサイトで X11 プログラムを起動するには、ssh -f host xterm のような方法を推奨する。
ExitOnForwardFailure 設定オプションが "yes" に設定されている場合、-f で起動したクライアントは、すべてのリモートポート転送が正常に確立されるのを待ってから、バックグラウンドに移行するようになる。
-G
ssh が Host および Match ブロックを評価した後に構成を表示して終了するようにする。
-g
リモートホストがローカルのフォワーディングされたポートに接続できるようにする。 多重接続で使用する場合、このオプションはマスタープロセスで指定する必要がある。
-I pkcs11
ユーザ認証用の鍵を提供する PKCS#11 トークンと通信するために ssh が使用する PKCS#11 共有ライブラ リを指定する。
-i identity_file
公開鍵認証に用いる ID (秘密鍵) を読み込むファイルを選択する。 デフォルトは ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519, ~/.ssh/id_ed25519_sk, ~/.ssh/id_rsa のいずれかである。 ID ファイルは、設定ファイル内でホストごとに指定することもできる。 複数の -i オプションを指定することができる (構成ファイルで複数の ID を指定することもできる)。 CertificateFile ディレクティブで明示的に証明書が指定されていない場合、 ssh は ID ファイル名に -cert.pub を付加して得られるファイル名から証明書情報を読み込もうとすることもある。
-J destination
ジャンプ先のホストにssh接続し、そこから最終目的地までTCPフォワーディングを確立して接続する。 ジャンプホップはカンマで区切って複数指定することができる。 これは、ProxyJump設定ディレクティブを指定するためのショートカットである。 コマンドラインで指定された設定ディレクティブは、通常、宛先ホストに適用され、指定されたジャンプホストには適用されないことに注意すること。 ジャンプホストの設定を指定するには、 ~/.ssh/config を使用する。
-K
GSSAPIベースの認証と、サーバーへのGSSAPI資格情報の転送（委譲）を有効にする。
-k
GSSAPI認証情報のサーバーへの転送（委譲）を無効にする。
-L [bind_address:]port:host:hostport
-L [bind_address:]port:remote_socket
-L local_socket:host:hostport
-L local_socket:remote_socket
ローカル (クライアント) ホストの与えられた TCP ポートまたは Unix ソケットへの接続を、リモート側の与えられたホストとポート、または Unix ソケットにフォワーディングすることを指定する。 ローカル側の TCP ポート (オプションで指定された bind_address にバインドされる) または Unix ソケットをリッスンするためのソケットを確保することで動作する。 ローカルポートまたはソケットに接続すると、安全な経路で転送され、リモートマシンからホストポートの hostport または Unix ソケットの remote_socket に接続される。
ポートフォワーディングは、設定ファイルで指定することもできる。 特権ポートの転送はスーパーユーザのみ可能である。 IPv6 アドレスは、アドレスを角括弧で囲んで指定することができる。
デフォルトでは、ローカルポートはGatewayPortsの設定にしたがってバインドされる。ただし、明示的に bind_address を指定して、特定のアドレスに接続を束縛することができる。 bind_address に "localhost" を指定すると、リスニングポートをローカルにのみ割り当てることを示し、空のアドレスまたは '*' を指定すると、そのポートがすべてのインタフェースから利用可能であることを示す。
-l login_name
リモートマシンでログインするユーザーを指定する。 これも設定ファイルでホストごとに指定することができる。
-M
ssh クライアントを接続共有のための "master" モードにする。 複数の -M オプションを指定すると、ssh を"master"モードにするが、多重化状態を変更する各操作 (たとえば、新しいセッションを開く) の前に ssh-askpass を使った確認が必要になる。 詳細は ssh_config の ControlMaster の記述を参照。
-m mac_spec
MAC (メッセージ認証コード) アルゴリズムのカンマ区切りのリストで、優先順位の高い順に指定する。 詳細については、MACs キーワードを参照。
-N
リモートコマンドを実行しない。 これは、単にポートをフォワーディングする場合に便利である。
-n
標準入力を /dev/null からリダイレクトする (実際には、標準入力からの読み取りを防止する)。 これは、ssh がバックグラウンドで実行されているときに使用する必要がある。 一般的なトリックは、リモートマシン上で X11 プログラムを実行するために これを使用することである。 たとえば、ssh -n shadows.cs.hut.fi emacs & とすると shadows.cs.hut.fi で emacs が起動し、X11 接続は自動的に暗号化チャネルにフォワードされる。 ssh プログラムはバックグラウンドに置かれる。 (これは ssh がパスワードやパスフレーズを要求する必要がある場合には動作しない。 -f オプションも参照。)
-O ctl_cmd
アクティブな接続多重化マスタープロセスを制御する。 -O オプションを指定すると、引数 ctl_cmd を解釈し、マスタープロセスに渡す。 有効なコマンドは以下の通り。
"check" (マスタープロセスが動作しているか確認する), "forward" (コマンドを実行せずに転送を要求する), "cancel" (フォワーディングをキャンセルする), "exit" (マスターに終了を要求する), "stop" (マスターにさらなる多重化要求の受け付けを停止するように要求する)。
-o option
設定ファイルで使用される形式でオプションを指定するために使用することができる。 これは、独立したコマンドラインフラグがないオプションを指定する場合に便利である。 以下のオプションとその値の詳細については、 ssh_config を参照。
option list
                  AddKeysToAgent
                  AddressFamily
                  BatchMode
                  BindAddress
                  CanonicalDomains
                  CanonicalizeFallbackLocal
                  CanonicalizeHostname
                  CanonicalizeMaxDots
                  CanonicalizePermittedCNAMEs
                  CASignatureAlgorithms
                  CertificateFile
                  ChallengeResponseAuthentication
                  CheckHostIP
                  Ciphers
                  ClearAllForwardings
                  Compression
                  ConnectionAttempts
                  ConnectTimeout
                  ControlMaster
                  ControlPath
                  ControlPersist
                  DynamicForward
                  EscapeChar
                  ExitOnForwardFailure
                  FingerprintHash
                  ForwardAgent
                  ForwardX11
                  ForwardX11Timeout
                  ForwardX11Trusted
                  GatewayPorts
                  GlobalKnownHostsFile
                  GSSAPIAuthentication
                  GSSAPIKeyExchange
                  GSSAPIClientIdentity
                  GSSAPIDelegateCredentials
                  GSSAPIKexAlgorithms
                  GSSAPIRenewalForcesRekey
                  GSSAPIServerIdentity
                  GSSAPITrustDns
                  HashKnownHosts
                  Host
                  HostbasedAuthentication
                  HostbasedKeyTypes
                  HostKeyAlgorithms
                  HostKeyAlias
                  Hostname
                  IdentitiesOnly
                  IdentityAgent
                  IdentityFile
                  IPQoS
                  KbdInteractiveAuthentication
                  KbdInteractiveDevices
                  KexAlgorithms
                  LocalCommand
                  LocalForward
                  LogLevel
                  MACs
                  Match
                  NoHostAuthenticationForLocalhost
                  NumberOfPasswordPrompts
                  PasswordAuthentication
                  PermitLocalCommand
                  PKCS11Provider
                  Port
                  PreferredAuthentications
                  ProxyCommand
                  ProxyJump
                  ProxyUseFdpass
                  PubkeyAcceptedKeyTypes
                  PubkeyAuthentication
                  RekeyLimit
                  RemoteCommand
                  RemoteForward
                  RequestTTY
                  SendEnv
                  ServerAliveInterval
                  ServerAliveCountMax
                  SetEnv
                  StreamLocalBindMask
                  StreamLocalBindUnlink
                  StrictHostKeyChecking
                  TCPKeepAlive
                  Tunnel
                  TunnelDevice
                  UpdateHostKeys
                  User
                  UserKnownHostsFile
                  VerifyHostKeyDNS
                  VisualHostKey
                  XAuthLocation
-p port
リモートホストに接続するときのポート番号。この値は、コンフィグレーションファイルでホスト毎に指定できる。
-Q query_option
指定されたバージョン 2 でサポートされているアルゴリズムを ssh に照会する。使用可能な機能は次のとおり。
cipher (対応している対称暗号)、cipher-auth (対応している認証付き暗号をサポートする対称暗号)、help (-Q フラグで使用する対応しているクエリー用語)、mac (対応しているメッセージ完全性コード)、kex (キー交換アルゴリズム), kex-gss (GSSAPI 鍵交換アルゴリズム)、key (鍵の種類)、key-cert (証明書の鍵の種類)、 key-plain (証明書以外の鍵の種類)、key-sig (すべての鍵の種類と署名アルゴリズム)、 protocol-version (対応 SSH プロトコルバージョン) および sig (対応署名アルゴリズム) がある。 また、 ssh_config や sshd_config のキーワードで、アルゴリズムのリストを取るものは、 対応する query_option の別名として使用することができる。
-q
クワイエットモード。 ほとんどの警告および診断メッセージが抑制される。
-R [bind_address:]port:host:hostport
-R [bind_address:]port:local_socket
-R remote_socket:host:hostport
-R remote_socket:local_socket
-R [bind_address:]port
リモート (サーバ) ホスト上の指定された TCP ポートまたは Unix ソケットへの接続をローカル側にフォワーディングするよう指定する。
これは、リモート側のTCPポートまたはUnixソケットのいずれかをリッスンするソケットを割り当てることで機能する。 このポートまたは Unix ソケットに接続が行われるたびに、接続は安全なチャネルを介して転送され、ローカルマシンから host port hostport または local_socket で指定された明示的な宛先に接続されるか、明示的な宛先を指定しなかった場合、ssh は SOCKS 4/5 プロキシとして動作し、リモート SOCKS クライアントが要求する宛先に接続がフォワーディングされる。
ポートフォワーディングは、構成ファイルで指定することもできる。 特権ポートは、リモートマシンでrootとしてログインしているときのみフォワーディングできる。 IPv6アドレスは、アドレスを角括弧で囲んで指定することができる。
デフォルトでは、サーバー上のTCPリスニング・ソケットはループバック・インターフェイスにのみバインドされる。これは bind_address を指定することで上書きできる。 bind_address を空にするか、アドレス '*' を指定すると、リモートソケットはすべてのインターフェイスで待ち受けることになる。 リモートの bind_address の指定は、サーバの GatewayPorts オプションが有効な場合のみ成功する (sshd_config を参照)。
port 引数が0の場合、listen portはサーバ上で動的に割り当てられ、実行時にク ライアントに通知される。 O forward と一緒に使用すると、割り当てられたポートが標準出力に出力される。
-S ctl_path
接続共有のための制御ソケットの場所を指定するか、または接続共有を無効にするために文字列 "none " を指定する。 詳細は、ssh_config の ControlPath および ControlMaster の説明を参照。
-s
リモートシステム上のサブシステムの起動を要求するために使用されることがある。 サブシステムは、他のアプリケーション (例: sftp) のための安全なトランスポートとして SSH を使用することを容易にするものである。 サブシステムは、リモートコマンドとして指定される。
-T
pseudo-terminal の割り当てを無効にする。
-t
擬似端末の割り当てを強制する。 これは、リモートマシン上で任意の画面ベースのプログラムを実行するために 使用され、例えばメニューサービスを実装する際に非常に便利である。 複数の -t オプションを指定すると、ssh にローカルな tty がない場合でも、 tty を強制的に割り当てる。
-V
バージョンナンバーを表示し終了する。
-v
バーボーズモード。 ssh の進行状況についてデバッグメッセージを表示する。 これは、接続、認証、および構成の問題をデバッグする際に便利である。 複数の -v オプションを使用すると、冗長性が高まる。 最大値は 3 である(-vvv)。
-W host
port
クライアントの標準入力および標準出力が、安全なチャネルを介してポート上のホストに転送されるように要求する。 -N、-T、ExitOnForwardFailure、および ClearAllForwardings を暗示することになるが、これらは設定ファイルまたは -o コマンドラインオプションで上書きすることができる。
-w local_tun[:remote_tun]
クライアント (local_tun) とサーバ (remote_tun) の間で、指定された tun(4) デバイスによるトンネルデバイスの転送を要求する。
デバイスは、数値 ID か、次に利用可能なトンネルデバイスを使用するキーワード "any" で指定することができる。 remote_tun が指定されない場合、デフォルトは "any"である。 ssh_config の Tunnel ディレクティブと TunnelDevice ディレクティブも参照。
Tunnel ディレクティブが設定されていない場合、デフォルトのトンネルモードである "point-to-point" に設定される。 もし、別のトンネル転送モードが必要なら、-w の前に指定されるべきである。
-X
X11 フォワーディングを有効にする。 これは、設定ファイルでホストごとに指定することもできる。
X11 フォワーディングを有効にするには、注意が必要である。 リモートホストのファイルパーミッションをバイパスする能力を持つユーザー（ユーザーのX権限データベースに対して）は、フォワーディングされた接続を介してローカルのX11ディスプレイにアクセスできる。 攻撃者は、次のような活動を行うことができるかもしれない。キーストロークの監視などを行うことができる。
このため、X11 フォワーディングはデフォルトでX11 SECURITY拡張の制限を受けるようになっている。詳しくは、ssh -Y オプションと ssh_config の ForwardX11Trusted ディレクティブを参照。
(Debian 固有のもの。X11 フォワーディングはデフォルトでは X11 SECURITY 拡張の制限を受けない。このモードでは現在多くのプログラムがクラッシュするからである。ForwardX11Trusted オプションを "no" に設定すると、アップストリームの動作が復元される。 これは、クライアント側の改善によって将来的に変更される可能性がある)。
-x
X11 フォワーディングを無効にする。
-Y
信頼できる X11 フォワーディングを有効にする。 信頼された X11 転送は、X11 SECURITY 拡張の制御の対象にはならない。
(Debian固有: デフォルトの設定では、ForwardX11Trustedのデフォルトが上記のように'yes'になっているため、このオプションは-Xと同じになる。 ForwardX11Trusted オプションを 'no'に設定すると、アップストリームの動作が復元される。 今後、クライアント側の改善により変更される可能性がある)。
-y
syslog(3) システムモジュールを使ってログ情報を送信する。 デフォルトでは、この情報は標準エラー出力に送信される。
ssh はさらに、ユーザごとの設定ファイルおよびシステム全体の設定ファイルから 設定データを取得することができる。 ファイルの形式と構成オプションについては、 ssh_config で説明されている。

AUTHENTICATION

OpenSSHのSSHクライアントは、SSHプロトコル2.に対応している。

認証に利用できる方式は以下の通り。GSSAPI ベース認証、ホストベース認証、公開鍵認証、チャレンジ・レスポンス認証、およびパスワード認証である。認証方法は、上記の順序で試行されるが、PreferredAuthenticationsを使用すると、デフォルトの順序を変更することができる。

ホストベース認証は、次のように動作する。ユーザーがログインするマシンがリモートマシンの /etc/hosts.equiv または /etc/ssh/shosts.equiv にリストされており、ユーザーが非 root で、ユーザー名が双方で同じであるか、リモートマシンのユーザーのホームディレクトリに ~/.rhosts または ~/.shosts ファイルが存在し、クライアントマシンの名前とそのマシンのユーザー名が含まれる行があれば、そのユーザはログインできると見なされる。さらに、login が許可されるためには、サーバはクライアントのホスト鍵 (後述の /etc/ssh/ssh_known_hosts および ~/.ssh/known_hosts の説明を参照) を確認することができなくてはならない。この認証方法は、IPスプーフィング、DNSスプーフィング、およびルーティングスプーフィングによるセキュリティホールを塞ぐ。(管理者向け注意事項 /etc/hosts.equiv、~/.rhosts、および一般的なrlogin/rshプロトコルは、本質的に安全ではないので、セキュリティが必要な場合は無効にすべきである)。

公開鍵認証は次のように動作する。この方式は公開鍵暗号方式に基づいている。暗号化と復号化が別々の鍵で行われ、暗号化鍵から復号化鍵を導き出すことが不可能な暗号方式を使用している。各ユーザーは、認証のために公開鍵と秘密鍵のペアを作成するというものである。ssh は、DSA、ECDSA、Ed25519、RSA アルゴリズムのいずれかを使用して、 公開鍵認証プロトコルを自動的に実装する。ssl(7) の HISTORY セクション (OpenBSD 以外のシステムでは、 http://www.openbsd.org/cgi-bin/man.cgi?query=ssl&sektion=8#HISTORY を参照) に、 DSA と RSA アルゴリズムについての簡単な説明がある。

~/.ssh/authorized_keys ファイルには、ログインに許可されている公開鍵が一覧表示される。 ユーザがログインすると、ssh プログラムはサーバに、認証に使用する鍵ペアを通知する。 クライアントは秘密鍵にアクセスできることを証明し、サーバは対応する公開鍵がそのアカウントを受け入れることを許可されているかどうかを確認する。

サーバは、別の方法で認証を完了した後、公開鍵認証が成功しなかったエラーをクライアントに通知することがある。 これらのエラーは、LogLevel を DEBUG 以上にすることで確認できる (例: -v フラグを使用する)。

ユーザは ssh-keygen を実行して、自分の鍵ペアを作成する。 これは秘密鍵を ~/.ssh/id_dsa (DSA), ~/.ssh/id_ecdsa (ECDSA), ~/.ssh/id_ecdsa_sk (authenticator-hosted ECDSA), ~/.ssh/id_ed255 (DSA) に格納する。公開鍵は ~/.ssh/id_dsa.pub (DSA), ~/.ssh/id_ecdsa.pub (ECDSA), ~/.ssh/id_ecdsa_sk.pub (authenticator-hosted ECDSA), ~/.ssh/id_ed25519.pub (Ed25519)、 ~/.ssh/id_ed25519_sk.pub (authenticator-hosted Ed25519)、 ~/.ssh/id_rsa.pub (RSA) をユーザのホームディレクトリに配置する。 その後、ユーザは公開鍵をリモートマシンのホームディレクトリの ~/.ssh/authorized_keys にコピーする必要がある。 authorized_keys ファイルは、従来の ~/.rhosts ファイルに相当するもので、1 行に 1 つの鍵が記述されているが、非常に長い行になることもある。 この後、ユーザはパスワードを与えずにログインできるようになる。

公開鍵認証のバリエーションとして、証明書認証がある。これは、一連の公開鍵／秘密鍵の代わりに、署名された証明書を使用する。 これには、多数の公開鍵/秘密鍵の代わりに、単一の信頼できる認証局を使用できるという利点がある。 詳細は ssh-keygen の CERTIFICATES セクションを参照。

公開鍵認証や証明書認証を使用する最も便利な方法は、認証エージェントを使用することである。 詳細は ssh-agent と (オプションで) ssh_config の AddKeysToAgent ディレクティブを参照。

チャレンジ・レスポンス認証は、以下のように動作する。サーバは、任意の「チャレンジ」テキストを送信し、応答を求める。 チャレンジ・レスポンス認証の例としては、BSD Authentication (login.conf(5) 参照) や PAM (OpenBSD 以外のシステムの一部) がある。

最後に、他の認証方法が失敗した場合、ssh はパスワードの入力をユーザに要求する。 パスワードはチェックのためにリモートホストに送信されるが、 すべての通信が暗号化されているため、ネットワーク上で聞いている人に パスワードを見られることはない。

ssh は、これまでに使用されたすべてのホストの識別情報を含むデータベースを 自動的に維持および確認する。 ホスト鍵は、ユーザのホームディレクトリにある ~/.ssh/known_hosts に保存される。 さらに、/etc/ssh/ssh_known_hosts ファイルは、既知のホストについて自動的にチェックされる。 新しいホストがあれば、自動的にユーザのファイルに追加されます。 ホストの識別が変更されることがあると、ssh はそのことを警告し、パスワード認証を 無効にして、暗号化を回避するために使用される可能性のあるサーバスプーフィングや中間者攻撃を防止する。 StrictHostKeyChecking オプションを使用すると、ホスト鍵が不明または変更された マシンへのログインを制御することができる。

ユーザーの身元がサーバーに承認されると、サーバーは与えられたコマンドを非インタラクティブセッションで実行するか、コマンドが指定されていない場合はマシンにログインしてインタラクティブセッションとして通常のシェルをユーザーに提供する。 リモートコマンドやシェルとの通信は、すべて自動的に暗号化される。

対話型セッションが要求された場合、デフォルトでは ssh はクライアントが対話型セッション用の疑似端末 (pty) を持っている場合にのみ、それを要求する。 フラグ -T および -t を使用すると、この動作をオーバーライドすることができる。

疑似端末が割り当てられている場合、ユーザは以下に示すエスケープ文字を使用することができる。

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

セッションは、リモートマシン上のコマンドまたはシェルが終了し、すべてのX11およびTCP接続が閉じられたときに終了する。

ESCAPE CHARACTERS

擬似端末が要求された場合、ssh はエスケープ文字を使用することで多くの機能に対応する。

チルダ文字 1 つを ~~ として送信することも、チルダに続いて以下に説明する以外の文字を送信することも可能である。 エスケープ文字は、特別な文字として解釈されるために、常に改行の後に続く必要がある。 エスケープ文字は、設定ファイルでは EscapeChar 設定ディレクティブで、コマンドラインでは -e オプションで変更することができる。

サポートされているエスケープ文字は (デフォルトの '~' を仮定して) 次のとおり。

~.
切断
~^Z
sshをバックグラウンドにする
~#
フォワーディングされた接続のリスト
~&
ログアウト時に、転送された接続/X11セッションの終了を待っているときにバックグラウンドでsshを実行
~?
エスケープキャラクターのリストを表示
~B
リモートシステムに BREAK を送信す (ピアサポートの場合のみ有効)
~C
コマンドラインを開く。 現在、-L、-R、-D オプションを使用してポートフォワーディングを追加することができる (上記参照)。 また、ローカル用の -KL[bind_address:]port、リモート用の -KR[bind_address:]port、動的ポートフォワーディング用の -KD[bind_address:]port によって、既存のポートフォワーディングをキャンセルすることが可能である。 ssh_config で PermitLocalCommand オプションが有効になっている場合、 !command によってローカルコマンドを実行することができる。 -h オプションを使用すると、基本的なヘルプが表示される。
~R
接続の再キーイングを要求（相手がサポートしている場合のみ有効）
~V
標準エラー出力時の冗長度(LogLevel)を下げる
~v
標準エラー出力時の冗長度(LogLevel)を上げる

TCP FORWARDING

任意のTCP接続を安全な経路にフォワーディングすることは、コマンドラインまたは設定ファイルで指定することができる。 TCP フォワーディングの応用例としては、メールサーバへのセキュアな接続や、ファイアウォールを通過した接続などが考えられる。

以下の例では、IRCクライアントが接続するIRCサーバーが直接暗号化通信をサポートしていないにもかかわらず、IRCクライアントの通信を暗号化することについて見ている。 これは次のように動作する:

ユーザーは ssh を使ってリモートホストに接続し、接続をフォワーディングするために使用するポートを指定する。 その後、ローカルでプログラムを起動することができ、ssh は接続を暗号化してリモートサーバにフォワーディングする。

次の例は、クライアントから "server.example.com" の IRC サーバに IRC セッションをトンネリングし、チャンネル "#users"、ニックネーム "pinky" に参加、標準 IRC ポート 6667 を使用している。

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

-fオプションは、sshの背景となるリモートコマンド "sleep 10" を指定し、トンネルを利用しようとするプログラムを起動するための時間（例では10秒）を確保するためのものである。 指定された時間内に接続が行われない場合、ssh は終了する。

X11 FORWARDING

ForwardX11 変数が "yes" に設定されていて (または上記の -X, -x, -Y オプションの説明を参照)、 ユーザが X11 を使っている (DISPLAY 環境変数が設定されている) 場合、 X11 ディスプレイへの接続は自動的にリモート側にフォワーディングされ、 シェル (やコマンド) から起動した X11 プログラムは暗号化チャネルを通り、 本物の X サーバへの接続はローカルマシンからなされるようにする。ユーザは手動でDISPLAYを設定してはいけない。X11 接続のフォワーディングは、コマンドラインまたは設定ファイルで設定することができる。

ssh によって設定された DISPLAY 値は、サーバマシンを指しますが、DISPLAY 番号は 0 よりも大きくなっている。これは正常で、ssh がサーバマシン上に「プロキシ」X サーバを作成し、 暗号化された経路で接続を転送するために起こることである。

ssh はまた、サーバマシンの Xauthority データを自動的にセットアップする。この目的のために、ランダムな認証クッキーを生成し、それをサーバの Xauthority に保存し、フォワーディングされた接続がこのクッキーを持ち、接続が開かれたときに本当のクッキーに置き換わるかどうかを確認するのである。本当の認証クッキーは、サーバマシンに送られることはない(プレーンなクッキーも送られることはない)。

ForwardAgent変数が "yes" に設定されていて(あるいは上記の -A および -a オプションの説明を参照)、ユーザが認証エージェントを使用している場合、そのエージェントへの接続は自動的にリモート側にフォワーディングされる。

VERIFYING HOST KEYS

サーバに初めて接続する際、サーバの公開鍵の指紋がユーザに提示される (オプション StrictHostKeyChecking が無効になっている場合を除く)。 フィンガープリントは ssh-keygen を使用して決定することができる。

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

fingerprintがすでに知られている場合、それを照合し、鍵を受け入れるか拒否するかを決めることができる。サーバ用のレガシー (MD5) 指紋しか利用できない場合、 ssh-keygen -E オプションを使用して、一致する指紋アルゴリズムをダウングレードすることができる。

fingerprint文字列を見るだけではホスト鍵を比較するのは難しいため、ランダムアートを使用して ホスト鍵を視覚的に比較することもできる。 VisualHostKey オプションを "yes" に設定することで、セッション自体が対話的であるかどうかに関わらず、サーバへのログイン毎に小さな ASCII グラフィックが表示されるようになる。 既知のサーバが生成するパターンを学習することで、ユーザは全く異なるパターンが表示されたときに、ホストキーが変更されたことを容易に発見することができる。 しかし、これらのパターンは曖昧でないため、覚えているパターンと似ているパターンは、ホスト鍵が同じである確率が高いだけで、保証された証明ではない。

すべての既知のホストのfingerprintとそのランダムアートのリストを得るには、次のコマンドラインを使用することができる。

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

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

この例では、クライアントを "host.example.com"というサーバーに接続する。 SSHFPリソースレコードは、まずhost.example.comのゾーンファイルに追加されなければならない。

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

出力行はzonefileに追加されなければならない。 ゾーンがフィンガープリントクエリーに応答していることを確認するため。

$ 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 の VerifyHostKeyDNS オプションを参照。

SSH-BASED VIRTUAL PRIVATE NETWORKS

ssh には tun(4) ネットワーク擬似デバイスを用いた Virtual Private Network (VPN) トンネリング機能があり、2 つのネットワークを安全に結合できるようになる。 sshd_config の設定オプション PermitTunnel は、サーバがこの機能をサポートしているかどうか、 またどのレベル (レイヤ 2 または 3 トラフィック) でサポートしているかを制御する。

次の例は、リモートネットワークのゲートウェイ 192.168.1.15 で動作している SSH サーバが許可していれば、 10.1.1.1 から 10.1.1.2 へのポイントツーポイント接続を用いて、 クライアントネットワーク 10.0.50.0/24 とリモートネットワーク 10.0.99.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 や isakmpd のようなツールで提供するのがよい。

ENVIRONMENT

sshは通常、以下の環境変数を設定する。

DISPLAY
DISPLAY変数は、X11サーバの場所を示す。 ここで、hostnameはシェルを実行するホストを示し、nは 1 以上の整数を示す。ssh は、この特別な値を使用して、安全なチャネル上で X11 接続をフォワーディングする。 通常、ユーザは DISPLAY を明示的に設定するべきではない。これは、X11 接続が安全でなくなるためである (また、必要な認証クッキーをユーザが手動でコピーする必要があるためである)。
HOME
ユーザのホームディレクトリのパスを設定する。
LOGNAME
USERの同義語。この変数を使用するシステムとの互換性のために設定される。
MAIL
ユーザのメールボックスのパスを設定する。
PATH
sshをコンパイルしたときに指定された、デフォルトのパスを設定する。
SSH_ASKPASS
ssh がパスフレーズを必要とする場合、もしターミナルから実行されていれば、 現在のターミナルからパスフレーズを読み取る。 ssh に端末が関連付けられておらず、DISPLAY と SSH_ASKPASS が設定されている場合、SSH_ASKPASS で指定されたプログラムを実行し、パスフレーズを読み込むために X11 ウィンドウを開く。 これは特に .xsession や関連するスクリプトから ssh を呼び出すときに便利である。 (マシンによっては、これを動作させるために /dev/null からの入力をリダイレクトする必要があるかもしれないことに 注意)。
SSH_ASKPASS_REQUIRE
askpass プログラムの使用をさらに制御できるようにする。 この変数が "never" に設定されると、ssh は、askpass プログラムを使用しようとはしない。 "prefer" に設定された場合、ssh は、パスワードを要求するときに、 TTY の代わりに askpass プログラムを使用することを希望する。 最後に、この変数が "force" に設定されると、DISPLAY が設定されているかどうかに関係なく、すべてのパスフレーズの入力に askpass プログラムが使用されるようになる。
SSH_AUTH_SOCK
エージェントとの通信に使用する UNIX ドメインソケットのパスを指定する。
SSH_CONNECTION
接続のクライアント側とサーバー側を識別する。 この変数には、スペースで区切られた4つの値、すなわちクライアントIPアドレス、クライアントポート番号、サーバIPアドレス、およびサーバポート番号が含まれる。
SSH_ORIGINAL_COMMAND
この変数には、強制コマンドを実行した場合の元のコマンドラインが格納される。これは、元の引数を抽出するために使用することができる。
SSH_TTY
この変数には、現在のシェルまたはコマンドに関連するttyの名前（デバイスへのパス）が設定される。 現在のセッションにttyがない場合、この変数は設定されない。
SSH_TUNNEL
オプションで sshd によって設定され、トンネル転送がクライアントによって要求された場合に割り当てられるインターフェイス名を含む。
SSH_USER_AUTH
オプションで sshd によって設定され、この変数には、セッションが確立されたときに成功した認証方法と、使用された公開鍵の一覧を示すファイルへのパス名を含めることができる。
TZ
この変数は、デーモンが起動したときに設定されていた場合、現在のタイムゾーンを示すように設定される（すなわち、デーモンは新しい接続に値を渡す）。
USER
ユーザログインの名称を設定する。

さらに、ssh は ~/.ssh/environment を読み込み、そのファイルが存在し、ユーザが環境 の変更を許可されている場合、「VARNAME=value」という形式の行を環境に追加する。 詳細については、 sshd_config の PermitUserEnvironment オプションを参照。

FILES

~/.rhosts
このファイルは、ホストベースの認証に使用される (上記参照)。マシンによっては、ユーザのホームディレクトリが NFS パーティション上にある場合、 sshd が root として読み込むため、このファイルは world-readable である必要があるかもしれない。さらに、このファイルの所有者はそのユーザでなければならず、他の誰にも書き込み権限を与えてはいけない。ほとんどのマシンで推奨されるパーミッションは、ユーザが読み取り/書き込みを行い、他のユーザがアクセスできないようにすることである。
~/.shosts
このファイルは .rhosts と全く同じように使用されるが、rlogin/rsh によるログインを許可せずに、ホストベースの認証を可能にする。
~/.ssh/
このディレクトリは、すべてのユーザー固有の設定と認証情報のデフォルトの場所である。 このディレクトリの内容全体を秘密にする一般的な要件はないが、推奨されるパーミッションは、ユーザーのための読み取り/書き込み/実行であり、他の人がアクセスできないようにする。
~/.ssh/authorized_keys
このユーザとしてログインするために使用できる公開鍵 (DSA、ECDSA、Ed25519、RSA) を一覧表示する。このファイルの形式は sshd のマニュアルページで説明されている。 このファイルの機密性は高くないが、推奨されるパーミッションは、そのユーザの読み取り/書き込みで、他のユーザがアクセスできないようにする。
~/.ssh/config
これは、ユーザごとの設定ファイルである。 ファイルの形式と構成オプションは ssh_config で説明されている。 悪用される可能性があるため、このファイルには厳格なパーミッションが必要である。
ユーザは読み取り/書き込みが可能で、他のユーザは書き込みができないようにする。 また、グループ書き込みが可能であっても、そのグループにそのユーザしか含まれない場合は、書き込みができない。
~/.ssh/environment
環境変数の追加定義を含んでいる。ENVIRONMENT を参照。
~/.ssh/id_dsa
~/.ssh/id_ecdsa
~/.ssh/id_ecdsa_sk
~/.ssh/id_ed25519
~/.ssh/id_ed25519_sk
~/.ssh/id_rsa
認証のための秘密鍵が含まれている。 これらのファイルには機密データが含まれているため、ユーザは読むことができるが、他のユーザはアクセスできないようにする必要がある (読み取り/書き込み/実行)。 このファイルの機密部分を AES-128 で暗号化するために使用される鍵を生成する際に、パスフレーズを指定することが可能である。
~/.ssh/id_dsa.pub
~/.ssh/id_ecdsa.pub
~/.ssh/id_ecdsa_sk.pub
~/.ssh/id_ed25519.pub
~/.ssh/id_ed25519_sk.pub
~/.ssh/id_rsa.pub
認証のための公開鍵が含まれている。 これらのファイルは機密情報ではないので、誰でも読むことができる（その必要はない）。
~/.ssh/known_hosts
ユーザがログインしたすべてのホストのうち、システム全体の既知のホスト鍵の一覧にまだ 含まれていないホスト鍵の一覧が含まれる。 このファイルの形式の詳細については、sshd を参照。
~/.ssh/rc
このファイルのコマンドは、ユーザがログインしたとき、ユーザのシェル (またはコマンド) が起動される直前に ssh によって実行される。 詳細は sshd のマニュアルページを参照。
/etc/hosts.equiv
このファイルは、ホストベースの認証用である (上記を参照)。 root によってのみ書き込み可能であるべきである。
/etc/ssh/shosts.equiv
このファイルは hosts.equiv とまったく同じ方法で使用されるが、rlogin/rsh でのログインを許可せずに、ホストベースの認証を可能にする。
/etc/ssh/ssh_config
システム全体の構成ファイルである。 このファイルの形式と設定オプションについては、 ssh_config に記載されている。
/etc/ssh/ssh_host_key
/etc/ssh/ssh_host_dsa_key
/etc/ssh/ssh_host_ecdsa_key
/etc/ssh/ssh_host_ed25519_key
/etc/ssh/ssh_host_rsa_key
これらのファイルにはホスト鍵の秘密部分が含まれており、ホストベースの認証に使用される。
/etc/ssh/ssh_known_hosts
既知のホスト鍵のシステム全体のリスト。 このファイルは、組織内のすべてのマシンの公開ホスト鍵が含まれるよう、システム管理者が用意する必要がある。 このファイルは、globalで読み取り可能である必要がある。このファイルの形式の詳細については、sshd を参照。
/etc/ssh/sshrc

このファイルのコマンドは、ユーザがログインしたとき、ユーザのシェル (またはコマンド) が起動される直前に、ssh によって実行される。 詳細は sshd のマニュアルページを参照。

EXIT STATUS

ssh は、リモートコマンドの終了ステータスで終了し、エラーが発生した場合は 255 で終了する。

SEE ALSO

scp, sftp, ssh-add, ssh-agent, ssh-argv0, ssh-keygen, ssh-keyscan, tun(4), ssh_config, ssh-keysign, sshd

STANDARDS

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, RFC4344, 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, RFC5656, 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).

AUTHORS

OpenSSH is a derivative of the original and free ssh 1.2.12 release by Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt and Dug Song removed many bugs, re-added newer features and created OpenSSH. Markus Friedl contributed the support for SSH protocol versions 1.5 and 2.0.

External Link

Retrieved from "https://wiki.tiffa.net/w/index.php?title=/usr/bin/ssh&oldid=2251"