SSH(1)

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

書式
ssh [-l ログイン名] ホスト名 | ユーザ@ホスト名 [コマンド]

ssh [-afgknqstvxACNTX1246] [-b bindするアドレス] [-c 暗号化オプション] [-e エスケープ文字] [-i identityファイル] [-l ログイン名] [-m MAC指定] [-o オプション] [-p ポート番号] [-F 設定ファイル] [-L ポート番号: ホスト: ホスト側ポート番号] [-R ポート番号: ホスト: ホスト側ポート番号] [-D ポート番号] ホスト名 | ユーザ@ホスト名 [コマンド]

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

ssh は指定された ホスト名 に接続し、ログインします。 ユーザはリモートマシンに対して、本人であることを証明する必要があります。 これにはプロトコルのバージョンに応じたいくつかの方法のうち一つを使います:

  SSH プロトコル バージョン 1

最初に、ユーザがリモートマシン上の /etc/hosts.equiv あるいは /etc/shosts.equiv に記されているマシンからログインしてきて、 さらにそのユーザの名前が両方のホストで同じならば、そのユーザは すぐさまログインが許可されます。 つぎに、 .rhosts あるいは .shosts がリモートホスト上のそのユーザのホームディレクトリに存在していて、そこに クライアントホスト名とそのホスト上におけるユーザ名が記されている 行が存在すれば、そのユーザはログインが許可されます。 この形の認証はふつう、これ単体ではサーバから許可されません。 安全ではないからです。

2番目の認証方法は rhosts または hosts.equiv を RSA ベースのホスト認証と組み合わせて使うことです。 これは、もしログインが $HOME/.rhosts, $HOME/.shosts, /etc/hosts.equiv, あるいは /etc/shosts.equiv で許可されていて、さらにサーバ側がクライアントのホスト鍵 ( FILES セクションの /etc/ssh/ssh_known_hosts と $HOME/.ssh/known_hosts の項を参照) を確認できる場合にのみ ログインが許可されます。この認証方法を使うと IP 詐称、 DNS 詐称 および 経路詐称 によるセキュリティーホールをふさぐことができます。 [管理者の方へ: /etc/hosts.equiv や $HOME/.rhosts 、 そして一般的な rlogin/rsh プロトコルは 本質的に危険であり、セキュリティを考えるなら禁止しなくてはいけません]

3つめの認証方法として、 ssh は RSA ベースの認証をサポートしています。 このやりかたは公開鍵暗号技術に基づいています: 暗号システムのなかには、 暗号化／復号化をそれぞれ別の鍵をつかっておこなうことができ、さらに復号化用の 鍵から暗号化用の鍵が推測することはできないものがあります。RSA はこのような 暗号システムのひとつで、以下のようなアイデアで認証をおこないます。 まず各ユーザは、認証のための「秘密鍵」「公開鍵」とよばれる鍵の対を つくります。サーバは公開鍵を知っていますが、秘密鍵のほうはユーザだけが 知っているものとします。 $HOME/.ssh/authorized_keys ファイルには、ログインが許可されている公開鍵の一覧が書かれています。 ユーザがログインするさい、 ssh プログラムは、そのユーザがどの鍵をつかって 認証したがっているかをサーバに伝えます。サーバはこの鍵が許される ものであるかどうかを検査し、もし許されているならば、ユーザ (実際には ユーザのために走っている ssh プログラム) に「チャレンジ (挑戦)」と 呼ばれるものを送ります。これはサーバ側で生成された でたらめな数で、 ユーザの公開鍵によって暗号化されています。このチャレンジはユーザが もっている正しい秘密鍵によってのみ復号化することができます。ユーザ側の クライアントはこのときチャレンジを秘密鍵をつかって復号化してみせること で、秘密鍵の中身をサーバ側に見せることなしに、それを持っていることを サーバに対し証明するのです。

ssh は RSA の認証プロトコルを自動的におこないます。ユーザは ssh-keygen(1) をつかって自分の RSA 鍵の対をつくります。このプログラムは秘密鍵を ユーザのホームディレクトリ内の $HOME/.ssh/identity ファイルに、公開鍵を $HOME/.ssh/identity.pub ファイルに格納します。ユーザはつぎにこの identity.pub をリモートマシン上の自分のホームディレクトリにある $HOME/.ssh/authorized_keys ファイルにコピーしなくてはいけません ( authorized_keys ファイルは従来の $HOME/.rhosts ファイルに相当し、1行ごとにひとつの鍵を格納します。 各行はかなり長くなることもあります)。 この後、ユーザはパスワードなしでログインすることができます。 RSA 認証は rhosts 認証よりもずっと安全です。

RSA 認証を使う際にいちばん便利なのは「認証エージェント」と呼ばれる ものを使うことでしょう。詳しくは ssh-agent(1) のマニュアルページをごらんください。

もし他の認証方法が失敗した場合、 ssh はユーザにパスワードを要求します。 このパスワードは検査のためリモートホストに送られますが、 すべての通信は暗号化されているため、ネットワークを盗聴している何物かに よってパスワードが見られてしまうようなことはありません。

  SSH プロトコル バージョン 2

ユーザがバージョン 2 のプロトコルで接続したときにも、同様の認証方法が 使えるようになります。まずクライアントは最初にホストベース認証を 試そうとするでしょう。これは PreferredAuthentications のデフォルト値によります。この認証に失敗すると、次は公開鍵認証を 試みます。これもだめなら最後にキーボードインタラクティブ認証と パスワード認証を試みます。

公開鍵による方法は前節に書かれている RSA 認証と似ており、 RSA または DSA アルゴリズムを使うことができます。 クライアントは自分の秘密鍵である $HOME/.ssh/id_dsa または $HOME/.ssh/id_rsa を使ってセッション識別子に署名し、この結果をサーバに送ります。 サーバはこれに対応する公開鍵が $HOME/.ssh/authorized_keys ファイル中に存在するかどうか検査し、 もし双方の鍵が存在して、なおかつその署名が正しければアクセスを 許可します。 セッション識別子は共有 Diffie-Hellman 値によって与えられます。 この値を知ることができるのはクライアントとサーバだけです。

公開鍵認証が失敗するか、あるいはそれが使えなかった場合、 リモートホストにはそのユーザであることを証明するパスワードを 送ることができます。

加えて、 ssh ではホスト間認証やチャレンジ・レスポンス認証もサポートしています。

さらにプロトコル 2 では、秘匿性 (通信は 3DES, Blowfish, CAST128 または Arcfour によって暗号化されます) やデータの改竄を防ぐ機構 (data integrity protection) (hmac-sha1, hmac-md5) が提供されています。 プロトコル 1 では通信内容が改竄されていないことを保証するような 強力なメカニズムは存在しないので注意してください。

  ログインセッション と リモート実行

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

仮想端末が割り当てられている場合 (通常のログインセッション時)、 ユーザは以下のエスケープ文字を使うことができます。

仮想端末が割り当てられていない場合、そのセッションは透過になります。 そのため、バイナリデータでも確実に転送できます。 ほとんどのシステムでは、たとえ仮想端末が割り当てられている場合でも エスケープ文字に “none” を設定することによって、そのセッションを透過にすることができます。

セッションは、リモートマシン上のコマンドやシェルが完了し、すべての X11 や TCP/IP 接続が閉じられると終了します。このときのリモート プログラムの終了状態が ssh の終了状態となります。

  エスケープ文字

仮想端末が割り当てられている場合、ssh ではエスケープ文字を使った 機能がいくつかサポートされています。

チルダ記号そのものを 1回入力するには ~~ を押すか、上で述べられている以外の文字をチルダに続けます。 エスケープ文字は、つねに改行の直後に来なければ特別な文字とは 見なされません。エスケープ文字は、設定ファイルの EscapeChar 設定項目あるいはコマンドラインの -e オプションで変更できます。

現在サポートされているエスケープ機能 (エスケープ文字はデフォルトの ‘~’ と仮定します) :

~.  接続を切る

~^Z sshをバックグラウンドに移行させる

~#  いま転送されている接続の一覧を表示する

~&  sshをバックグラウンドに移行させ、転送された接続あるいは X11 の セッションが終了するのを待ってログアウトする

~?  エスケープ文字の一覧を表示する

~C  コマンドラインをオープンする ( -L や -R オプションを使っていて、ポート転送を追加したい場合に有効です)

~R  その接続の rekeying を要求する (SSH プロトコル バージョン 2 で、 なおかつ相手がこれをサポートしているときのみ有効)

  X11 と TCP の転送

ForwardX11 項目が “yes” に設定されており (または後の -X および -x オプションを参照してください)、 ユーザが X11 を使っている (環境変数 DISPLAY が設定されている) 場合、X11 ディスプレイへの接続は 自動的にリモート側に転送されます。つまり、 シェル (あるいはコマンド) から起動された X11 プログラムはみな 暗号化された通信路を通り、本来の X サーバへの接続は ローカルマシン上からなされるようになります。 ユーザは DISPLAY を手動で設定すべきではありません。 X11 接続の転送はコマンドラインあるいは設定ファイルによって設定できます。

ssh によって設定された DISPLAY の値はサーバマシン上を指すようになっていますが、 ディスプレイ番号は 0 より大きい値になっているでしょう。 これは正常な状態です。 ssh は暗号化された通信路を介して接続を転送します。 そのため、サーバマシン上に X サーバの “プロキシー” をつくるのでこうなるのです。

また、 ssh はサーバマシン上で Xauthority 情報を自動的に用意します。 ssh はこのためにランダムな認証クッキーを生成し、サーバ側の Xauthority に格納し、接続が転送されるときはすべてこのクッキーを持たせる ようにします。そして接続が開かれるときに、これが本物のクッキーと置き換わる ようにするのです。本物の認証クッキーがサーバ側に送られることは 決してありません (し、暗号化されないままでクッキーが送られる こともありません)。

ForwardAgent 設定項目が “yes” になっていて、ユーザが認証エージェントを使っている場合、 認証エージェントに対する接続は自動的にリモート側に転送されます。 (以下で説明する -A and -a オプションも参照のこと)。

安全な通信路をつかった任意の TCP/IP 接続への転送は、 コマンドラインあるいは設定ファイルで指定します。TCP/IP 転送の 応用として、ひとつは電子預金への安全な接続が考えられます。ほかにも ファイヤーウォールをまたいで接続するなどの使いみちがあるでしょう。

  サーバ認証

ssh はこれまでに使った鍵すべてが入っているデータベースを 自動的に保持し、検査します。これらのうち、ホスト鍵はユーザの ホームディレクトリにある $HOME/.ssh/known_hosts に格納されます。これらに加え、 /etc/ssh/ssh_known_hosts も既知のホストとして自動的に検査されます。 新しいホストは、ユーザ側のファイルに自動的に追加されていきます。 もしあるホストの鍵がこれまでと変わっていた場合、 ssh は警告を発してパスワード認証を禁止します。 これはトロイの木馬がユーザのパスワードを盗むのを防ぐためです。 この仕組みのもうひとつの目的は、どこか他の場所で man-in-the-middle 攻撃がおこなわれ、暗号化がたくみにかわされてしまうのを防ぐことです。 StrictHostKeyChecking 設定項目はホスト鍵が知られていなかったり、 それが変更されていた場合のログインを防ぐために使われます。

オプションは次のとおりです:

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

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

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

-b bindするアドレス
    複数のインタフェイスやエイリアスされたアドレスをもつ マシン上で、使用するインタフェイスを指定します。

-c blowfish|3des|des
    このセッションで使われる暗号化の方法を指定します。デフォルトでは 3des が使われます。これが安全であると考えられているためです。 3des (トリプル des) は 3つの異なる鍵をつかって 暗号化-復号化-暗号化をおこないます。 blowfish は高速なブロック暗号化アルゴリズムで、かなり安全であり、 3des よりもずっと高速です。 des は、 3des 暗号をサポートしていない、もはや古くなったプロトコル 1 の実装と 相互運用するためにのみサポートされています。 des 暗号は弱いため、このオプションを使用することはおすすめできません。

-c 暗号化オプション
    プロトコル バージョン 2 では、カンマで区切ったリストにより、 暗号化の方法を優先順位をつけて指定することができます。 暗号化についての詳しい情報は 暗号化 の項をご覧ください。

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

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

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

-i identityファイル
    RSA認証 あるいは DSA 認証のさいに identity (秘密鍵) を読むファイルを指定します。 デフォルトは、プロトコル バージョン 1 の場合 ユーザのホームディレクトリにある $HOME/.ssh/identity 、プロトコル バージョン 2 の場合は $HOME/.ssh/id_rsa および $HOME/.ssh/id_dsa になっています。identity ファイルは設定ファイルによって、 ホストごとに指定することもできます。複数の -i オプションを指定することも可能です。 (設定ファイルで複数の鍵を指定することもできます。)

-I スマートカードデバイス
    使用するスマートカードデバイスを指定します。引数には、 ユーザの RSA 秘密鍵を格納するスマートカードと ssh が通信するのに使うデバイスを指定します。

-k  Kerberos チケットおよび AFS トークンの転送を禁止します。 これは設定ファイルによって、ホストごとに指定することもできます。

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

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

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

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

-o オプション
    設定ファイルと同じ形式でオプションを与えたいときに使用します。 これはコマンドラインオプションでは指定できないオプションを 指定したいときに便利です。

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

-q  静かなモード。すべての警告メッセージや診断メッセージは抑制されます。

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

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

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

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

-x  X11 の転送を禁止します。

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

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

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

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

-L ポート番号:ホスト:ホスト側ポート番号
    与えられたローカル (クライアント) ホスト上のポートが、 与えられたリモートホスト上のポートに転送されるようにします (ローカル→リモートのポート転送)。 これはローカル側で port に listen (接続受け付け) 用の ソケットを割り当てることによりおこなわれます。 このポートに向けておこなわれた接続はつねに 安全な通信路を経由してリモートマシン上に到達し、そこから host のポート hostport に接続されるようになります。 ポート転送は設定ファイルによっても指定できます。特権ポートを 転送できるのは root だけです。IPv6 アドレスの場合は、指定する 形式が異なります: port/host/hostport

-R ポート番号:ホスト:ホスト側ポート番号
    与えられたリモート (サーバ) ホスト上のポートが、 与えられたローカルホスト上のポートに転送されるようにします (リモート→ローカルのポート転送)。 これはリモート側で port に listen (接続受け付け) 用の ソケットを割り当てることによりおこなわれます。 このポートに向けておこなわれた接続はつねに 安全な通信路を経由してローカルマシン上に到達し、ここから host のポート hostport に接続されるようになります。 ポート転送は設定ファイルによっても指定できます。特権ポートを 転送できるのは、リモートマシン上に root としてログインしているときだけです。 IPv6 アドレスの場合は、指定する形式が異なります: port/host/hostport

-D ポート番号
    ローカルホスト側における、アプリケーションレベルの “動的な” ポート転送を指定します。 これは次のように実現しています。まずローカル側で ポート番号 を listen するソケットを割り当て、このポートに向けて 接続が張られると、その接続はつねに安全な通信路に転送されるように なります。そして、ここでアプリケーションプロトコルが使われ、 そのリモートマシンからどこに接続するかを決めることができます。 今のところ SOCKS4 プロトコルが使われており、 ssh は SOCKS4 サーバのようにふるまいます。 特権ポートを転送できるのは root だけです。 ダイナミックポート転送は設定ファイルでも指定できます。

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

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

-4  ssh が IPv4 アドレスのみを使うよう強制します。

-6  ssh が IPv6 アドレスのみを使うよう強制します。

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

環境変数
ssh はふつう以下の環境変数を設定します:

DISPLAY
    環境変数 DISPLAY は X11 サーバの場所を示しています。これは ssh によって、 “hostname:n” という形の値が自動的に設定されます。 ここで hostname の部分はシェルが走っているホストを表しており、 n は n >= 1 の整数です。 ssh は X11 接続を安全な通信路で転送するために、この特別な値を使います。 X11 の接続が安全でなくなってしまうため、ユーザは環境変数 DISPLAY を自分で設定すべきではありません (また、それをやってしまうとユーザは認証に必要なクッキーを手で コピーしなければならなくなります)。

HOME
    ユーザのホームディレクトリのパス名が設定されます。

LOGNAME
    環境変数 USER と同じです。 これは、この変数を使うシステムで互換性を保つために設定されます。

MAIL
    ユーザのメールボックスのパス名が設定されます。

PATH
    デフォルトの PATH です。これは ssh のコンパイル時に指定されます。

SSH_ASKPASS
    パスフレーズを入力するさい、 ssh が端末から起動されていると ssh はパスフレーズをその端末から要求します。 ssh が制御できる端末を持っておらず、環境変数 DISPLAY および SSH_ASKPASS が設定されている場合、 ssh は 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 は $HOME/.ssh/environment ファイルが存在してアクセス可能になっていればそれを読み込み、 “VARNAME=value” という形式の行を環境変数に追加します。 sshd_config(5) の PermitUserEnvironment 設定項目を参照してください。

関連ファイル

$HOME/.ssh/known_hosts
    ユーザがログインしたことのあるホストすべてのホスト鍵を保持します ( /etc/ssh/ssh_known_hosts にあるものを除く)。 sshd(8) も見てください。

$HOME/.ssh/identity, $HOME/.ssh/id_dsa, $HOME/.ssh/id_rsa
    認証のための identity (秘密鍵および公開鍵) が格納されています。 それぞれ、プロトコル 1 の RSA 認証用、プロトコル 2 の DSA 認証用、 プロトコル 2 の RSA 認証用です。 これらのファイルには他人に見られてはいけないデータが入っているため、 そのユーザには読めても、他人からはアクセスできないようにしてください (読み込み/書き込み/実行属性ともに)。 ssh は、他人にアクセスできるようになっている identity ファイルは無視するので注意してください。 鍵を作成するときにパスフレーズを指定することも可能です。この パスフレーズはファイル中の見られるべきでない部分を、 3DES を使って暗号化するのに用いられます。

$HOME/.ssh/identity.pub, $HOME/.ssh/id_dsa.pub, $HOME/.ssh/id_rsa.pub
    認証のための公開鍵です (ここには identity ファイルの 公開できる部分が可読形式で格納されています)。 $HOME/.ssh/identity.pub ファイルの内容は、プロトコル バージョン 1 の RSA 認証を 使ってログインしたいすべてのマシン上の $HOME/.ssh/authorized_keys ファイルに含まれている必要があります。また、 $HOME/.ssh/id_dsa.pub および $HOME/.ssh/id_rsa.pub ファイルの内容も同様に、 プロトコル バージョン 2 の RSA/DSA 認証を 使ってログインしたいすべてのマシン上の $HOME/.ssh/authorized_keys ファイルに含まれている必要があります。 これらのファイルは見られてもよいため、他人が読めるように しておいてもかまいません (が、別にそうする必要はありません)。 これらのファイルが自動的に使われることは決してありません。 また、必要でもありません。これらはただ単に ユーザの便宜をはかるために提供されています。

$HOME/.ssh/config
    ユーザごとの個人用設定ファイルです。 このファイルの形式と設定項目は ssh_config(5) で説明されています。

$HOME/.ssh/authorized_keys
    このユーザのログインに使われる公開鍵 (RSA/DSA) の一覧です。この形式は sshd(8) のマニュアルで説明されています。 このファイルのいちばん簡単な形式は .pub 公開鍵ファイルと同じものです。 これは特に見られてまずいというものではないのですが、 できればこのユーザからは読み/書きが可能で、 他人からはアクセス不可能なパーミッションに設定しておくのがよいでしょう。

/etc/ssh/ssh_known_hosts
    システム全体の known_hosts ファイルです。 このファイルはシステム管理者によって用意され、その組織内で 使われるすべてのマシン用の公開ホスト鍵を格納するようになっているはずです。 このファイルは誰でも読めるようになっていなければいけません。 このファイルは 1行ごとに次のような形式で公開鍵を格納しています (各フィールドはスペースで区切られます): システム名、公開鍵およびオプションとしてコメント用フィールド。 同一のマシンにいくつかの 異なる名前が使われている場合は、それらはすべてカンマで区切って 列挙する必要があります。この形式は sshd(8) マニュアルページで説明されています。

    sshd(8) がログイン時にクライアント側のホストを検証するさいには、 システムの別名 (ネームサーバの返す canonical name) が 使われます。これ以外の名前が必要なのは次のような理由によります。 ssh は、鍵を検査する前にユーザの指定した名前を (DNS 的に) 正式なものに 変換する、ということをしません。なぜなら もし何物かがネームサーバに仕掛けを入れれば、 これを使ってホスト認証をだますことが可能になってしまうからです。

/etc/ssh/ssh_config
    システム全体にわたる設定ファイルです。 このファイルの形式と設定項目は ssh_config(5) で説明されています。

/etc/ssh/ssh_host_key, /etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_rsa_key
    これら 3つのファイルにはホスト秘密鍵が格納されています。 これらは、 RhostsRSAAuthentication (rhosts-RSA 認証) および HostbasedAuthentication (ホストベース認証) で使われます。 プロトコル バージョン 1 で RhostsRSAAuthentication を使う場合、ホスト鍵は root にしか読めないので ssh を setuid root しておく必要があります。 プロトコル バージョン 2 の場合、 ssh は HostbasedAuthentication のホスト鍵のアクセスに ssh-keysign(8) を使用します。 これで、この認証方法を使うときも ssh を setuid root しておく必要がなくなります。 デフォルトでは ssh は setuid root されていません。

$HOME/.rhosts
    このファイルは .rhosts 認証で使われる、ログインを許可されたホスト名と ユーザの対の一覧です。(このファイルは rlogin と rsh でも 使われるので、安全ではありません。) ファイル中の各行はホスト名 (ネームサーバが返す正式な形式のもの) およびそのホストでの ユーザ名をスペースで区切って格納します。 ユーザのホームディレクトリが NFS パーティション上にあるような マシンでは、このファイルは誰にでも読み込み 可能でなければなりません。なぜなら sshd(8) はこれを root として読むからです。 加えて、このファイルはそのユーザの所有でなければならず、 他の人が書き込み可能であってはいけません。 ほとんどのマシンにおける推奨されるパーミッションは、そのユーザが 読み書き可能で、他の人はアクセス不可能というものです。

    デフォルトでは、 sshd(8) で .rhosts 認証が許可されるには、 まず RSA ホスト認証に成功することが必要になっています。 サーバマシンが /etc/ssh/ssh_known_hosts の中にそのクライアントのホスト鍵を持っていない場合は、 $HOME/.ssh/known_hosts ファイルに格納されます。こうするのに いちばん簡単な方法は、サーバマシンから ssh を使ってクライアントマシンに接続し直すことです。 こうすることによって、そのホスト鍵が自動的に $HOME/.ssh/known_hosts に追加されます。

$HOME/.shosts
    このファイルは .rhosts とまったく同じように扱われます。このファイルは、 rlogin や rsh(1) ではログインできないようにしつつ、 ssh で rhosts 認証を使えるようにするためにあります。

/etc/hosts.equiv
    このファイルは .rhosts 認証 で使われます。ここには正式なホスト名が各行に記載されています (この形式の完全な説明は sshd(8) マニュアルページにあります)。このファイルに クライアントホストが載っていると、クライアント側とサーバ側の ユーザ名が同じ場合にログインは自動的に許可されます。普通は RSA ホスト認証が成功してからでなくてはいけません。このファイルは root のみが書き込めるようにしておくべきです。

/etc/shosts.equiv
    このファイルは /etc/hosts.equiv とまったく同じように扱われます。このファイルは ssh を使うが、rsh/rlogin は使わないユーザのログインを許可するのに便利です。

/etc/ssh/sshrc
    このファイルのコマンドは、ユーザがログインしてシェル (あるいはコマンド) が開始する直前に ssh によって実行されます。より詳しい情報については sshd(8) マニュアルページを見てください。

$HOME/.ssh/rc
    このファイルのコマンドは、ユーザがログインしてシェル (あるいはコマンド) が開始する直前に ssh によって実行されます。より詳しい情報については sshd(8) マニュアルページを見てください。

$HOME/.ssh/environment
    環境変数の追加定義を格納します。上の 環境変数 の節を見てください。

診断
ssh は終了状態として、リモートコマンドの終了状態を返します。 エラーが発生した場合は 255 を返します。

作者
OpenSSH は Tatu Ylonen による、フリーな オリジナル版 ssh 1.2.12 リリースから派生したものです。 Aaron Campbell、 Bob Beck、 Markus Friedl、 Niels Provos、 Theo de Raadt および Dug Song が多くのバグをとり除き、 新しい機能をふたたび追加して OpenSSH をつくりました。 SSH プロトコル バージョン 1.5 および 2.0 のサポートは Markus Friedl の貢献によるものです。

日本語訳
新山 祐介 (yusuke at cs . nyu . edu) 2002/10/15 (for 3.5p1)

関連項目
rsh(1), scp(1), sftp(1), ssh-add(1), ssh-agent(1), ssh-keygen(1), telnet(1), ssh_config(5), ssh-keysign(8,) sshd(8) T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen, SSH Protocol Architecture, draft-ietf-secsh-architecture-12.txt, January 2002, work in progress material.