はじめに
このドキュメントでは、セキュアシェル(SSH)ネゴシエーション中のパケットレベル交換について説明します。
前提条件
要件
基本的なセキュリティの概念に関する知識があることが推奨されます。
- [Authentication]
- 機密保持
- 整合性
- キー交換方式
使用するコンポーネント
このドキュメントは、特定のハードウェアバージョンに限定されるものではありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。
SSHプロトコル
SSHプロトコルは、1台のコンピュータから別のコンピュータに安全なリモートログインを行うための方法です。SSHアプリケーションはクライアント/サーバアーキテクチャに基づいており、SSHクライアントインスタンスをSSHサーバに接続します。
SSH交換
1. SSHの最初のステップが Identification String Exchange
.
a.クライアントはパケットを作成し、それを次の情報を含むサーバに送信します。
- SSHプロトコルバージョン
- [Software Version]
クライアントプロトコルのバージョンはSSH2.0、ソフトウェアのバージョンはPutty_0.76です。
b.サーバは、SSHプロトコルバージョンとソフトウェアバージョンを含む独自のID文字列交換で応答します。
サーバのプロトコルバージョンはSSH2.0で、ソフトウェアバージョンはCisco1.25です。
2. 次のステップは「Algorithm Negotiation.
」です。このステップでは、クライアントとサーバの両方が次のアルゴリズムをネゴシエートします。
- 鍵交換
- 暗号化
- HMAC(ハッシュベースのメッセージ認証コード)
- 圧縮
- クライアントは、サポートするアルゴリズムを指定して、Key Exchange Initメッセージをサーバに送信します。アルゴリズムは優先順位に従ってリストされます。
キー交換の初期化
クライアントがサポートするアルゴリズム
b.サーバは自身のKey Exchange Initメッセージで応答し、サポートするアルゴリズムをリストします。
c.これらのメッセージは同時に交換されるため、両方のパーティがアルゴリズムリストを比較します。両方の側でサポートされているアルゴリズムに一致がある場合は、次のステップに進みます。完全に一致するアルゴリズムがない場合、サーバはクライアントのリストから同じくサポートする最初のアルゴリズムを選択します。
d.クライアントとサーバが共通のアルゴリズムに合意できない場合、キー交換は失敗します。
サーバーキー交換の初期化
3. この後、両側でKey Exchang
e
フェーズに入り、DHキー交換を使用して共有秘密を生成し、サーバを認証します。
a.クライアントはキーペアを生成しPublic and Private
、DH Group Exchange InitパケットでDH公開キーを送信します。このキーペアは、秘密キーの計算に使用されます。
クライアントDH公開キーとDiffie-Hellmanグループ交換の初期化
b.サーバはそれ自体のPublic and Private
キーペアを生成します。 クライアントの公開キーと独自のキーペアを使用して共有秘密を計算する
c.サーバは、次の入力を使用してExchangeハッシュも計算します。
- クライアント識別文字列
- サーバID文字列
- クライアントKEXINITのペイロード
- サーバKEXINITのペイロード
- ホストキーからのサーバ公開キー( RSAキーペア)
- クライアントDH公開キー
- サーバDH公開キー
- 共有秘密キー
d.ハッシュの計算後、サーバはRSA秘密キーを使用してハッシュに署名します。
e.サーバは、次の内容を含むメッセージDH_Exchange_Replyを作成します。
- サーバのRSA公開キー(クライアントがサーバを認証するのを支援するため)
- サーバのDH公開キー(共有秘密を計算するため)
- HASH(秘密キーはハッシュ計算の一部であるため、サーバを認証し、サーバが共有秘密を生成したことを証明するため)
サーバDH公開キーとDiffie-Hellmanグループ交換応答
f. DH_Exchange_Replyの受信後、クライアントは同じ方法でハッシュを計算し、受信したハッシュと比較し、サーバのRSA公開キーを使用して復号化します。
g.受信したHASHを復号化する前に、クライアントはサーバの公開キーを確認する必要があります。この検証は、認証局(CA)によって署名されたデジタル証明書を使用して行われます。証明書が存在しない場合は、サーバの公開キーを受け入れるかどうかをクライアントが決定します。
注:デジタル証明書を使用しないデバイスに初めてSSH接続する際に、サーバの公開キーを手動で受け入れるよう求めるポップアップが表示されることがあります。接続するたびにポップアップが表示されないようにするには、サーバのホストキーをキャッシュに追加することを選択できます。
サーバのRSAキー
4. これで共有秘密が生成されたため、両方の端末が共有秘密を使用してこれらの鍵を取得します(共有秘密は暗号化の対象となります)。
- 暗号化キー
- IVキー:これらは、セキュリティを強化するために対称アルゴリズムへの入力として使用される乱数です
- 整合性キー
キー交換の終了は、NEW KEYS'
メッセージの交換によって通知されます。このメッセージによって、各当事者は以降のすべてのメッセージがこれらの新しいキーを使用して暗号化および保護されることを知らされます(新しいキーによって、新しいキーは暗号化されません)。
クライアントとサーバの新しいキー
5. 最後のステップはサービスリクエストです。クライアントは、SSHサービスリクエストパケットをサーバに送信してユーザ認証を開始します。サーバはSSH Service Acceptメッセージで応答し、クライアントにログインを要求します。この交換は、確立された安全なチャネルを介して行われます。
関連情報