[Jiwang] SSHプロトコルの詳細説明

1. コンセプトの紹介

SSH (Secure Shell)、セキュア シェル プロトコルは、アプリケーション層に基づくセキュリティ プロトコルであり、パスワードを暗号化して検証することにより、安全でないネットワークでのネットワーク サービスに安全な伝送環境を提供し、SSH クライアントを実現します。 SSH サーバー。つまり、SSH はクライアント/サーバー モデルに基づいています。

2.機能

SSH を使用すると、すべての送信データを暗号化できるため、「中間者」攻撃が不可能になり、DNS スプーフィングや IP スプーフィングも可能になります。また、送信データが圧縮されるため、通信速度を高速化できるという利点もあります。

SSH には多くの機能があり、Telnet を置き換えるだけでなく、FTP、Pop、さらには PPP に安全な「チャネル」を提供することもできます。

3. サービス構成

SSH サービスは、サーバー ソフトウェア OpenSSH と接続クライアント (SSH、SecureCRT、xshell など) で構成されており、デフォルトのポートは 22 です。SSH は、クライアント要求をリアルタイムで監視し、処理するデーモン プロセスです。

4. フレームワーク構成

SSH プロトコル フレームワークには、トランスポート層プロトコル、ユーザー認証プロトコル、接続プロトコルの 3 つの主要なプロトコルがあります。

1. トランスポート層プロトコル: サーバー認証、データ セキュリティ、情報の整合性、その他の機能のサポートを提供します。
2. 認証プロトコル: サーバーにクライアントの ID を提供します。
3. 接続プロトコル: 暗号化された情報トンネルを複数の論理チャネルに多重化し、それらを上位レベルのアプリケーション プロトコルに提供します。さまざまな上位レベルのアプリケーション プロトコルは SSH 基本システムから比較的独立しており、この基本システムに依存します。接続プロトコルを介した SSH のセキュリティ メカニズム。
   

5. ワークフロー

1. バージョン番号ネゴシエーション フェーズでは、
   SSH には現在 SSH1 と SSH2 の 2 つのバージョンが含まれており、両者はバージョン ネゴシエーションを通じて実際にバージョンを使用します。
   (1) サーバーはポート 22 を開き、クライアントが接続要求を開始するのを待ちます。
   (2) クライアントはサーバーに対して TCP 初期接続要求を開始し、確立後、サーバーはクライアントにメッセージ (バージョン フラグ文字列: SSH-<メイン プロトコルのバージョン番号>.<セカンダリ プロトコルのバージョン番号>-<ソフトウェア バージョン) を送信します。 Number>)
   (3) メッセージを受信した後、クライアントはデータ パケットを解析します。サーバーのプロトコル バージョン番号が自身のプロトコル バージョン番号よりも低く、クライアントがサーバーの下位バージョンをサポートできる場合は、サーバーの下位バージョンのプロトコル番号を使用します。それ以外の場合は、クライアントの独自のプロトコル バージョン番号が使用されます。
   (4) クライアントは、使用することを決定したプロトコルのバージョン番号を含むメッセージでサーバーに応答します。サーバーはクライアントから送信されたバージョン番号を比較して、クライアントと正常に動作するかどうかを判断します。
   (5) ネゴシエーションが成功すると、キーとアルゴリズムのネゴシエーション段階に入ります。そうでない場合、サーバーは TCP 接続を切断します。

注: バージョン番号ネゴシエーション フェーズ中のメッセージはクリア テキストで送信されます。

2. キーとアルゴリズムのネゴシエーション フェーズでは、
   SSH は複数の暗号化アルゴリズムをサポートしており、両者はサーバーとクライアントでサポートされているアルゴリズムに基づいて最終的なアルゴリズムをネゴシエートします。

(1) サーバーとクライアントはそれぞれ、公開鍵アルゴリズムリスト、暗号化アルゴリズムリスト、MAC (メッセージ認証コード、メッセージ検証コード) アルゴリズムリスト、圧縮アルゴリズムリストなどを含むアルゴリズムネゴシエーションメッセージを相互に送信します。サポート、情報の交渉。
(2) サーバーとクライアントは、相互および自身がサポートするアルゴリズム リストに基づいて、最終的に使用するアルゴリズムを決定します。
サーバーとクライアントは、DH (Diffie-Hellmenan Exchange) アルゴリズムとホスト キー パリティ パラメーターを使用してセッション キーとセッション ID を生成し、その後、両方の当事者が同じセッション ID とセッション キーを取得します。
(3) その後のデータ通信では、データ送信の安全性を確保するために、双方がセッション キーを使用して暗号化および復号化します。

注: ネゴシエーション フェーズの前に、サーバーはすでに RSA または DSA キー ペアを生成しています。これは主にセッション キーの生成に参加するために使用されます。

3. 認証フェーズでは
   、SSH クライアントがサーバーへの認証リクエストを開始し、サーバーがクライアントを認証します。

(1) クライアントはサーバに対して、ユーザ名、認証方式、認証方式に関する内容（例えばパスワード認証の場合はパスワード）を含む認証要求を送信します。
サーバーはクライアントを認証します。認証が失敗した場合、サーバーはクライアントに認証失敗メッセージを送信します。このメッセージには、認証を再度開始できる方法のリストも含まれています。
(2) クライアントは、サーバから返された認証方式リストから認証方式を選択し、再認証を行います。
(3) このプロセスは、認証が成功するか、認証回数が上限に達してサーバーが接続を切断するまで繰り返されます。

4. セッション要求フェーズ
   認証に合格した後、クライアントはサーバーにセッション要求を送信します。

(1) サーバーはクライアントのリクエストを待ちます
(2) 認証に合格した後、クライアントはサーバーにセッションリクエストを送信します
(3) サーバーはクライアントのリクエストを処理します リクエストが正常に処理された後、サーバーは次のように応答しますクライアントに SSH_SSMG_SUCCESS パケットが送信され、SSH は対話の応答フェーズに入ります。それ以外の場合は、サーバーが要求の処理に失敗したか、要求を認識できないことを示す SSH_SSMG_FAILURE パケットが応答されます。

5. 対話型セッション段階:
   セッション要求が通過した後、サーバーとクライアントは情報を交換できます。

(1) クライアントは、実行するコマンドを暗号化して
サーバーに送信します (2) サーバーはメッセージを受信し、復号してコマンドを実行し、実行結果を暗号化してクライアントに送り返します (3) クライアント
は受信した結果を復号化して端末に表示します

注: 現段階では、データは両方向に送信できます。

6. 認証方法

1. パスワード認証

   クライアントはパスワード認証要求をサーバーに送信し、ユーザー名とパスワードを暗号化してサーバーに送信します。サーバーは情報を復号化して、ユーザー名とパスワードの平文を取得します。デバイスに保存されているユーザー名とパスワードと比較し、認証の成功または失敗を示すメッセージを返します。

2. 公開鍵認証

   デジタル署名を使用してクライアントを認証します。現在、デバイスにデジタル署名を実装するために、RSA と DSA という 2 つの公開キー アルゴリズムを使用できます。

   クライアントは、ユーザー名、公開鍵、公開鍵アルゴリズムを含む公開鍵認証リクエストをサーバーに送信します。サーバーは公開キーの有効性をチェックし、有効でない場合は失敗メッセージを直接送信します。有効でない場合は、サーバーはデジタル署名を使用してクライアントを認証し、認証の成功または失敗を示すメッセージを返します。

SSH キー認証ログインプロセス:

(1) SSH 接続を確立する前に、SSH クライアントは独自の公開鍵と秘密鍵のペアを生成し、独自の公開鍵を SSH サーバーに保存する必要があります。
(2) SSH クライアントがログイン要求を送信すると、SSH サーバーは、要求内のユーザー名およびその他の情報に基づいてクライアントの公開キーをローカルで検索し、この公開キーを使用して乱数を暗号化し、クライアント。
(3) クライアントは、返された情報を独自の秘密キーを使用して復号化し、サーバーに送信します。
(4) サーバーは、クライアントが復号した情報が正しいかどうかを検証し、正しければ認証を通過します。

SSH プロトコルは、インターネット ネットワーク内のホスト間の相互アクセスと情報交換を目的としているため、ホスト キーが基本的なキー メカニズムになります。つまり、SSH プロトコルでは、このプロトコルを使用する各ホストが少なくとも 1 つの独自のホスト キー ペアを持っている必要があり、サーバーはクライアントのホスト キーの認証に合格した後にのみ接続要求を許可できます。ホストは複数のキーを使用し、異なるキー アルゴリズムに対して異なるキーを持つことができますが、少なくとも 1 つ、つまり DSS アルゴリズムによって生成されたキーが必要です。

次の図に示すように、SSH プロトコルのホスト キー認証には 2 つの管理スキームがあります。

スキーム 1

スキーム 2

各ホストには独自のホスト キーが必要です。キーのペアは複数存在できます。各ホスト キー ペアには、公開キーと秘密キーが含まれます。これらのキーは実際のアプリケーションでどのように使用され、セキュリティ機能を実装するために利用されますか? 上の図に示すように、SSH プロトコル フレームワークでは 2 つのソリューションが提案されています。

1つ目の方式では、ホストが自身の公開鍵を該当クライアントに配布し、クライアントがホストにアクセスする際に、ホストはホストの公開鍵を使ってデータを暗号化し、ホストは自身の秘密鍵を使ってデータを復号化することで実現する。ホスト キー認証とクライアントの信頼できる ID の決定。図 2(a) からわかるように、ユーザーはホスト A からホスト B とホスト C にアクセスする操作を開始します。この時点で、A がクライアントとなり、ホスト B とホスト C の公開鍵を設定する必要があります。アクセスすると、ホスト名に基づいて対応する公開鍵が見つかります。訪問先のホスト (つまりサーバー) の場合は、その秘密キーが安全に保管されていることを確認するだけで済みます。

2 番目のソリューションでは、キー認証センターがあり、システム内でサービスを提供するすべてのホストが公開キーを認証センターに送信し、クライアントであるホストは認証センターの公開キーのコピーを保存するだけで済みます。キーをクリックするだけです。このモードでは、クライアントはサーバー ホストにアクセスする前に、キー認証センターに認証を要求する必要があり、認証されて初めて宛先ホストに正しく接続できます。

明らかに、最初の方法の方が実装は簡単ですが、すべての変更をクライアントに反映する必要があるため、クライアントのキーのメンテナンスが面倒です。2 番目の方法は、管理とメンテナンスの問題を完全に解決しますが、このようなモデルでは、このようなインターネット上での一元的な認証を実現するには、権限を確認するだけでも大変ですし、誰が最終決定権を持つのでしょうか？しかし、長期的な開発の観点から、エンタープライズアプリケーションや商用アプリケーションの分野では、一元的な認証ソリューションを採用する必要があります。

さらに、SSH プロトコル フレームワークでは、ホスト キーの侵害も許可されています。つまり、最初のアクセスに認証は必要ありません。初回アクセス時の認証不要とは、クライアントが初めてホストにアクセスするときに、ホストがホスト キーをチェックせず、公開キーのコピーをクライアントに発行するため、以降のアクセスではそのキーを使用する必要があることを意味します。 . そうでない場合は、違法とみなされ、アクセスが拒否されます。

3. パスワード + 公開キー認証 (SSH2.0) は、
   ユーザーの認証方法がパスワード + 公開キー認証であることを指定しており、同時に満たす必要があります。

   注: クライアント バージョン SSH1 のユーザーは、いずれかの認証に合格すればログインできますが、クライアント バージョン SSH2 のユーザーは、ログインする前に両方の認証に合格する必要があります。

4. 任意の認証
   ユーザーの認証方法がパスワードまたは公開鍵のいずれかであることを指定します。

7. よく使われるコマンド

1. リモートログイン
   ssh ユーザー名@リモートホスト IP: 初回ログイン時に相手の公開鍵をダウンロードする必要があります。
   例: ssh [email protected]

2. リモート アップロード
   scp [ファイルをアップロードする必要があるローカルの場所] root@リモート ホスト ip: [リモート ホストの朝のパスに保存する必要があります]: ファイルをローカルからリモート ホストにアップロードします。
   例: scp /root/test.sh [email protected]

3. Remote copy
   scp root@remote host ip:[リモート ホスト ファイルの絶対パス][保存するローカルの場所]: リモート ホストからローカル マシンにファイルをダウンロードします。
   例: scp [email protected]:/root/test.sh /root