OpenSSH-5.1p1 日本語マニュアルページ (2008/10/03)
OpenSSH SSH デーモン
sshd
[-46DdeiqTt ]
[-b ビット数 ]
[-C 接続指定 ]
[-f 設定ファイル ]
[-g ログイン制限時間 ]
[-h ホスト鍵ファイル ]
[-k 鍵の生成間隔 ]
[-o オプション ]
[-p ポート ]
[-u 長さ ]
sshd
(OpenSSH デーモン) はssh (1)
のためのデーモンプログラムです。これらのプログラムはともにrlogin
とrsh
を置き換えるもので、安全でないネットワーク上にある、2つの信頼されていないホスト間で、暗号化された安全な通信を提供します。
sshd
はクライアントからの接続を listen します。通常、これはブート時に/etc/rcから起動され、接続を受けつけるたびに新しいデーモンが fork します。fork したデーモンは、鍵の交換、暗号化、認証、コマンド実行、そしてデータ交換をおこないます。
sshd
はコマンドライン オプションか、設定ファイル(デフォルトではsshd_config (5))
によって設定することができます。コマンドラインからのオプションは、設定ファイルで指定されている値よりも優先されます。sshd
はハングアップシグナルSIGHUPを受け取ると、自分の設定ファイルを読み込みなおします。これは自分自身を開始したときのパス名、たとえば/usr/sbin/sshdとオプションを exec することによっておこないます。
コマンドラインオプションには次のようなものがあります:
-4 sshd
が IPv4 アドレスのみを使うよう強制します。-6 sshd
が IPv6 アドレスのみを使うよう強制します。-b ビット数 -C 接続指定 -T で使われる接続時のパラメータを指定します。このオプションが与えられた場合、そこで指定されているユーザ、ホスト名、およびアドレスに一致するような、設定ファイル中のMatch指定すべてが標準出力に表示されます。接続指定は「キーワード=値」の形式で指定し、使えるキーワードは"user"、"host"および"addr"です。これらは順序は関係ありませんが、すべてを指定する必要があります。これらの指定をカンマで区切るか、あるいは複数の-C オプションを使ってもかまいません。-D sshd
は切り離し (detach) をおこなわず、デーモンにはなりません。これはsshd
の監視を簡単にします。-d -d オプションをつけるとデバッグレベルが上がります。最高は 3 です。-e sshd
は出力を syslog のかわりに標準エラー出力に送ります。-f 設定ファイル /etc/ssh/sshd_configになっています。sshd
は設定ファイルがないと起動しません。-g ログイン制限時間 -h ホスト鍵ファイル sshd
を root 以外で起動するときは必ず指定しなければいけません(ホスト鍵のファイルはふつう root からしか読めないようになっているからです)。デフォルトでは、プロトコル バージョン 1 用の鍵が/etc/ssh/ssh_host_keyであり、プロトコル バージョン 2 用の鍵が/etc/ssh/ssh_host_rsa_keyおよび/etc/ssh/ssh_host_dsa_keyです。異なるバージョンのプロトコルやホスト鍵の方式に対し、複数のホスト鍵ファイルを指定することも可能です。-i sshd
がinetd (8)
から起動されることを指定します。ふつうsshd
が inetd から起動されることはありません。なぜなら sshd はクライアントを受けつける前にサーバ鍵を生成しておく必要があり、これには数十秒かかるためです。鍵が毎回生成しなおされると、クライアントは非常に長い間待たされてしまいます。しかし鍵のサイズが小さければ (たとえば 512 ビットぐらい)、inetd からsshd
を使うことも可能でしょう。-k 鍵の生成間隔 -o オプション -p ポート Portで指定されたポートは無視されます。ListenAddressで指定したポートはコマンドラインで指定されたポートよりも優先されます。-q sshd
は接続の開始と認証および終了を syslog に残します。このオプションを指定すると syslog には何も残りません。-T -C を指定すると、そこで指定されているひとつあるいは複数の接続パラメータにMatch指定が適用されます。-t sshd
を安全に更新するのに便利です。-u 長さ utmp構造体のフィールド長を指定するのに使われます。名前解決されたホストがこのlen よりも長い場合、ドットで区切られた 10 進の数値がかわりに保持されます。これは非常に長いホスト名をもつホストがこのフィールドをあふれさせても、一意に識別できるようにするためです。-u0 を指定するとutmpファイルにはつねにドットで区切られた 10 進値が使われるようになります。また-u0 はsshd
が DNS 要求をおこなわないようにするのにも使うことができます。ただし設定ファイルや認証メカニズムでこれが必要とされた場合はこの限りではありません。DNS を要求する可能性のある認証メカニズムはRhostsRSAAuthentication 、HostbasedAuthenticationおよびfrom=pattern-listオプションを使った鍵ファイルです。DNS を必要とする設定オプションには、AllowUsersあるいはDenyUsers .で使われている「USER@HOST」のパターンも含まれますので注意してください。Protocolオプションで変更できます。プロトコルバージョン 2 は RSA および DSA鍵をどちらもサポートしています。プロトコルバージョン 1 がサポートするのはRSA 鍵だけです。どちらのプロトコルでも、各ホストは識別のためのホストごとの鍵を持っており、これは通常 2048ビットからなります。
プロトコルバージョン 1 では、追加のサーバ鍵によってforward security(訳注: 将来、鍵が破られても現在の通信の秘匿性が保たれる特性) を提供しています。サーバ鍵は使われると通常 1 時間おきに再生成され、これは決してディスクに保存されません。クライアントが接続してくると、デーモンはそのホスト公開鍵とサーバ鍵を使って応答します。クライアントはその RSA ホスト鍵を自分のデータベース中にあるものと比較し、それが変更されていないことを確かめます。その後クライアントは 256 ビットの乱数を生成し、ホスト鍵とサーバ鍵を使って暗号化したあと暗号化された数値をサーバに送ります。以降、クライアントとサーバの両者はこの乱数をセッション鍵として使い、通信を暗号化します。これ以降の通信は一般的な Blowfish あるいは 3DES (デフォルト)暗号方式を使って暗号化されます。暗号方式は、クライアントがサーバから提供されたものの中から選択します。
プロトコルバージョン 2 では、forward security はDiffie-Hellman 鍵交換によって提供されます。この鍵交換プロセスにより、サーバとクライアント間で共通のセッション鍵が得られます。これ以降の通信は現在のところ128-bit AES, Blowfish, 3DES, CAST128, Arcfour, 192-bit AESあるいは 256-bit AES などの共通鍵暗号方式によって暗号化されます。暗号方式は、クライアントがサーバから提供されたものの中から選択します。さらに、通信の正真性 (integrity、訳注: 内容が改ざんされていないこと) がメッセージ認証コード (MAC) によって提供されます。これにはhmac-md5, hmac-sha1, umac-64 あるいは hmac-ripemd160 が使われます。
最後にサーバとクライアントは認証をおこないます。ここではクライアントは自分自身を認証するために、ホストベースド認証 (host-based authentication)、公開鍵認証 (public key authentication)、チャレンジ・レスポンス認証 (challenge-response authentication)、またはパスワード認証 (password authentication) を使用します。
認証の形式に関わらず、アカウントがアクセス可能かどうかをチェックします。アカウントがロックされているか、DenyUsersに記載されているか、またはそのグループがDenyGroupsに記載されている場合、アカウントはアクセスできません。ロックされたアカウントの定義はシステムに依存します。いくつかのプラットフォーム (例えば AIX) では独自のアカウントデータベースを持ち、またいくつかは passwd フィールドを変更します(Solaris および UnixWare では *LK* , HP-UX では * , Tru64 では Nologin を含みます。また FreeBSD では *LOCKED* , Linux では !! が先行します)。あるアカウントに公開鍵認証を許可しておきながら、パスワード認証を無効にする必要がある場合、パスワードフィールドはこれら以外の値(例えば NP または *NP* ) に設定する必要があります。
クライアントが認証に成功すると、セッションを準備するための対話がおこなわれます。この時点で、クライアントは仮想端末の使用を要求したり、X11 接続の転送、TCP 接続の転送、あるいは認証エージェントの転送などを安全な通信路を介して要求することができます。
この後、クライアントはシェルを要求するか、コマンドを実行します。両者はこの後セッションモードに入ります。セッションモードでは、どちらの側もいつでもデータを送ることができ、これらのデータはサーバ側のシェルやコマンドとクライアント側のユーザの端末の間でやりとりされます。
ユーザのプログラムが終了し、すべての転送された X11 接続やその他の接続が閉じられると、サーバはコマンドの終了状態をクライアント側に送り、両者は終了します。
sshd
は以下のことをおこないます:ユーザが端末にログインしており、コマンドがとくに指定されていない場合、(設定ファイルまたは ~/.hushlogin--FILESの項を参照 -- で禁止されていなければ) 前回のログイン時刻と/etc/motdを表示する。ユーザが端末にログインしている場合、ログイン時刻を記録する。 /etc/nologinをチェックする。これが存在する場合、 (root でなければ)その内容を表示して終了する。そのユーザの通常の権限に移行する。 基本的な環境変数を設定する。 ~/.ssh/environmentが存在していて、ユーザの環境変数を変更することが許されていれば、それを読み込む。sshd_config (5) のPermitUserEnvironment設定項目を参照のこと。ユーザのホームディレクトリに移動する。 ~/.ssh/rcが存在する場合、それを実行する。そうでなければ、もし/etc/ssh/sshrcが存在しているなら、それを実行する。これ以外の場合は xauth を実行する。この"rc"ファイルには、X11 の認証プロトコルとそのクッキーが標準入力から与えられる。(下記のSSHRCを参照してください。)ユーザのシェルまたはコマンドを実行する。
~/.ssh/rcファイルが存在する場合は、環境変数ファイルを読み込んだあと、ユーザのシェルやコマンドが開始する前にこのファイルがsh (1)
を介して実行されます。このスクリプトは標準出力 (stdout) に何も表示してはいけません。かわりに標準エラー出力 (stderr) を使ってください。X11転送を使っている場合、このスクリプトは標準入力から「仮のクッキー」 (およびDISPLAY 環境変数) を受けとることになります。この場合、このスクリプトはxauth (1)
を呼び出す必要があります。なぜならこのときsshd
は X11 クッキーを追加するために xauth を自動では呼ばないからです。
このファイルのおもな目的は、ユーザのホームディレクトリがアクセス可能になる前に必要な初期化作業を実行することです。そういった環境の例としてはAFS があります。
このファイルはおそらく以下のような初期化コードと似たものを含むことになるでしょう:
if read proto cookie && [ -n "$DISPLAY" ]; then if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then # X11UseLocalhost=yes echo add unix:`echo $DISPLAY | cut -c11-` $proto $cookie else # X11UseLocalhost=no echo add $DISPLAY $proto $cookie fi | xauth -q -fi
このファイルが存在しない場合、/etc/ssh/sshrcが実行されます。このファイルも存在しない場合は、クッキーを追加するために xauth が実行されます。
AuthorizedKeysFile項目は公開鍵認証のための公開鍵を格納するファイルを指定します。指定がない場合、このファイルはデフォルトで~/.ssh/authorized_keysになります。このファイルには各行にひとつの鍵が格納されています (空行や # で始まる行はコメントとして無視されます)。プロトコル バージョン 1 の公開鍵では、空白で区切られた以下の項目が格納されています:オプション、ビット数、指数、係数 (modulus)、鍵のコメント。プロトコル バージョン 2 の公開鍵では、以下の項目が格納されています:オプション、鍵の種類、base64 エンコードされた鍵本体、鍵のコメント。オプション項目はなくてもかまいません。オプションが存在するかどうかは、この行が数字で始まるかどうかによって決定されます(オプション項目は決して数字では始まりません)。プロトコル バージョン 1 では、RSA 鍵はビット数、指数および係数 (modulus) によって表されます。コメント欄は利用されません (が、鍵を区別するのに役立ちます)。プロトコル バージョン 2 では、鍵の種類は"ssh-dss"あるいは"ssh-rsa"です。
これらのファイルでは通常、 1 行が何百バイトもの長さになっていることに注意してください(これは公開鍵の係数のサイズが大きいためです)。DSA 鍵の長さの制限は最大 8 キロバイトで、RSA 鍵の最大は 16 キロバイトです。これを手でタイプする気にはならないでしょう。かわりにidentity.pub ,id_dsa.pubあるいはid_rsa.pubをコピーして、それを編集してください。
sshd
では、プロトコル 1 とプロトコル 2 の両方で、RSA 鍵の長さが少なくとも 768 ビット以上である必要があります。
オプションは (もしあれば) カンマによって区切ることができます。間にスペースを入れてはいけませんが、ダブルクォートの間にはさめばオッケーです。以下のオプションがサポートされています(これらのキーワードは大文字小文字を区別しません) :
command=commandno-ptyオプションを使ってください。コマンド文字列中にダブルクォートを入れたいときは、前にバックスラッシュをつけてください。このオプションは、ある公開鍵には特定の操作だけしかさせないようにするのに有効です。例として、リモートバックアップだけをさせて、それ以外な何もさせないような鍵がつくれます。クライアントの TCP や X11 転送は、明示的に禁止されていない限り可能なので注意してください。クライアントによって元々実行されたコマンドラインは環境変数SSH_ORIGINAL_COMMAND に格納されています。注意: このオプションはシェル、コマンドまたはサブシステムの実行に適用されます。environment=NAME=valuePermitUserEnvironmentを設定する必要があります。UseLoginを使っているときは、このオプションは自動的に禁止されます。from=pattern-list
ホスト名やIPアドレスにはワイルドカード指定が使用できますが、from節には CIDR表記 (アドレス/マスク長 の形式) で IPアドレス群を指定することもできます。
このオプション目的は、セキュリティのさらなる向上です:公開鍵認証それ自体は、(鍵を除いて) ネットワークやネームサーバ、その他ありとあらゆるものを信用しません。しかし、もし何者かが何らかの方法で鍵を盗むことができれば、その鍵を使って世界のどこからでもログインできてしまうことになります。このオプションは、そのような盗まれた鍵を使うことをより困難にします (もしこれを使おうとするなら、鍵のほかにネームサーバやルータなどにまで侵入しなくてはならないからです)。
no-agent-forwardingno-port-forwardingcommandオプションの指定されている接続などで使われます。no-ptyno-user-rc~/.ssh/rcの実行を禁止します。no-X11-forwardingpermitopen=host:port``ssh -L''のポート転送先を、指定されたホストの指定されたポートのみに限定します。IPv6 アドレスの場合は、指定する形式が異なります:host /port permitopenオプションはカンマで区切って複数個指定することもできます。パターンマッチングはおこなわれません。ホスト名にはドメイン名かアドレスをそのまま書く必要があります。tunnel=nauthorized_keys ファイルの例:
# コメントをつけるときは行頭からssh-rsa AAAAB3Nza...LiPk== user@example.netfrom="*.sales.example.net,!pc.sales.example.net" ssh-rsaAAAAB2...19Q== john@example.netcommand="dump /home",no-pty,no-port-forwarding ssh-dssAAAAC3...51R== example.netpermitopen="192.0.2.1:80",permitopen="192.0.2.2:25" ssh-dssAAAAB5...21S==tunnel="0",command="sh /etc/netstart tun0" ssh-rsa AAAA...==jane@example.net
/etc/ssh/ssh_known_hostsおよび~/.ssh/known_hostsの各ファイルは今までに知られているホストの公開鍵をすべて格納しています。システム全体で使われる known_hosts ファイル(大域的 known_hosts ファイル) は管理者によって用意され (必須ではありません)、ユーザ用の known_hosts ファイルは自動的に更新されます。ユーザがまだ知られていないホストに接続すると、そのホスト鍵が自動的にユーザ用 known_hosts ファイルに追加されるようになっています。
これらの known_hosts ファイルの各行は次のような項目からなっています:ホスト名、ビット数、指数、係数 (modulus)、そしてコメント。各項目はスペースによって区切られています。
ホスト名はカンマで区切られたパターン列です( * および ? はワイルドカードとして使われます)。各パターンは、クライアントを認証している場合は順にそのホストの正式名と比較され、サーバを認証している場合はユーザが与えた名前と比較されます。パターンの先頭に ! をつけると「〜でない」という否定 (negation) の意味になります。否定されたパターンにマッチしたホストは、たとえその行の他のパターンにマッチしても (その行では)受けつけられません。ホスト名またはアドレスには、ブラケット [ および ] で囲んだあと、 : の後に標準的でないポート番号を加えることもできます。
もうひとつの形式として、各ホスト名はハッシュされた形式で格納されていることもあります。これは、万が一そのファイルが見られた時でも、そのホスト名や IP アドレスが識別できないようにするためです。ハッシュされたホスト名は | 文字から始まります。各行はハッシュされたホスト名をひとつだけ持ち、これらに上記の否定表現やワイルドカード演算子を適用することはできません。
ビット数、指数および係数は RSA ホスト鍵から直接取り込まれます。たとえばこれらは/etc/ssh/ssh_host_key.pubなどから取得されます。オプションのコメントは行末まで続き、これは無視されます。
# で始まる行および空行はコメントとして無視されます。
ホスト間認証をおこなう際、どれか適切な鍵をもった行がマッチすれば、認証は受け入れられます。したがって同じ名前が複数の行にあったり、同一ホストに異なるホスト鍵が書いてあったりしても受けつけられます (が、おすすめはしません)。異なったドメインにあるホスト名の短縮形がひとつのファイルにまとめられているときは、これは仕方がないでしょう。また、これらのファイルには互いに矛盾する情報が書かれていることもあり得ます。その場合は、どれかのファイルに正しい情報が書いてあれば認証は受け入れられます。
注意。これらのファイルの各行は、ふつう何百文字もの長さになっています。もちろんこんなホスト鍵を手で入力したくはないでしょう。かわりにスクリプトで生成するか、/etc/ssh/ssh_host_key.pubをとってきてその先頭にホスト名をつけ加えるかしてください。
ssh_known_hosts の例:
# コメントをつけるときは行頭からclosenet,...,192.0.2.53 1024 37 159...93 closenet.example.netcvs.example.net,192.0.2.10 ssh-rsa AAAA1234.....=# ハッシュされたホスト名|1|JfKTdBh7rNbXkVAQCRp4OQoPfmI=|USECr3SWf1JUPsms5AqfD5QfxkM= ssh-rsaAAAA1234.....=
PrintLastLogおよびPrintMotdがそれぞれ許可されている場合でも最終ログイン時刻と/etc/motdファイルの表示はされなくなります。しかしBannerによって指定されているバナーはかならず表示します。
sshd
はこのファイルを root として読むため、ユーザのホームディレクトリが NFS 上にある場合、マシンによっては、このファイルは誰にでも読めるようにしておく必要があるかもしれません。
.rhostsとまったく同じように扱われます。しかしこれは rlogin/rsh から使われることなくホストベースド認証を許可することができます。
~/.ssh/authorized_keys
このファイル本体、あるいは~/.sshディレクトリ、あるいはそのユーザのホームディレクトリに対して他のユーザが書き込み可能になっている場合、権限のないユーザでもこのファイルを変更あるいは置き換えることができていまいます。このような場合、sshd
はStrictModesが"no"に設定されていない限り、このファイルの内容を使用しません。このファイルを推奨されるパーミッションにするには、以下のように実行します:"chmod go-w ~/ ~/.ssh ~/.ssh/authorized_keys"
PermitUserEnvironment項目を設定する必要があります。
sshd
は root を除くすべてのユーザのログインを拒否します。このファイルの内容は root 以外でログインしようとして拒否された人に対して表示されます。このファイルは誰にでも読めるようになっている必要があります。
hosts.equivとまったく同じように扱われます。しかしこれは rlogin/rsh から使われることなくホストベースド認証を許可することができます。
sshd
はこのファイルが誰にでも読めるようになっていると起動しないので注意してください。
sshd
の設定ファイルです。このファイルの形式と設定項目はsshd_config (5)
で説明されています。
~/.ssh/rcに似ています。これはそのマシン全体にわたってログイン時の初期化を指定するのに使われます。これはroot のみ書き込み可能にしておき、誰からも読めるようにしておくべきです。
/var/emptysshd
が特権分離の際に、認証前の段階で使用するchroot (2)
用のディレクトリです。このディレクトリはどんなファイルも含んでいてはならず、所有者は root で、他の人あるいはグループが書きこめるようになっていてはいけません。
/var/run/sshd.pidsshd
のプロセス ID が入っています (複数のsshd
が異なるポートで走っているときは、最後に開始したプロセスの ID が入ります)。このファイルの内容は機密事項ではなく、誰でも読めるようにしてかまいません。rshd
、rlogind
、およびrexecd
を禁止しないかぎり(つまりこれはrlogin
およびrsh
でそのマシンにログインすることを完全に禁止することになります)、システムのセキュリティは改善されませんので注意してください。