Secure Shell の SunSSH 実装は、OpenSSH (http://www.openssh.com) プロジェクトのフォークです。
OpenSSH の最近のバージョンに見つかった脆弱性に対するセキュリティー関連の修正が、個別のバグ修正および機能として Secure Shell (SunSSH) の sunssh 実装に組み込まれています。
次の機能が、現在のリリースの SunSSH で実装されました。
ForceCommand キーワード – ユーザーがコマンド行に入力した内容に関係なく、指定されたコマンドを強制的に実行します。このキーワードは、Match ブロックの内側で非常に役立ちます。この sshd_config 構成キーワードは、$HOME/.ssh/authorized_keys 内の command="..." キーワードに似ています。
AES-128 パスフレーズ保護 – ssh-keygen コマンドで生成される非公開鍵は AES-128 アルゴリズムで保護されます。このアルゴリズムでは、新しく生成された鍵や再暗号化された鍵 (パスフレーズが変更された場合など) を保護します。
sftp-server コマンドの –u オプション – ユーザーがファイルやディレクトリに対して明示的な umask を設定できるようにします。このオプションは、ユーザーのデフォルトの umask をオーバーライドします。例については、sshd_config(4) のマニュアルページの「Subsystem」の説明を参照してください。
Match ブロック用のその他のキーワード – Match ブロックの内側では AuthorizedKeysFile、ForceCommand、および HostbasedUsesNameFromPacketOnly がサポートされています。デフォルトでは、AuthorizedKeysFile の値は $HOME/.ssh/authorized_keys で、HostbasedUsesNameFromPacketOnly の値は no です。Match ブロックを使用するには、Secure Shell デフォルトのユーザーおよびホスト例外を作成する方法を参照してください。
Oracle Solaris エンジニアは次の Oracle Solaris 機能を SunSSH に組み込みました。
PAM – SunSSH は PAM を使用します。OpenSSH UsePAM 構成キーワードはサポートされていません。
特権分離 – SunSSH の特権分離コードは常にオンに設定されており、オフに切り替えることはできません。
この実装では、監査、記録管理、および再キーイングの処理がセッションプロトコルの処理から分離されます。OpenSSH UsePrivilegeSeparation キーワードはサポートされていません。
ロケール – SunSSH では、RFC 4253「Secure Shell Transfer Protocol」で定義されている言語ネゴシエーションが完全にサポートされています。ユーザーがログインしたあと、ユーザーのログインシェルプロファイルは Secure Shell でネゴシエーションを行なったロケール設定をオーバーライドできます。
監査 – SunSSH は Oracle Solaris 監査サービスに完全に統合されています。監査サービスについては、Oracle Solaris 11.3 での監査の管理を参照してください。
GSS-API のサポート – SunSSH では、GSS-API 認証はユーザー認証と初期鍵交換の両方に使用できます。GSS-API 認証は、RFC4462「Generic Security Service Application Program Interface」で定義されています。
プロキシコマンド – SunSSH では、SOCKS5 プロトコルと HTTP プロトコルのプロキシコマンドが提供されています。例については、ファイアウォール外部のホストへのデフォルトの Secure Shell 接続を設定する方法を参照してください。
SunSSH は SSH_OLD_FORWARD_ADDR 互換性フラグを OpenSSH プロジェクトから再同期します。
SunSSH は OpenSSL FIPS 140-2 モジュールのコンシューマです。Oracle Solaris は、SunSSH サーバー側とクライアント側に FIPS 140-2 オプションを提供します。FIPS 140-2 の要件に準拠するには、管理者は FIPS 140-2 オプションを構成および使用するようにしてください。
FIPS 140-2 モードの SunSSH はデフォルトではありません。管理者は、明示的に SunSSH を FIPS 140-2 モードで動作できるようにする必要があります。コマンド ssh -o "UseFIPS140 yes" remote-host を使用して FIPS 140-2 モードを起動できます。構成ファイル内にキーワードを設定することもできます。
簡単に説明すると、この実装は次のもので構成されます。
SunSSH のサーバー側とクライアント側で、次の FIPS 140-2 承認の暗号化方式を使用できます: aes128-cbc、aes192-cbc、および aes256-cbc。
3des-cbc は、クライアント側ではデフォルトで使用できますが、セキュリティーリスクの可能性があるため、SunSSH サーバー側の暗号化方式のリストには含まれていません。
次の FIPS 140-2 承認のメッセージ認証コード (MAC) を使用できます。
hmac-sha1、hmac-sha1-96
hmac-sha2-256、hmac-sha2-256-96
hmac-sha2-512、hmac-sha2-512-96
4 つの SunSSH サーバークライアント構成がサポートされています。
クライアントとサーバーの両方で FIPS 140-2 モードを使用しない
クライアントとサーバーの両方で FIPS 140-2 モードを使用する
サーバーでは FIPS 140-2 モードを使用するがクライアントでは FIPS 140-2 モードを使用しない
サーバーでは FIPS 140-2 モードを使用しないがクライアントでは FIPS 140-2 モードを使用する
ssh-keygen コマンドには、FIPS 140-2 モードの SunSSH クライアントに必要な PKCS #8 形式でユーザーの非公開鍵を生成するためのオプションがあります。詳細は、ssh-keygen(1) のマニュアルページを参照してください。
FIPS 140-2 および SunSSH の詳細は、Oracle Solaris 11.3 での FIPS 140-2 対応システムの使用、Oracle Solaris 11.3 での暗号化と証明書の管理 の FIPS 140-2 が有効になったブート環境の作成および sshd(1M) のマニュアルページを参照してください。
Secure Shell の操作に Sun Crypto Accelerator 6000 カードを使用すると、SunSSH はレベル 3 の FIPS 140-2 サポートを受けて実行されます。レベル 3 のハードウェアは、物理的な改ざんへの耐性があり、ID ベースの認証を使用し、重要なセキュリティーパラメータを処理するインタフェースをハードウェアのほかのインタフェースから分離するものとして認定されています。
SunSSH では、受け入れた公開鍵タイプを制御して、弱い鍵タイプを無効にできるようにする新しいキーワードが追加されました。デフォルトは、すべての鍵のタイプを受け入れることです。
SunSSH サーバー構成には次の新しいキーワードが追加されました。
HostKeyAlgorithms
HostbasedAcceptedKeyTypes
PubkeyAcceptedKeyTypes
Kexalgorithms
詳細は、sshd_config(4) のマニュアルページを参照してください。
SunSSH クライアント構成には次の新しいキーワードが追加されました。
HostbasedAcceptedKeyTypes
PubkeyAcceptedKeyTypes
Kexalgorithms
詳細は、ssh_config(4) のマニュアルページを参照してください。
X.509 証明書は SunSSH 認証に適しています。これらはリモートスクリプトを実行する場合など、ユーザーとの対話が許可されていないリモートログインではもっとも安全なオプションです。また、ユーザーにホスト ID を受け入れることを求めるプロンプトが表示されず、ユーザーの公開鍵がリモートサーバー上に存在する必要がありません。
ユーザー (SunSSH クライアント) が SunSSH サーバーへの接続を試みたときに、サーバーはホスト証明書をクライアントに渡します。CA 証明書内の認証局 (CA) の公開鍵を使用することにより、クライアントは CA に関連付けられたデジタル署名に対してサーバー上のホスト証明書を検証します。
X.509 証明書の構成には次のステップが必要になります。
管理者はユーザーがリモートログインするサーバー上にサーバーの X.509 証明書を生成します
サーバーにリモートでログインする予定のユーザーは、自分の X.509 証明書を生成します
管理者はサーバーのルート証明書の公開部分を、ユーザーを構成する管理者に送信します
すべてのユーザーは、ルート証明書の公開部分 (SunSSH 構成ファイル内で「トラストアンカー」または TA と呼ばれます) をリモートサーバーの管理者に送信します
サーバー管理者はユーザーの TA 証明書を、ssh デーモンが読み取りできる場所に保管します
ユーザー管理者はサーバーの TA 証明書を、ssh デーモンが読み取りできる場所に保管します
その後、ユーザーは SunSSH を使用して、リモートサーバーにログインできます
ユーザーは、自己署名付きトラストアンカー (TA) 証明書を生成して署名することもできます。自己署名付き証明書はあまりセキュアではありません。証明書に自己署名するユーザーは、証明書に関する技術上およびセキュリティー上の問題について精通している必要があります。
手順については、Secure Shell の構成を参照してください。