| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
マニュアルページセクション 1M: システム管理コマンド Oracle Solaris 11.1 Information Library (日本語) |
| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
|
マニュアルページセクション 1M: システム管理コマンド Oracle Solaris 11.1 Information Library (日本語) |
- Secure Shell デーモン
sshd [-deiqtD46] [-b bits] [-f config_file]
[-g login_grace_time] [-h host_key_file]
[-h PKCS#11 URI]
[-p port] [-V client_protocol_id]sshd (Secure Shell デーモン) は、ssh(1) 用のデーモンプログラムです。これらのプログラムはともに、rlogin や rsh を置き換え、安全でないネットワーク上にある 2 台の信頼できないホスト間において、暗号化された安全な通信を提供します。これらのプログラムは、できるだけ簡単にインストールして使用できるよう意図されています。
sshd は、クライアントからの接続を待機するデーモンです。それは接続を受信するたびに新しいデーモンをフォークします。フォークされたデーモンは、鍵の交換、暗号化、認証、コマンドの実行、およびデータ交換を行います。
この sshd の実装では、SSH プロトコルバージョン 2 のみをサポートしています。
このプロトコルバージョンは、そのデーモンプログラムではサポートされなくなりました。それはクライアントでのみサポートされます。詳細は、ssh(1) のマニュアルページを参照してください。
各ホストには、そのホストの識別に使用されるホスト固有の DSA/RSA 鍵があります。フォワードセキュリティーは、Diffie-Hellman 鍵合意を通じて提供されます。この鍵合意によって共有セッション鍵が生成されます。セッションの残りは、対称暗号化 (現在は 128/192/256 ビットの AES CBC または CTR、128/256 ビットの ARCFOUR、Blowfish、または 3DES) を使用して暗号化されます。クライアントでは、サーバーが提供するそれらの中から使用する暗号化アルゴリズムを選択します。また、暗号メッセージ認証コード(hmac-sha1、hmac-sha2-256、 hmac-sha2-256-96、hmac-sha2-512、hmac-sha2-512-96、または hmac-md5) を通じてセッションの整合性が確保されます。
プロトコルバージョン 2 には、公開鍵ベースのユーザー認証方式 (PubKeyAuthentication)、GSS–API ベースのユーザー認証、従来のパスワード認証、およびパスワードベース認証用の汎用プロンプト/応答プロトコルが用意されています。
クライアントが自分自身の認証に成功した場合、セッションを準備するためのダイアログに入ります。この時点で、クライアントは擬似 tty の割り当て、X11 接続の転送、TCP/IP 接続の転送、セキュリティー保護されたチャネル経由での認証エージェント接続の転送のようなことを要求できます。
最後に、クライアントはシェル、またはコマンドの実行を要求します。その際、どちらの側もセッションモードに入ります。このモードでは、どちらの側もデータを常時送信でき、そのようなデータはサーバー側のシェルまたはコマンドに (またはそこから) 転送されたり、クライアント側のユーザー端末に (またはそこから) 転送されたりします。
ユーザーのプログラムが終了し、転送した X11 などの接続がすべて閉じられると、サーバーはコマンド終了ステータスをクライアントに送信し、どちらの側も終了します。
sshd は、コマンド行オプションまたは構成ファイル /etc/ssh/ssh_config を使用して構成できます。これについては、ssh_config(4) に説明されています。構成ファイル内に指定されている値は、コマンド行オプションによってオーバーライドされます。
sshd は、ハングアップシグナル SIGHUP を受け取ると、それが開始されたときの名前、つまり /usr/lib/ssh/sshd を使って自分自身を実行することにより、その構成ファイルを再度読み取ります。
sshd デーモンは、TCP ラッパーを使用してホストへのアクセスを制限します。hosts_access() には sshd のサービス名が使用されます。TCP ラッパーの詳細は、SUNWsfman パッケージの一部である (SunOS のマニュアルページではない) tcpd(1M) および hosts_access(3) のマニュアルページを参照してください。TCP ラッパーのバイナリ (libwrap を含む) は、sshd を含むパッケージ service/network/ssh の必須パッケージ security/tcp-wrapper 内にあります。
sshd のオプションは次のとおりです。
サーバー鍵のビット数を指定します (デフォルトは 768)。
デバッグモード。サーバーは冗長なデバッグ出力をシステムログに送信し、バックグラウンドには移行しません。またサーバーはフォークせず、1 つの接続しか処理しません。このオプションは、サーバーのデバッグのためにのみ用意されています。複数の -d オプションを指定すると、デバッグレベルが上がります。最高は 3 です。
このオプションを指定した場合、sshd は出力をシステムログではなく標準エラーに送ります。
構成ファイルの名前を指定します。デフォルトは /etc/ssh/sshd_config です。構成ファイルがないと、sshd は開始しません。
クライアントが自分自身を認証するまでの猶予時間を指定します (デフォルトは 300 秒)。クライアントがこの秒数内にユーザーを認証できなかった場合、サーバーは接続を解除して終了します。値ゼロは、制限がないことを示します。
ホスト鍵を読み取るファイルを指定します。sshd を root として実行しない場合は、このオプションを指定する必要があります (標準のホスト鍵ファイルは通常、root 以外のユーザーでは読み取り不可であるため)。デフォルトは、プロトコルバージョン 1 の場合は /etc/ssh/ssh_host_key、プロトコルバージョン 2 の場合は /etc/ssh/ssh_host_rsa_key および /etc/ssh/ssh_host_dsa_key です。異なるプロトコルバージョンやホスト鍵アルゴリズムに合わせて複数のホスト鍵ファイルを指定できます。
ホスト鍵ファイルを使用するのではなく、PKCS#11 トークンに格納されている証明書と秘密鍵を使って処理します。後述の「X.509 証明書の使用」セクションも参照してください。
sshd が inetd から実行されることを指定します。sshd は、クライアントに応答する前にサーバー鍵を生成する必要があり、これに数十秒かかる場合があるため、通常 inetd からは実行されません。その鍵が毎回再生成されると、クライアントの待機時間が長くなりすぎてしまいます。ただし、鍵のサイズが小さければ (たとえば、512)、inetd から sshd を使用することは理にかなっている場合があります。
構成ファイルで使用されている形式でオプションを指定する場合に使用できます。これは、個別のコマンド行フラグのないオプションを指定する場合に役立ちます。
サーバーが接続を待機するポートを指定します (デフォルトは 22)。
静寂モード。システムログには何も送られません。通常は、各接続の開始、認証、および終了がログに記録されます。
テストモード。構成ファイルの有効性や鍵の妥当性のみをチェックします。これは、構成オプションが変更される可能性があるときに sshd を安全に更新するために役立ちます。
このオプションを指定すると、sshd は切り離しを行わず、デーモンになりません。これにより、sshd の監視が容易に行えるようになります。
sshd が IPv4 アドレスのみを使用するように強制します。
sshd が IPv6 アドレスのみを使用するように強制します。
$HOME/.ssh/authorized_keys ファイルには、プロトコルバージョン 2 の公開鍵認証 (PubkeyAuthentication) を許可された公開鍵の一覧が記述されています。AuthorizedKeysFile 構成オプションを使用すると、代替ファイルを指定できます。
このファイルの各行には鍵が 1 つ入ります (空の行およびハッシュ記号 [#] で始まる行はコメントとして無視されます)。
プロトコルバージョン 1 の RSA 鍵の場合、ファイルは次のスペースで区切られたフィールドで構成されます。
options bits exponent modulus comment
プロトコルバージョン 2 の公開鍵の場合、ファイルは次のスペースで区切られたフィールドから構成されます。
options key-type base64-encoding-key comment
プロトコルバージョン 2 では、key-type は ssh-rsa または ssh-dsa のどちらかです。
options はオプションのフィールドであり、存在するかどうかは、その行が数字で始まるかどうかによって判断します。(options フィールドが数字で始まることはありません。)bits、exponent、および modulus フィールドには RSA 鍵を指定し、comment フィールドはその鍵を識別するのに便利な場所です。
このファイル内の行は通常、数百バイトの長さになります (鍵のモジュラスのサイズのため)。それらを入力するのは非常に不便であると思われます。代わりに公開鍵ファイルをコピーし、それを編集してください。
このファイルのアクセス権は、だれでも書き込み可能でもグループ書き込み可能でもないように設定する必要があります。sshd_config(4) の StrictModes オプションを参照してください。
options (存在する場合) はコンマで区切られたオプション指定で構成されます。スペースは許可されませんが、二重引用符の中には入れることができます。次のオプション指定がサポートされています。
公開鍵認証に加えて、リモートホストの正規名もコンマで区切られたパターンのリスト内に含まれている必要があることを指定します (「*」と「?」はワイルドカードとして機能する)。このリストには、パターンに接頭辞「!」を付けることで、否定パターンを含めることもできます。正規のホスト名が否定されたパターンと一致した場合、その鍵は受け入れられません。
このオプションの目的は、セキュリティーの向上を選択できるようにすることです。公開鍵認証だけでは、ネットワークやネームサーバーなど、鍵以外のものはどれも信頼できません。しかし、何者かが何らかの方法で鍵を盗んだ場合、その鍵を持っていることで侵入者は世界中のどこからでもログインできることになります。このオプションは盗まれた鍵の使用をより困難にします (鍵だけでなくネームサーバーやルーターのセキュリティーも脅かす必要があるため)。
この鍵が認証に使用される場合に必ず command が実行されることを指定します。ユーザー (存在する場合) が指定したコマンドは無視されます。クライアントが pty を要求した場合、このコマンドは pty 上で実行されます。それ以外の場合は、tty なしで実行されます。8 ビットのクリーンなチャネルが必要な場合は、pty を要求してはいけません。つまり、no-pty を指定するようにしてください。コマンド内に引用符を含める場合は、それをバックスラッシュでエスケープします。このオプションは、特定の公開鍵が特定の処理を実行しないように制限するのに役立つ場合があります。たとえば、リモートバックアップ以外は何も行えないような鍵です。クライアントでは、明示的に禁止されていないかぎり、TCP/IP 転送または X11 転送 (あるいはその両方) を指定できることに注意してください。また、このオプションがシェル、コマンド、またはサブシステムの実行に適用されることにも注意してください。
この鍵を使ってログインしたときに文字列 NAME=value が環境に追加されることを指定します。この方法で設定された環境変数によって、ほかのデフォルトの環境値がオーバーライドされます。このタイプのオプションは複数指定できます。環境処理はデフォルトで無効になっており、PermitUserEnvironment オプションによって制御されます。
この鍵が認証に使用される場合に TCP/IP 転送を禁止します。クライアントがポート転送を要求してもすべてエラーが返されます。これは、たとえば command オプションに関連して使用されることがあります。
この鍵が認証に使用される場合に X11 転送を禁止します。クライアントが X11 転送を要求してもすべてエラーが返されます。
この鍵が認証に使用される場合に認証エージェント転送を禁止します。
tty の割り当てができないようにします (pty の割り当て要求が失敗します)。
ローカルの ssh -L ポート転送を、指定されたホストおよびポートにしか接続できないように制限します。IPv6 アドレスは、代替構文 host/port を使って指定できます。各インスタンスをコンマで区切って、複数の permitopen オプションを呼び出すことができます。指定されたホスト名に対してパターンマッチングは行われません。それらはリテラルのドメインまたはアドレスである必要があります。
/etc/ssh/ssh_known_hosts および $HOME/.ssh/known_hosts ファイルには、すべての既知のホストのホスト公開鍵が含まれています。グローバルファイルは管理者によって用意され (省略可能)、ユーザーごとのファイルは自動的に維持されます。ユーザーが不明なホストから接続すると、必ずその鍵がユーザーごとのファイルに追加されます。
プロトコルバージョン 1 の RSA 鍵の場合、これらのファイルは次のスペースで区切られたフィールドから構成されます。
hostnames bits exponent modulus comment
プロトコルバージョン 2 の公開鍵の場合、これらのファイルは次のスペースで区切られたフィールドから構成されます。
hostnames key-type base64-encoding-key comment
プロトコルバージョン 2 では、key-type は ssh-rsa または ssh-dsa のどちらかです。
hostnames はコンマで区切られたパターンのリストです (* および ? はワイルドカードとして機能する)。各パターンは順に正規のホスト名と照合されるか (クライアントの認証時)、またはユーザー提供の名前と照合されます (サーバーの認証時)。また、パターンの前に ! を付けると、否定を表すことができます。ホスト名が否定されたパターンと一致した場合、それがその行の別のパターンと一致した場合でも (その行によって) 受け入れられません。
あるいは、ホスト名をハッシュされた形式で格納することもできます。これにより、万一ファイルの内容が開示された場合にホスト名とアドレスが非表示になります。ハッシュされたホスト名は垂直バー (|) 文字で始まります。ハッシュされたホスト名は 1 行に 1 つだけ表示でき、上記の否定またはワイルドカード演算子を適用することはできません。
bits、exponent、および modulus は RSA ホスト鍵から直接取り込まれます。たとえば、それらは /etc/ssh/ssh_host_rsa_key.pub から取得できます。省略可能な comment フィールドは行末まで続き、使用されません。
ハッシュ記号 (#) で始まる行と空白の行はコメントとして無視されます。
ホスト認証を行う際、一致するいずれかの行に適切な鍵が含まれていれば、認証が受け入れられます。したがって、同じ名前に対して複数の行や異なるホスト鍵が含まれていても許容されます (ただし、推奨されません)。さまざまなドメインからのホスト名の短縮形がそのファイルに格納された場合に、これが必然的に起こります。それらのファイルには競合する情報が含まれている可能性があります。どちらかのファイルから有効な情報が見つかれば、認証は受け入れられます。
これらのファイル内の行は通常、何百文字もの長さです。ホスト鍵を決して手動で入力すべきではありません。そうではなく、スクリプトによって、または /etc/ssh/ssh_host_rsa_key.pub を取得し、その先頭にホスト名を追加することによってそれらを生成してください。
sshd は、ssh ユーザーによって実行されたコマンドに対して、次の環境変数を設定します。
X11 サーバーの場所を示します。それは、書式 hostname:n の値を指し示すために sshd によって自動的に設定されます。hostname はシェルが実行されるホストを示し、n は 1 以上の整数です。ssh はこの特別な値を使用して X11 接続をセキュリティー保護されたチャネル経由で転送します。重要な理由が特にないかぎり、DISPLAY を明示的に設定しないようにしてください。それによって X11 接続が不安定な状態となり、必要な承認 cookie を手動でコピーする必要が生じます。
ユーザーのホームディレクトリのパスに設定されます。
ロケール設定。ロケールはデフォルトで sshd のそれ (通常はシステム全体のデフォルトロケール) になるか、または初期鍵交換中にクライアントとサーバー間でネゴシエーションが行われます (RFC 4253 に準拠)。
初期鍵交換のあとで、それらの各変数を次の手順でオーバーライドできます。
ロケール設定がクライアントの環境で行われ、そのクライアントが「Environment Variable Passing」 (RFC 4254 を参照) をサポートしている場合、その設定はサーバー側に引き渡されます。
サーバーの認証に公開鍵認証方法が使用され、サーバー側で sshd_config(4) の PermitUserEnvironment 変数が yes に設定された場合、その設定はクライアントの AuthorizedKeysFile ファイル内の environment オプションを使用して変更できます。
その設定は、サーバー上のクライアントの ~/.ssh/environment ファイル内で変更される可能性があります。
ユーザー環境を設定するために AuthorizedKeysFile および ~/.ssh/environment ファイルが処理され、使用されるタイミングについては、sshd_config(4) の PermitUserEnvironment を参照してください。
USER の同義語。この変数を使用するシステムとの互換性のために設定されます。
ユーザーのメールボックスを指し示すように設定されます。
そのエージェントとの通信に使用される unix-domain ソケットのパスを示します。
接続のクライアント側とサーバー側を識別します。この変数には、スペースで区切られた値が 4 つ含まれています。クライアント IP アドレス、クライアントポート番号、サーバー IP アドレス、およびサーバーポート番号です。
接続のクライアント側を識別します。この変数には、スペースで区切られた値が 3 つ含まれています。クライアント IP アドレス、クライアントポート番号、およびサーバーポート番号です。
現在のシェルまたはコマンドに関連付けられた tty (デバイスへのパス) の名前に設定されます。現在のセッションに tty がない場合、この変数は設定されません。
現在のタイムゾーンを示します (TIMEZONE が /etc/default/login 内に設定されている場合、またはデーモンが開始されたときに TZ が設定された場合)。
/etc/default/login 内に設定されている場合、デーモンはそれを同じ値に設定します。
ユーザーのシェル (/etc/default/login 内で ALTSHELL=YES の場合)。
/etc/default/login 内の PATH または SUPATH の値に設定されます (login(1) を参照)。設定されていない場合は、/usr/bin:/bin に設定されます。
ログインしているユーザーの名前に設定されます。
さらに、sshd は $HOME/.ssh/environment を読み取り、書式 VARNAME=value の行を環境に追加します。
次の例では、使用しているディスプレイの行の長さ制限のためにいくつかの行が折り返されることがあります。それでも、折り返された行を 1 行とみなすようにしてください。
例 1 authorized_key ファイルのエントリ
次は、プロトコル 1 の authorized_key ファイルエントリの例です。
1024 33 12121...312314325 ylo@foo.bar from="*.niksula.hut.fi,!pc.niksula.hut.fi" 1024 35 23...2334 ylo@niksula command="dump /home",no-pty,no-port-forwarding 1024 33 23...2323 backup.hut.fi
例 2 プロトコル 2 の authorized_key ファイルのエントリ
次は、プロトコル 2 の authorized_key ファイルエントリの例です。
ssh-rsa AAAAB3NzaC1y.....EU88ovYKg4GfclWGCFYTuw8= ylo@foo.bar from="*.niksula.hut.fi" ssh-rsa AAAAB3NzaC...uw8= ylo@niksula command="dump /home",no-pty,no-port-forwarding ssh-rsa AA..8= backup.hut.fi
例 3 プロトコル 1 の ssh_known_hosts ファイルのエントリ
次は、プロトコル 1 の ssh_known_hosts ファイルエントリの例です。
closenet,closenet.hut.fi,...,130.233.208.41 1024 37 159...93 closenet.hut.fi
例 4 プロトコル 2 の ssh_known_hosts ファイルのエントリ
次は、プロトコル 2 の ssh_known_hosts ファイルエントリの例です。
closenet,closenet.hut.fi,...,130.233.208.41 ssh-rsa AA..8= closenet.hut.fi
例 5 X.509 公開鍵認証の使用
次のユーザー認証の例は、X.509 公開鍵認証が機能する方法を理解するのに役立つはずです。ホスト認証に X.509 証明書/鍵を使用する手順は非常に似ています。通常の場合とは異なり、TA 証明書とユーザー証明書の両方に同じトークン (softtoken) が使用されることに注意してください
自己署名付きのトラストアンカー証明書と、トラストアンカー秘密鍵によって署名されたユーザー証明書を作成します。証明書の検証用の SSH デーモンを構成し、前の手順で生成されたユーザー証明書をユーザー識別情報として使って SSH クライアントを実行します。
サーバー側で、ユーザー名「PUT-YOUR-USERNAME-HERE」を既存 (自身) のユーザー名に置き換えます。
# Generate a trusted anchor certificate/key pair in the
# default token (softtoken).
pktool gencert keystore=pkcs11 label=authority \
subject="CN=authority" serial=0x01
# Export the trusted anchor certificate (and, after that,
# put it to /etc/ssh/cert directory).
pktool export keystore=pkcs11 outfile=ta.cert objtype=cert
label=authority outformat=pem
# Generate a user certificate signed by the trusted anchor
# private key and then import the certificate into the
# token.
pktool gencsr keystore=pkcs11 label=user \
outcsr=user.csr subject="CN=<PUT-YOUR-USERNAME-HERE>"
pktool signcsr keystore=pkcs11 signkey=authority \
csr=user.csr serial=0x02 issuer="CN=authority" \
outcert=user.cert
pktool import keystore=pkcs11 infile=user.cert label=user
# Create a new policy file.
kmfcfg create dbfile=/etc/ssh/policy.xml policy=ssh \
ta-name=search mapper-name=cn
# Start the SSH daemon in a debug mode to test the
# configuration. Use a different port so that you do not
# clash with the already running daemon.
/usr/lib/ssh/sshd -p 2222 -ddd -o \
-o TrustedAnchorKeystore=/etc/ssh/cert \
-o KMFPolicyDatabase=/etc/ssh/policy.xml \
-o KMFPolicyName=ssh
# Run the client in a debug mode to test the configuration
# (will ask for a PIN for the token, use the 'pinfile'
# attribute if you do not want to set PIN for each
# invocation).
# Note that the space and the hash-sign in the PKCS#11 URI are
# percent-encoded. Percent-encoding is in particular important when
# used from config file. Otherwise the '#' would be mistaken for a
# comment and token name matching would fail!
ssh -p 2222 -vvv -o \
IdentityFile=\
"pkcs11:object=user;token=Sun%20Software%20PKCS%2311%20softtoken" \
<PUT-YOUR-USERNAME-HERE>@localhostsofttoken を使用する前に、setpin サブコマンドを使用してその PIN を設定するようにしてください。詳細は、pktool(1) を参照してください。
次の終了ステータスが返されます。
正常終了。
エラーが発生した。
いくつかの sshd_config パラメータ、環境変数、およびその他の環境要素のデフォルトが含まれています。
次のパラメータは環境変数に影響を及ぼします (login(1) および前述のこれらの変数に関する説明を参照)。
TIMEZONE
HZ
ALTSHELL
PATH
SUPATH
次の /etc/default/login パラメータは、対応する sshd_config(4) パラメータのデフォルト値を提供します。
CONSOLE (sshd_config(4) の PermitRootLogin を参照)
PASSREQ (sshd_config(4) の PermitEmptyPasswords を参照)
TIMEOUT (sshd_config(4) の LoginGraceTime を参照)
次の /etc/default/login パラメータ:
UMASK
ULIMIT
はそれぞれ、sshd によって生成されたシェルおよびコマンドの umask(2) とファイルサイズの上限を設定します。
最後に、次の 2 つの /etc/default/login パラメータは、対話型ユーザー認証方法 (たとえば、publickey ではなく keyboard-interactive) を使用した接続ごとの許容される最大ログイン試行回数に影響を及ぼします (login(1) に準拠)。
RETRIES
SYSLOG_FAILED_LOGINS
sshd の構成データが入っています。このファイルは root によってのみ書き込み可能にするべきですが、だれでも読み取り可能にすることをお勧めします (必須ではありません)。
ホスト鍵の非公開部分が入っています。このファイルは root によってのみ所有され、root によってのみ読み取り可能で、ほかのユーザーはアクセス不可にするべきです。このファイルがグループアクセス可能またはだれでもアクセス可能な場合、sshd は開始されません。
ホスト鍵の公開部分が入っています。このファイルは、だれでも読み取り可能ですが、root によってのみ書き込み可能にするべきです。その内容は非公開部分と一致するようにします。このファイルは、暗号化には使用されず、ユーザーがその内容を既知ホストのファイルにコピーできるように利便性のためにのみ用意されています。これらのファイルは ssh-keygen(1) を使用して作成されます。
接続を待機している sshd のプロセス ID が入っています。異なるポートでいくつかのデーモンが同時に実行されている場合、これには最後に開始されたデーモンの pid が入ります。このファイルの内容には機密性がありません。だれでも読み取り可能にできます。sshd_config の PidFile キーワードを使用すると、/var/run/sshd.pid 以外のファイルを指定できます。sshd_config(4) を参照してください。
これらのファイルは、rhosts を公開鍵ホスト認証で使用してホストの公開鍵をチェックする場合に参照されます。この鍵が受け入れられるためには、これらのファイルの 1 つにそれが記述されている必要があります。クライアントでは、同じファイルを使用して、リモートホストが接続予定のものであるかを検証します。これらのファイルは root または所有者によってのみ書き込み可能にするべきです。/etc/ssh/ssh_known_hosts はだれでも読み取り可能にするべきで、$HOME/.ssh/known_hosts はだれでも読み取り可能にできますが、そうする必要はありません。
このファイルが存在する場合、sshd は root 以外の者がログインするのを許可しません。このファイルの内容はログインを試みるすべての人に表示され、root 以外の接続は拒否されます。このファイルはだれでも読み取り可能にするべきです。
ユーザーのアカウントへのログインに使用できる公開鍵 (RSA または DSA) の一覧が入っています。このファイルは root によって読み取り可能にします。一部のマシンでは、ユーザーのホームディレクトリが NFS ボリューム上にある場合にそれがだれでも読み取り可能であることを意味していることがあります。ほかのユーザーがそれにアクセスできないようにすることをお勧めします。このファイルの形式については前述しました。ssh-keygen(1) に説明しているように、ユーザーは自分の identity.pub、id_dsa.pub、または id_rsa.pub ファイル (あるいはそれらすべて) の内容をこのファイルに入れます。
このファイルには、スペースで区切られたホストとユーザー名のペアが 1 行につき 1 つずつ入っています。対応するホスト上の指定のユーザーは、パスワードなしでログインすることを許可されます。同じファイルが rlogind および rshd によって使用されます。このファイルはそのユーザーによってのみ書き込み可能にします。ほかのユーザーがそれにアクセスできないようにすることをお勧めします。また、このファイル内の netgroups を使用することもできます。ホストまたはユーザー名のどちらかの書式を +@groupname にして、グループ内のすべてのホストまたはすべてのユーザーを指定することもできます。
ssh の場合、このファイルは .rhosts の場合とまったく同じです。ただし、このファイルは rlogin や rshd では使われないため、これを使用すると、SSH を使ったアクセスしか許可されません。
このファイルは .rhosts 認証中に使用されます。そのもっとも簡単な書式では、このファイルにはホスト名が 1 行につき 1 つずつ入っています。これらのホスト上のユーザーは、両方のマシンに同じユーザー名を持っていれば、パスワードなしでログインすることを許可されます。ホスト名のあとにユーザー名を指定することもできます。そのようなユーザーはこのマシン上のユーザー (root 以外) としてログインすることが許可されます。また、構文 +@group を使用してネットグループを指定することもできます。否定されたエントリはハイフン (-) で始まります。
このファイル内でクライアントのホスト/ユーザーが正常に一致した場合、クライアントとサーバーのユーザー名が同じであれば、ログインが自動的に許可されます。また、RSA ホスト認証に成功することが通常は必須です。このファイルは root によってのみ書き込み可能にしてください。だれでも読み取り可能にすることをお勧めします。
警告: hosts.equiv でユーザー名を使用するのはあまり得策であるとは言えません。それは実際には指定したユーザーが任意のユーザーとしてログインできることを意味し、その中には重要なバイナリやディレクトリを所有する bin、daemon、adm などのアカウントが含まれていることに注意してください。事実上、ユーザー名を使用することはそのユーザーに root アクセス権を付与することです。おそらくユーザー名の有効な使い方は否定エントリ内のみです。この警告は rsh/rlogin にも当てはまります。
プライベートファイル。
このファイルは /etc/hosts.equiv とまったく同じように処理されます。ただし、このファイルは rsh/rlogin と ssh の両方を実行する環境で役立つ場合があります。
このファイルはログイン時に環境に読み込まれます (それが存在する場合)。その中には、空白の行、コメント行 (# で始まる)、および書式 name=value の割り当て行のみを入れることができます。このファイルはそのユーザーによってのみ書き込み可能にするべきです。ほかのだれでも読み取り可能にする必要はありません。環境処理はデフォルトで無効になっており、PermitUserEnvironment オプションによって制御されます。
このファイルが存在する場合は、環境ファイルの読み取り後、ユーザーのシェルまたはコマンドを開始する前に /bin/sh とともに実行されます。X11 スプーフィングが使用中の場合、これは proto cookie ペアを標準入力 (および環境内の DISPLAY) で受け取ります。その場合、これによって xauth が呼び出される必要があります。
$HOME/.ssh/rc のプライマリな目的は、ユーザーのホームディレクトリがアクセス可能になる前に必要となる可能性のある初期化ルーチンをすべて実行することです。AFS はそのような環境の特定の例です。このファイルが存在する場合は、環境ファイルの読み取り後、ユーザーのシェルまたはコマンドを開始する前に /bin/sh とともに実行されます。それによって標準出力に出力が生成されてはいけません。代わりに標準エラー出力を使用する必要があります。X11 転送が使用中の場合、それは proto cookie ペアをその標準入力、およびその環境内の DISPLAY で受け取ります。sshd は xauth を自動的に実行して X11 cookie を追加しないため、このスクリプトによって xauth が呼び出される必要があります。
このファイルにはおそらく、何らかの初期化コードに続いて次のようなものが入っています。
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 が実行され、それも存在しない場合は、cookie を格納するために xauth が使用されます。$HOME/.ssh/rc はそのユーザーによってのみ書き込み可能にするべきで、ほかのだれでも読み取り可能にする必要はありません。
$HOME/.ssh/rc と同様です。これを使用すると、マシン固有のログイン時の初期化をグローバルに指定できます。このファイルは root によってのみ書き込み可能にし、だれでも読み取り可能にするべきです。
sshd はいくつかのユーザー認証メカニズムの使用をサポートしています。鍵が (ユーザーの authorized_keys ファイルを通じて) ユーザーに関連付けられている公開鍵システム、鍵がホストに関連付けられている公開鍵システム (HostbasedAuthentication 構成パラメータを参照)、GSS-API ベースの方法 (GssAuthentication および GssKeyEx 構成パラメータを参照)、および 3 つの初期認証方法 (none、password、および汎用プロンプト/応答プロトコルの keyboard-interactive)。
「ホスト」サービス用の GSS-API アクセプタの資格がある場合にのみ、sshd は GSS-API の使用についてクライアントとネゴシエーションを行います。これは、GSS-API ベースの認証では、サーバーに Kerberos V keytab エントリ (下記参照)、またはインストールされる可能性のあるほかの GSS-API メカニズム用の同等のものが必要であることを意味します。
Kerberos 認証を機能させるためには、in.sshd サーバーに関連付けられた完全修飾ドメイン名 (Fully Qualified Domain Name) ごとに、host/<FQDN> Kerberos 主体が 1 つ存在する必要があります。これらの host/<FQDN> 主体にはそれぞれ、in.sshd サーバーの /etc/krb5/krb5.keytab ファイル内に keytab エントリが 1 つあります。主体の例は次のようになります。
host/bigmachine.eng.example.com
主体を krb5.keytab ファイルに追加する手順については、kadmin(1M) または gkadmin(1M) を参照してください。Kerberos 認証については、『Oracle Solaris 11.1 の管理: セキュリティーサービス』を参照してください。
GSS-API 認証は、gss_auth_rules(5) に説明されています。
sshd では、すべての認証方法のアカウント管理、セッション管理、およびパスワード管理に加えて、3 つの初期認証方法にも pam(3PAM) を使用します。
特に、sshd は「none」、「password」、および「keyboard-interactive」の SSHv2 userauth タイプに対して pam_authenticate() を呼び出します。ほかの SSHv2 認証方法では pam_authenticate() を呼び出しません。認証方法が成功するごとに pam_acct_mgmt() が呼び出されます。
認証に成功すると、pam_setcred() および pam_open_session() が呼び出され、接続が閉じられると、pam_close_session() が呼び出されます。
pam_open_session() と pam_close_session() は、pty を使用する SSHv2 チャネルが開かれたときと閉じられたときにも呼び出されます。
各 SSHv2 userauth タイプには、独自の PAM サービス名があります。
|
pam_acct_mgmt() が PAM_NEW_AUTHTOK_REQD (ユーザーの認証トークンが期限切れになったことを示す) を返した場合、プロトコルバージョン 2 が使用中であれば、sshd は「keyboard-interactive」 userauth を使用するよう強制します。pam_acct_mgmt() が再度 PAM_NEW_AUTHTOK_REQD を返した場合、「keyboard-interactive」 userauth は pam_chauthtok() を呼び出します。このようにして、管理者はユーザーごとに SSHv2 で許可される認証方法を制御できます。
ホストベースの認証を確立するには、次の手順を実行する必要があります。
クライアントを構成します。
サーバーを構成します。
既知のホストを公開します。
適切なエントリを /etc/ssh/shosts.equiv および ~/.shosts 内に作成します。
これらの手順については、次の段落で詳しく説明します。
クライアントマシンで、システム全体のクライアント構成ファイル /etc/ssh/ssh_config に次のエントリが含まれている必要があります。
HostbasedAuthentication yes
ssh_config(4) および ssh-keysign(1M) を参照してください。
サーバーで、システム全体のサーバー構成ファイル /etc/ssh/sshd_config に次のエントリが含まれている必要があります。
HostbasedAuthentication yes
ユーザーごとの .shost ファイルが許可される場合 (最後の手順を参照)、同じファイル内に次が必要です。
IgnoreRhosts no
これらのキーワードについては、sshd_config(4) を参照してください。
既知のホストを公開するには、ユーザーにホストベースの認証を許可するクライアントのエントリが必要です。これらのエントリを、システム全体のファイル (/etc/ssh/ssh_known_hosts) またはユーザーごとのファイル (~/.ssh/known_hosts) のどちらかまたは両方に作成します。
sshd が .rhosts ではなく .shosts を使用することに注意してください。.rhosts が提供する機能が必要であるが、セキュリティー上の欠陥のために rlogin または rsh を使用したくない場合は、.shosts を sshd とともに使用できます。この機能を使用するには、適切なエントリを rhosts(4) に指定されている形式で /etc/ssh/shosts.equiv および ~/.shosts 内に作成します。
大部分のネットワーク環境では、.shosts は .rhosts よりも優先されます。
SSH コマンドは、X.509v3 証明書がホスト鍵またはユーザー識別情報 (あるいはその両方) として使用される場合にそれを扱うことができます。この方法で使用すると、鍵と証明書の検出にプレーンなファイル名ではなく PKCS#11 URI を使うことができます。X.509 公開鍵認証に使用されるホスト鍵、ユーザー識別情報、およびそれらに対応する証明書は、PKCS#11 トークンにのみ格納できます。SSH で使用される PKCS#11 URI 属性は、object、token、および pinfile のみです。使用可能なハードウェアキーストアがない場合は、PKCS#11 softtoken キーストアを使用できます。
証明書の検証 (ユーザーを認証するサーバー、サーバーを認証するクライアント) のために、KMF ポリシーには証明書マッパーが必要です。マッパーはデフォルトのポリシーファイル内には設定されていません。詳細は、sshd_config(4) の TrustedAnchorKeystore、KMFPolicyDatabase、および KMFPolicyName オプションと、libkmf(3LIB) を参照してください。
自己署名付き証明書は、ホスト鍵としてのみ使用でき、ユーザー識別情報としては使用できません。自己署名付き証明書が使用される場合、または適切なトラストアンカー証明書が見つからないためにクライアント側でホスト証明書を検証できない場合、SSH クライアントは現在プレーンな公開鍵で行われているように、known_host データベースに鍵を自動的に格納します。公開鍵のみが証明書から抽出されてデータベースに格納され、そのようにして現在の形式が維持されます。クライアント側でこのような証明書を受け入れる理由は、初期ホスト鍵交換が再起動可能でないからです。このため、サーバーがその唯一のホスト鍵として証明書を使用した場合、その証明書を検証できないクライアントはそうしなければログインが認められません。
X.509 認証の使用方法については、「使用例」のセクションを参照してください。
FIPS-140 モードで OpenSSL を実行するよう sshd を構成するには、変数 UseFIPS140 を yes に設定します。
SunSSH は、ユーザー/ホスト認証のための暗号化操作を Solaris の他の部分 (FIPS-140 認定の場合とそうではない場合があります) に引き続き委任できます。UseOpenSSLEngine オプションのデフォルト値は no です。UseOpenSSLEngine を yes に設定しても、FIPS モードでは影響を受けません。
属性についての詳細は、マニュアルページの attributes(5) を参照してください。
|
/etc/ssh/moduli のインタフェースの安定性は「非公開」です。
kmfcfg(1), login(1), pktool(1), scp(1), ssh(1), ssh-add(1), ssh-agent(1), ssh-keygen(1), svcs(1), gkadmin(1M), kadmin(1M), sftp-server(1M), ssh-keysign(1M), svcadm(1M), libkmf(3LIB), pam(3PAM), rhosts(4), ssh_config(4), sshd_config(4), attributes(5), gss_auth_rules(5), kerberos(5), pam_roles(5), pkcs11_softtoken(5), smf(5)
krb5_auth_rules(5)で .k5login ファイルの説明を参照してください。
『Oracle Solaris 11.1 の管理: セキュリティーサービス』
sshd サービスは、サービス管理機能 smf(5) により、次のサービス識別子の下で管理されます。
svc:/network/ssh:default
有効化、無効化、または再起動要求など、このサービスに関する管理操作は、svcadm(1M) を使用して実行できます。サービスステータスを照会するには、svcs(1) コマンドを使用します。
sshd は常に PAM_RHOST を設定し、ホストベースの userauth の場合は PAM_AUSER を設定します。この動作により、ホストベースの認証を使用した役割へのリモートログインが可能になります。pam_roles(5) を参照してください。
|