ssh [-l login_name] hostname | user@hostname [ command]
ssh [-afgknqstvxACNTX1246] [-b bind_address] [-m mac_spec]
[-c cipher_spec] [-e escape_char] [-i identity_file]
[-i PKCS#11-URI]
[-l login_name] [-F configfile] [-o option] [-p port]
[-L [bind_address:]port:host:hostport]
[-R [bind_address:]port:host:hostport]
[-D [bind_address:]port] hostname | user@hostname [command]
ssh (Secure Shell) は、リモートマシンにログインしたり、リモートマシン上でコマンドを実行したりするためのプログラムです。これは、rlogin や rsh に代わるものとして開発され、安全でないネットワーク上にある 2 台の信頼できないホスト間において、暗号化された安全な通信を提供します。X11 接続と任意の TCP/IP ポートも、セキュリティー保護されたチャネルを介して転送されます。
この ssh の実装は、SSH プロトコルバージョン 1 と 2 を同時にサポートします。v1 プロトコルのセキュリティー上の弱点のため、可能な場合は v2 のみ実行するようにしてください。
v1 用のサポートは、ssh v1 サーバーが存在するサイトが v2 に移行することをサポートするために提供されています。v1 は今後のリリースでサポートされなくなる可能性があります。
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 によってログインが許可されていて、さらにサーバーがクライアントのホスト鍵 (「ファイル」セクションの「/etc/ssh_known_hosts」を参照) を検証できる場合にだけ、ログインが許可されるということです。この認証方式では、IP スプーフィング、DNS スプーフィング、およびルーティングスプーフィングによるセキュリティーホールをふさぎます。
管理者の方への注意: /etc/hosts.equiv、$HOME/.rhosts、および一般的な rlogin/rsh プロトコルは本質的に安全ではないため、セキュリティーが要求される場合は無効にするべきです。
3 番目の認証方式として、ssh は RSA ベースの認証をサポートしています。この手法は公開鍵暗号方式に基づいています。暗号方式の中には、暗号化と復号化がそれぞれ異なる鍵を使って行われ、暗号化鍵から復号化鍵を導き出せないものがあります。RSA はそのような暗号方式の 1 つであり、次のような仕組みに基づいて認証を行います。まず、各ユーザーは認証のための公開鍵と秘密鍵のペアを作成します。サーバーは公開鍵を知っていますが、秘密鍵を知っているのはユーザーだけです。$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 行につき 1 つの鍵を保持しますが、各行は非常に長くなることがあります)。このあと、ユーザーはパスワードなしでログインできるようになります。RSA 認証は、rhosts 認証よりもはるかに安全です。
RSA 認証を使用するもっとも便利な方法は、認証エージェントを使うことでしょう。詳細は、ssh-agent(1) を参照してください。
他の認証方式が失敗した場合、ssh はパスワードを入力するようユーザーに要求します。このパスワードは検査のためにリモートホストに送られます。しかし、すべての通信は暗号化されているため、ネットワークを盗聴している何者かによってパスワードが見られることはありません。
SSH プロトコルバージョン 2 では、SSH プロトコルバージョン 1 で利用できる認証方式に似たものも含めて、複数のユーザー認証方式をサポートしています。これらの認証メカニズムは、クライアントとサーバーによってネゴシエーションが行われ、クライアントは PreferredAuthentications クライアント構成オプションで指定された順番で各方式を試します。サーバーは、どの時点でプロトコルの認証フェーズを完了するのに十分な数の認証方式が正常に通過したかを決めます。
ユーザーがプロトコルバージョン 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 を使って暗号化される) や整合性 (hmac-sha2-256、hmac-sha2-256-96、hmac-sha2-512、hmac-sha2-512-96、 hmac-sha1、および hmac-md5) を保持するためのメカニズムも備わっています。プロトコル 1 には、接続の整合性を保証するための強力なメカニズムがありません。
そのユーザーが本人であることが確認できると、サーバーは指定されたコマンドを実行するか、ユーザーをそのマシンにログインさせてリモートマシン上で通常のシェル環境を提供します。リモートコマンドまたはシェルとの通信はすべて自動的に暗号化されます。
仮想端末が割り当てられている場合 (通常のログインセッション時)、ユーザーは後述するエスケープ文字を使用できます。仮想端末が割り当てられている場合 (通常のログインセッション時)、ユーザーは ~. で接続を切り離したり、~^Z で ssh を中断したりできます。転送されたコネクションの一覧は ~# で表示できます。セッションがブロックされて、転送された X11 コネクションまたは TCP/IP コネクションが終了待ちになっている場合、~& で ssh をバックグラウンドに移行させることができます (ユーザーシェルがアクティブになっている間はシェルがハングアップすることがあるため、これは使用しないでください)。使用できるエスケープ文字の一覧は、~? で表示できます。
チルダ文字を 1 つだけ送るには、~~ を押すか、前述した文字以外の文字をチルダのあとに続けます。エスケープ文字は、必ず改行の直後に入力されなければ特殊な文字とは見なされません。エスケープ文字は、構成ファイルまたはコマンド行で変更できます。
仮想端末 (pseudo tty) が割り当てられていない場合、そのセッションは透過的であるため、バイナリデータを確実に転送できます。ほとんどのシステムでは、端末 (tty) が使用されている場合でも、エスケープ文字を「none」に設定することにより、そのセッションを透過的にすることができます。
セッションは、リモートマシン上のコマンドやシェルが終了し、すべての X11 コネクションおよび TCP/IP コネクションが閉じられると終了します。リモートプログラムの終了ステータスは、ssh の終了ステータスとして返されます。
仮想端末が要求されている場合、ssh ではエスケープ文字を使った機能がいくつかサポートされています。
チルダ文字を 1 つだけ入力するには、~~ を押すか、後述する文字以外の文字をチルダのあとに続けます。エスケープ文字は、必ず改行の直後に入力されなければ特殊な文字とは見なされません。エスケープ文字は、構成ファイルの EscapeChar 構成指示またはコマンド行の –e オプションで変更できます。
サポートされているエスケープ機能 (エスケープ文字はデフォルトの ~ とする) は次のとおりです。
接続を切り離します。
ssh をバックグラウンドに移行させます。
転送されたコネクションの一覧を表示します。
ssh をバックグラウンドに移行させ、転送されたコネクションまたは X11 のセッションが終了するのを待ってログアウトします。
エスケープ文字の一覧を表示します。
リモートシステムに break 信号を送ります。SSH プロトコルバージョン 2 で、相手側もそれをサポートしている場合にのみ有効です。
コマンド行を開きます。–L オプションや –R オプションを使ってポート転送を追加する場合にのみ有効です。
そのコネクションの鍵の変更を要求します。SSH プロトコルバージョン 2 で、相手側もそれをサポートしている場合にのみ有効です。
ForwardX11 変数が「yes」に設定されており (後述の –X および –x オプションの説明を参照)、ユーザーが X11 を使用している (DISPLAY 環境変数が設定されている) 場合、X11 ディスプレイへのコネクションは自動的にリモート側に転送されます。つまり、シェル (またはコマンド) から起動された X11 プログラムはどれも暗号化されたチャネルを経由し、本物の X サーバーへのコネクションはローカルマシンから行われるようになります。ユーザーは DISPLAY を手動で設定しないでください。X11 コネクションの転送は、コマンド行または構成ファイルのどちらでも指定できます。
ssh によって設定された DISPLAY 値はサーバーマシンを指していますが、ディスプレイ番号はゼロよりも大きくなります。これは正常な動作です。ssh は暗号化されたチャネル経由でコネクションを転送します。そのため、サーバーマシン上に X11 サーバーの「プロキシ」を生成するのでこうなるのです。
また、ssh はサーバーマシン上で Xauthority データを自動的に設定します。このためにランダムな承認 cookie を生成して、サーバー側の Xauthority に格納し、転送されたコネクションがこの cookie を運び、コネクションが開かれるときにこれが本物の cookie と置き換わることを確認します。本物の認証 cookie がサーバーマシンに送られることはありません (また、cookie が平文で送られることもありません)。
ForwardAgent 変数が「yes」に設定されており (または、後述の –A および –a オプションの説明を参照)、ユーザーが認証エージェントを使用している場合、エージェントへのコネクションは自動的にリモート側に転送されます。
セキュリティー保護されたチャネルを経由した任意の TCP/IP コネクションの転送は、コマンド行または構成ファイルのどちらでも指定できます。TCP/IP 転送の応用の 1 つとして、電子財布へのセキュリティー保護された接続が考えられます。ほかにもファイアウォールをまたいだ接続などが考えられます。
ssh は、これまでに使用されたすべてのホストの識別情報が入っているデータベースを自動的に保守し、検査します。ホスト鍵はユーザーのホームディレクトリ内の $HOME/.ssh/known_hosts に格納されています。さらに、既知のホストについては /etc/ssh_known_hosts ファイルが自動的にチェックされます。不明なホスト鍵に関する ssh の動作は、StrictHostKeyChecking パラメータによって制御されます。あるホストの識別情報がこれまでと変わった場合、ssh はこれに関する警告を発し、パスワード認証を無効にすることで、トロイの木馬がユーザーのパスワードを盗むのを防ぎます。このメカニズムのもう一つの目的は、中間者による攻撃で暗号化が巧みにかわされてしまうのを防ぐことです。StrictHostKeyChecking オプションを使用すれば、ホスト鍵が不明だったり、変更されていたりするマシンへのログインを阻止することができます。
しかし、GSS-API で保護された鍵交換を使用している場合、サーバーはホスト鍵を通知できます。クライアントはこのホスト鍵を既知ホストファイル $HOME/.ssh/known_hosts に自動的に追加します。これは、通知されたホスト鍵が既存の既知ホストエントリと衝突しないかぎり、StrictHostKeyChecking オプションの設定に関係なく行われます。
ユーザーの GSS-API 資格の有効期限が切れると、クライアントはサーバーの公開ホスト鍵を使って引き続きセッションの鍵の変更を行うことができ、これにより鍵交換が保護されます。
ssh では、GssKeyEx または GssAuthentication (あるいはその両方) が設定されている場合、可能なかぎり、ユーザーの GSS-API 資格を使ってクライアントをサーバーに認証させます。
GssKeyEx が設定されている場合、GssKeyEx だけが使用されるように、ホストの公開鍵を持たない SSHv2 サーバーを 1 台持つことができます。そのようなサーバーでは、クライアントの資格の有効期限が切れた場合、鍵の変更は失敗します。
GSS-API ユーザー認証には SSH ホスト鍵の必要性を取り除かないというデメリットがありますが、その障害は鍵の変更に影響ありません。ssh では、GSS-API 認証に失敗した場合、ほかの認証方式 (公開鍵、パスワードなど) を試すことができます。
GSS-API 資格の委譲は極めて有効な場合がありますが、危険がないわけではありません。パスワードと同様に、ユーザーは GSS 資格を信頼できないサーバーに委譲しないでください。改ざんされたサーバーはユーザーの委譲された GSS 資格を使ってそのユーザーになりすます可能性あるからです。
GSS-API ユーザー承認については、gss_auth_rules(5) を参照してください。
GssKeyEx が「yes」のときは、鍵の変更を使って資格を再委譲できます。(前述の「エスケープ文字」の「~R」を参照してください。)
次を使用して ssh を構成します:
UseFIPS140 yes
...OpenSSL を FIPS-140 モードで実行します。SSH プロトコルバージョン 2 のみがサポートされます。SunSSH は、ユーザー/ホスト認証の暗号化操作を Solaris のほかの部分に引き続き委任する場合があり、その場合は FIPS 140 が認定されることもされないこともあります。UseOpenSSLEngine オプションのデフォルト値は no で、UseOpenSSLEngine を yes に設定しても FIPS モードには影響しません。ssh を FIPS-140 モードで実行するためのほかの要件として、クライアントは ssh-keygen –8 コマンドを使用してユーザーの非公開鍵を PKCS#8 形式で生成する必要があります。
FIPS-140 が有効な ssh の場合、FIPS-140 ではない sshd にログインするときに、このシナリオの「暗号化方式」を使用して、sshd_config(4) 内でサポートおよび承認されている FIPS 暗号化方式を明示的に指定する必要があります。
サポートしているオプションは、次のとおりです。
ssh がプロトコルバージョン 1 のみを試すように強制します。
ssh がプロトコルバージョン 2 のみを試すように強制します。
ssh が IPv4 アドレスのみを使用するように強制します。
ssh が IPv6 アドレスのみを使用するように強制します。
認証エージェント接続の転送を無効にします。
認証エージェント接続の転送を有効にします。これは構成ファイル内でホストごとに指定することもできます。
エージェントの転送を有効にするときは注意が必要です。リモートホスト上で (エージェントの UNIX ドメインソケットに対する) ファイルアクセス権を無視できるユーザーは、転送されたコネクションを介してローカルエージェントにアクセスできてしまいます。攻撃者は、エージェントから鍵そのものを盗むことはできません。しかし、鍵を操作して、攻撃者がエージェントに読み込まれたアイデンティティーを使って認証できるようにすることは可能です。
複数のインタフェースまたはエイリアス処理されたアドレスを持つマシン上で転送元となるインタフェースを指定します。
セッションを暗号化するための暗号化仕様を選択します。
プロトコルバージョン 1 では、cipher_spec は単一の暗号化です。詳細は、ssh_config(4) の「Cipher」オプションを参照してください。
プロトコルバージョン 2 では、cipher_spec は優先度順に暗号化をコンマで区切ったリストです。詳細は、ssh_config(4) の「Ciphers」オプションを参照してください。
すべてのデータ (標準入力、標準出力、標準エラー出力、転送された X11 コネクションや TCP/IP コネクションのデータを含む) を圧縮するよう要求します。圧縮アルゴリズムは、gzip(1) で使用されるものと同じです。gzip のマニュアルページは、SUNWsfman パッケージから入手できます。「レベル」は –CompressionLevel オプション (ssh_config(4) を参照) によって制御できます。圧縮は、モデム回線などの低速な接続には適していますが、高速のネットワークでは速度が低下するだけです。デフォルト値は、設定ファイル内でホストごとに指定できます。 ssh_config(4) の「–Compression」オプションを参照してください。
ローカル側でのアプリケーションレベルの「動的な」ポート転送を指定します。これは、(オプションで指定された bind_address にバインドされた) ローカル側のポートを待機するソケットを割り当てると機能します。このポートに接続されると、常に接続はセキュリティー保護されたチャネルを介して転送されます。アプリケーションプロトコルはこのとき、リモートマシンからどこに接続するかを決めるために使われます。現在、SOCKS4 および SOCKS5 プロトコルがサポートされており、SOCKS サーバーとして ssh が動作します。十分な特権を持っているユーザーのみが特権ポートにアクセスできます。動的ポート転送は、構成ファイル内で指定することもできます。
IPv6 アドレスは、代替の構文 [bind_address/]port を使用するか、アドレスを角括弧で囲むことによって指定できます。デフォルトでは、ローカルポートは「GatewayPorts」設定に従ってバインドされます。ただし、明示的に bind_address を使用すると、特定のアドレスに接続をバインドできます。localhost の bind_address は、待機ポートがローカルでのみ使用されるようにバインドされることを示します。一方、空のアドレスや * は、ポートがすべてのインタフェースからアクセス可能であることを示します。
仮想端末 (pty) を使用するセッションのためのエスケープ文字を設定します (デフォルトは「~」)。エスケープ文字は、行の先頭にあるときのみ認識されます。エスケープ文字の後ろにドット (.) を付けると、接続が閉じられます。エスケープ文字のあとに CTRL-z が続く場合、その接続は中断されます。エスケープ文字そのものが続く場合、その文字が 1 度だけ送られます。エスケープ文字を none に設定すると、すべてのエスケープが無効になり、セッションは完全に透過的になります。
ssh がコマンドを実行する直前に、バックグラウンドに移行するように要求します。これは、ssh からパスワードやパスフレーズの入力を求められるが、それをバックグラウンドで実行させたい場合に便利です。これは暗に –n オプションを指定したことになります。リモート側で X11 プログラムを起動させる場合は、ssh –f host xterm などとするのがよいでしょう。
ユーザーごとの構成ファイルに別のファイルを指定します。コマンド行に構成ファイルを指定すると、システム全体の構成ファイル /etc/ssh_config が無視されます。デフォルトでは、ユーザーごとの構成ファイルは $HOME/.ssh/config です。
リモートホストが転送済みのローカルポートに接続することを許可します。
RSA または DSA 認証用のアイデンティティー (秘密鍵) が読み取られるファイルを選択します。デフォルトは、プロトコルバージョン 1 の場合は $HOME/.ssh/identity、プロトコルバージョン 2 の場合は $HOME/.ssh/id_rsa と $HOME/.ssh/id_dsa です。アイデンティティーファイルは、構成ファイル内でホストごとに指定することもできます。複数の –i オプションを指定することも可能です (構成ファイルで複数のアイデンティティーを指定することもできます)。
識別ファイルの代わりに、PKCS#11 トークンに格納された証明書および秘密鍵で動作します。詳細は、sshd(1M) のマニュアルページの「Using X.509 Certificates」セクションを参照してください。
リモートマシン上でログインする際のユーザー名を指定します。これは構成ファイル内でホストごとに指定することもできます。
指定されたローカル (クライアント) ホスト上のポートが、指定されたリモート側のホストおよびポートに転送されることを指定します。これは、(オプションで指定された bind_address にバインドされた) ローカル側のポートを待機するソケットを割り当てると機能します。次に、このポートへのコネクションが確立されると常に、そのコネクションがセキュリティー保護されたチャネル経由で転送され、リモートマシンから host のポート hostport へのコネクションが確立されます。ポート転送は、構成ファイル内で指定することもできます。十分な特権を持っているユーザーのみが特権ポートにアクセスできます。IPv6 アドレスは、代替の構文 [bind_address/]port/host/hostport を使用するか、アドレスを角括弧で囲むことによって指定できます。
デフォルトでは、ローカルポートは「GatewayPorts」設定に従ってバインドされます。ただし、明示的に bind_address を使用すると、特定のアドレスに接続をバインドできます。localhost の bind_address は、待機ポートがローカルでのみ使用されるようにバインドされることを示します。一方、空のアドレスや * は、ポートがすべてのインタフェースからアクセス可能であることを示します。
プロトコルバージョン 2 では、複数の MAC (message authentication code、メッセージ認証コード) アルゴリズムを優先度の高い順にコンマで区切って指定できます。詳細は、MAC というキーワードで調べてください。
標準入力を /dev/null からリダイレクトします (実際には標準入力からの読み取りが行えないようにします)。ssh がバックグラウンドで動作する場合は、これを使用する必要があります。よくある手としては、リモートマシン上で X11 プログラムを実行するときにこのオプションを使用することです。たとえば、
ssh -n shadows.cs.hut.fi emacs &
これにより、emacs が shadows.cs.hut.fi 上で起動し、X11 コネクションが暗号化されたチャネル経由で自動的に転送されます。ssh プログラムはバックグラウンドに移行します。ssh がパスワードやパスフレーズの入力を求める必要がある場合、このオプションは機能しません。–f オプションも参照してください。
リモートコマンドを実行しません。このオプションは、ポート転送のみを行う場合に便利です (プロトコルバージョン 2 のみ)。
構成ファイルと同じ形式でオプションを指定するために使われます。これは、個別のコマンド行フラグがない場合にオプションを指定するのに便利です。このオプションの形式は、構成ファイル内の行と同じです。
リモートホストの接続先ポートを指定します。これは、構成ファイル内でホストごとに指定することができます。
廃止されたオプションです。特権ポートからの SSHv1 コネクションはサポートされていません。
静寂モード。すべての警告メッセージや診断メッセージは抑制されます。致命的なエラーだけが表示されます。
指定されたリモート (サーバー) ホスト上のポートが、指定されたリモート側のホストおよびポートに転送されることを指定します。このオプションを指定すると、まずリモート側でポートを待機するソケットが割り当てられます。次に、このポートへのコネクションが確立されると常に、そのコネクションがセキュリティー保護されたチャネル経由で転送され、ローカルマシンから host のポート hostport へのコネクションが確立されます。ポート転送は、構成ファイル内で指定することもできます。十分な特権を持っているユーザーとしてリモートマシンにログインした場合にのみ、特権ポートに転送できます。
IPv6 アドレスは、アドレスを角括弧で囲むか、代替の構文 [bind_address/]host/port/ hostport を使用して指定できます。
デフォルトでは、サーバーの待機ソケットはループバックインタフェースにのみバインドされます。この設定は、bind_address を指定すると上書きできます。空の bind_address またはアドレス * は、すべてのインタフェースでリモートソケットが待機することを示します。サーバーの「GatewayPorts」オプションが有効になっている場合にのみ、リモート bind_address の指定が成功します。sshd_config(4) を参照してください。
リモートシステムでサブシステムの呼び出しを要求するために使われます。サブシステムは SSH2 プロトコルの機能であり、SSH をほかのアプリケーション (sftp など) のためのセキュリティー保護された転送路として使用しやすくします。サブシステムはリモートコマンドとして指定されます。
強制的に仮想端末 (pseudo-tty) を割り当てます。これはリモートマシン上で任意の画面ベースのプログラムを実行するために使われ、メニューサービスを実装する場合などに非常に役立ちます。複数の –t オプションを指定すると、ssh がローカル tty を持っていない場合でも強制的に割り当てが行われます。
仮想端末 (pseudo-tty) の割り当てを無効にします (プロトコルバージョン 2 のみ)。
冗長モード。ssh がその進捗状況についてデバッグメッセージを表示するようにします。これは、接続、認証、および構成の問題をデバッグするときに役立ちます。–v オプションを複数個指定すると、出力の詳細レベルが高くなります。最高は 3 です。
X11 転送を無効にします。
X11 転送を有効にします。これは構成ファイル内でホストごとに指定することもできます。
X11 の転送を有効にするときは注意が必要です。リモートホスト上で (ユーザーの X 承認データベースに対する) ファイルアクセス権を無視できるユーザーは、転送されたコネクションを介してローカル側の X11 ディスプレイにアクセスできてしまいます。攻撃者はこのとき、キーストロークを盗み見るなどの行為を行える可能性があります。
このため、X11 転送は X11 SECURITY 拡張制限に従う場合があります。詳細は、ssh_config(4) の「ForwardX11Trusted」の指示を参照してください。
X11 転送が有効になっている場合、リモート X11 クライアントがデフォルトで信頼されます。つまり、元の X11 ディスプレイに完全にアクセスできます。
通常、ssh は次の環境変数を設定します。
DISPLAY 変数は、X11 ディスプレイの転送を機能させるために設定する必要があります。
ssh がパスフレーズを必要とする場合、ssh が端末から起動されていれば、現在の端末からパスフレーズを読み取ります。ssh に端末が関連付けられていないが、DISPLAY と SSH_ASKPASS が設定されている場合は、SSH_ASKPASS で指定されたプログラムを実行し、X11 ウィンドウを開いてパスフレーズを読み取ります。これは、.Xsession やそれに関連するスクリプトから ssh を呼び出す際に特に役立ちます。マシンによっては、これを機能させるために、入力を /dev/null からリダイレクトする必要がある場合があります。システムは、SSH_ASKPASS のデフォルト値である /usr/lib/ssh/ssh-askpass が設定された状態で出荷されます。
エージェントとの通信に使用される UNIX ドメインソケットのパスを示しています。
IETF 言語タグをコンマで区切ったリスト (RFC 3066 を参照)。ユーザーが読み書きできる言語を示しています。サーバー側でのロケールのネゴシエーションに使われます。
これらの環境変数の値は、クライアント側でのロケール設定やサーバー側でのそれらのロケールのサポート状況に従って、リモートセッションで設定することができます。環境変数をサーバー側に引き渡すときには、RFC 4254 の「Environment Variable Passing」を参照してください。
サーバー側の構成に応じてロケール設定をさらに変更する方法については、sshd(1M) のマニュアルページの「ENVIRONMENT VARIABLES」のセクションを参照してください。
リモートプログラムのステータスは、ssh の終了ステータスとして返されます。ssh 接続 (最初の鍵交換を含む) 中の任意の時点でエラーが発生した場合は、255 が返されます。
ユーザーがログインしたことのあるすべてのホスト (/etc/ssh/ssh_known_hosts に含まれているものを除く) のホスト鍵を記録します。sshd(1M) を参照してください。
ユーザーの認証アイデンティティーが含まれています。それぞれ、プロトコル 1 の RSA 認証用、プロトコル 2 の DSA 認証用、プロトコル 2 の RSA 認証用です。これらのファイルには機密情報が含まれているため、ユーザーには読めても、他人からはアクセス (読み取り/書き込み/実行) できないようにしてください。ssh は、他人がアクセスできるようになっている秘密鍵ファイルを無視します。鍵を生成するときにパスフレーズを指定することができます。パスフレーズは、このファイルの機密性の高い部分を 3DES で暗号化するために使われます。
このファイルに書かれているコマンドは、ユーザーがログインしてシェル (またはコマンド) の実行が開始する直前に ssh によって実行されます。詳細は、sshd(1M) を参照してください。
このファイルに書かれているコマンドは、ユーザーがログインしてシェル (またはコマンド) の実行が開始する直前に ssh によって実行されます。詳細は、sshd(1M) を参照してください。
環境変数の追加の定義が含まれています。「環境変数」を参照してください。
属性についての詳細は、マニュアルページの attributes(5) を参照してください。
|
コマンド行の構文は「確実」です。LC_* 環境変数の引き渡しによるリモート側でのロケールの選択は「不確実」です。
rlogin(1), rsh(1), scp(1), ssh-add(1), ssh-agent(1), ssh-keygen(1), ssh-http-proxy-connect(1), ssh-socks5-proxy-connect(1), telnet(1), sshd(1M), ssh_config(4), sshd_config(4), attributes(5), gss_auth_rules(5), kerberos(5), privileges(5)
krb5_auth_rules(5) で、.k5login ファイルの説明を参照してください。
RFC 1928
RFC 4254