前書き

SSH(セキュアシェル)は、セキュアなプロトコルであり、リモートサーバーを安全に管理する最も一般的な方法です。 SSHは、多くの暗号化技術を使用して、2者間の暗号で保護された接続を確立し、各側を相互に認証し、コマンドと出力をやり取りするメカニズムを提供します。

他のガイドでは、https://www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server [SSHキーベースの設定方法アクセス]、https://www.digitalocean.com/community/tutorials/how-to-use-ssh-to-connect-to-a-remote-server-in-ubuntu [SSHを使用した接続方法]、およびhttps ://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys [SSHのヒントとテクニック]。

このガイドでは、SSHが採用している基礎となる暗号化技術と、SSHが安全な接続を確立するために使用する方法を調べます。 この情報は、暗号化のさまざまな層と、接続を形成して双方を認証するために必要なさまざまな手順を理解するのに役立ちます。

対称暗号化、非対称暗号化、およびハッシュ

情報の送信を保護するために、SSHは、トランザクションのさまざまなポイントで多くの異なるタイプのデータ操作技術を採用しています。 これらには、対称暗号化、非対称暗号化、およびハッシュの形式が含まれます。

対称暗号化

データを暗号化および復号化するコンポーネントの関係により、暗号化スキームが対称か非対称かが決まります。

対称暗号化は、1つのキーを使用して相手側へのメッセージを暗号化したり、他の参加者から受信したメッセージを解読したりできる暗号化の一種です。 これは、キーを保持している人はだれでも、キーを保持している他の人へのメッセージを暗号化および復号化できることを意味します。

このタイプの暗号化スキームは、「共有秘密」暗号化または「秘密鍵」暗号化と呼ばれます。 通常、すべての操作に使用される単一のキー、または関係を見つけやすく、反対のキーを導出するのは簡単なキーのペアのみがあります。

SSHは、接続全体を暗号化するために対称キーを使用します。 一部のユーザーが想定していることとは反対に、作成できる公開/秘密の非対称キーペアは認証にのみ使用され、接続の暗号化には使用されません。 対称暗号化により、パスワード認証でさえスヌーピングから保護できます。

クライアントとサーバーの両方がこのキーの確立に寄与し、結果の秘密が外部の当事者に知られることはありません。 秘密鍵は、鍵交換アルゴリズムと呼ばれるプロセスを通じて作成されます。 この交換により、サーバーとクライアントの両方が、特定の公開データを共有し、特定の秘密データで操作することにより、同じキーに個別に到達します。 このプロセスについては、後で詳しく説明します。

この手順で作成される対称暗号化キーはセッションベースであり、サーバーとクライアント間で送信されるデータの実際の暗号化を構成します。 これが確立されたら、残りのデータをこの共有秘密で暗号化する必要があります。 これは、クライアントを認証する前に行われます。

SSHは、AES、Blowfish、3DES、CAST128、Arcfourなど、さまざまな対称暗号システムを利用するように構成できます。 サーバーとクライアントはどちらも、サポートされている暗号のリストを優先順に並べることができます。 サーバーで利用可能なクライアントのリストの最初のオプションは、双方向の暗号アルゴリズムとして使用されます。

Ubuntu 14.04では、クライアントとサーバーの両方が次のようにデフォルト設定されています: + aes128-ctr ++ aes192-ctr ++ aes256-ctr ++ arcfour256 ++ arcfour128 ++ aes128- gcm @ openssh.com + `、 + aes256-gcm @ openssh.com + + chacha20-poly1305 @ openssh.com + + aes128-cbc + + blowfish-cbc + + cast128-cbc + 、 `+ aes192-cbc ++ aes256-cbc ++ arcfour +

これは、2つのUbuntu 14.04マシンが(設定オプションでデフォルトの暗号をオーバーライドすることなく)互いに接続している場合、接続を暗号化するために常に `+ aes128-ctr +`暗号を使用することを意味します。

非対称暗号化

非対称暗号化は対称暗号化とは異なり、単一方向にデータを送信するには2つの関連するキーが必要です。 これらのキーの1つは「プライベートキー」と呼ばれ、もう1つは「公開キー」と呼ばれます。

公開鍵は、任意の関係者と自由に共有できます。 ペアのキーに関連付けられていますが、公開キーから秘密キーを取得することはできません。 公開鍵と秘密鍵の数学的関係により、公開鍵は、秘密鍵によってのみ復号化できるメッセージを暗号化できます。 これは一方向の機能です。つまり、公開キーには、書き込むメッセージを解読する機能はなく、秘密キーが送信するメッセージを解読することもできません。

秘密鍵は完全に秘密にしておき、他者と共有しないでください。 これは、公開キーパラダイムが機能するための重要な要件です。 秘密鍵は、関連する公開鍵を使用して暗号化されたメッセージを復号化できる唯一のコンポーネントです。 この事実により、これらのメッセージを解読できるエンティティは、プライベートキーを制御していることを実証しています。

SSHは、いくつかの異なる場所で非対称暗号化を利用します。 (セッションの暗号化に使用される)対称暗号化のセットアップに使用される初期キー交換プロセス中に、非対称暗号化が使用されます。 この段階では、対称暗号化に使用される共有シークレットを作成するために、両方の当事者が一時キーペアを作成し、公開キーを交換します。

SSHでの非対称暗号化のよりよく議論された使用は、SSH鍵ベースの認証に由来します。 SSHキーペアは、サーバーに対するクライアントの認証に使用できます。 クライアントはキーペアを作成し、アクセスしたいリモートサーバーに公開キーをアップロードします。 これは、リモートサーバー上のユーザーアカウントのホームディレクトリにある `〜/ .ssh +`ディレクトリ内の ` authorized_keys +`というファイルに配置されます。

サーバーとクライアント間の通信を保護するために対称暗号化が確立された後、クライアントはアクセスを許可されるように認証する必要があります。 サーバーは、このファイル内の公開鍵を使用して、クライアントへのチャレンジメッセージを暗号化できます。 クライアントがこのメッセージを解読できたことを証明できた場合、クライアントは関連する秘密キーを所有していることを証明しました。 サーバーは、クライアントの環境をセットアップできます。

ハッシング

SSHが利用する別の形式のデータ操作は、暗号化ハッシュです。 暗号化ハッシュ関数は、一連の情報の簡潔な「署名」または要約を作成する方法です。 彼らの主な特徴は、決して逆転させることを意図したものではなく、予想通りに影響を与えることは事実上不可能であり、実質的にユニークであることです。

同じハッシュ関数とメッセージを使用すると、同じハッシュが生成されます。データの一部を変更すると、まったく異なるハッシュが生成されます。 ユーザーは、特定のハッシュから元のメッセージを生成することはできませんが、特定のメッセージが特定のハッシュを生成したかどうかを判断できる必要があります。

これらのプロパティが与えられると、ハッシュは主にデータの整合性の目的と通信の信頼性の検証に使用されます。 SSHの主な用途は、HMACまたはハッシュベースのメッセージ認証コードです。 これらは、受信したメッセージテキストが無傷で変更されていないことを確認するために使用されます。

上記の対称暗号化ネゴシエーションの一部として、メッセージ認証コード(MAC)アルゴリズムが選択されます。 アルゴリズムは、クライアントの受け入れ可能なMAC選択肢のリストを操作して選択されます。 サーバーがサポートするこのリストの最初のものが使用されます。

暗号化がネゴシエートされた後に送信される各メッセージにはMACが含まれている必要があるため、相手はパケットの整合性を検証できます。 MACは、対称共有シークレット、メッセージのパケットシーケンス番号、および実際のメッセージコンテンツから計算されます。

MAC自体は、パケットの最後の部分として、対称的に暗号化された領域の外部に送信されます。 研究者は一般に、最初にデータを暗号化してからMACを計算するこの方法を推奨しています。

SSHの仕組み

おそらく、SSHがどのように機能するかについての基本的な理解はすでにお持ちでしょう。 SSHプロトコルは、クライアントサーバーモデルを使用して、2者を認証し、両者間のデータを暗号化します。

サーバーコンポーネントは、指定されたポートで接続をリッスンします。 セキュリティで保護された接続のネゴシエート、接続側の認証、資格情報が受け入れられた場合の正しい環境の生成を担当します。

クライアントは、サーバーとの最初のTCPハンドシェイクを開始し、安全な接続をネゴシエートし、サーバーのIDが以前に記録された情報と一致することを確認し、認証のための資格情報を提供します。

SSHセッションは、2つの別々の段階で確立されます。 1つ目は、将来の通信を保護するために暗号化に同意して確立することです。 2番目の段階では、ユーザーを認証し、サーバーへのアクセスを許可する必要があるかどうかを確認します。

セッションの暗号化のネゴシエーション

クライアントがTCP接続を確立すると、サーバーはサポートするプロトコルバージョンで応答します。 クライアントが受け入れ可能なプロトコルバージョンのいずれかと一致する場合、接続は継続します。 サーバーは公開ホストキーも提供します。クライアントはこれを使用して、これが目的のホストであるかどうかを確認できます。

この時点で、両者はDiffie-Hellmanアルゴリズムと呼ばれるバージョンを使用してセッションキーをネゴシエートします。 このアルゴリズム(およびその変形)を使用すると、各パーティは自分のプライベートデータを他のシステムからのパブリックデータと組み合わせて、同一の秘密セッションキーに到達できます。

セッションキーは、セッション全体を暗号化するために使用されます。 手順のこの部分で使用される公開キーと秘密キーのペアは、サーバーに対するクライアントの認証に使用されるSSHキーとは完全に分離されています。

従来のDiffie-Hellmanのこの手順の基本は次のとおりです。

  1. 両当事者は、シード値として機能する大きな素数に同意します。

  2. 両者は、事前定義された方法で値を操作するために使用される暗号化ジェネレーター(通常はAES)に同意します。

  3. 独立して、各当事者は、他の当事者から秘密に保たれる別の素数を思い付きます。 この番号は、この対話の秘密キーとして使用されます(認証に使用される秘密SSHキーとは異なります)。

  4. 生成された秘密鍵、暗号化ジェネレータ、および共有素数は、秘密鍵から派生した公開鍵を生成するために使用されますが、これは相手と共有できます。

  5. その後、両方の参加者は、生成された公開鍵を交換します。

  6. 受信エンティティは、独自の秘密キー、相手の公開キー、および元の共有素数を使用して共有秘密キーを計算します。 これは、反対側の秘密鍵と公開鍵を使用して各当事者によって独立して計算されますが、_same_共有秘密鍵になります。

  7. 共有秘密は、その後のすべての通信を暗号化するために使用されます。

接続の残りに使用される共有秘密暗号化は、バイナリパケットプロトコルと呼ばれます。 上記のプロセスにより、各当事者は共有秘密の生成に平等に参加でき、一方の端が秘密を制御することはできません。 また、安全でないチャネルを介してその情報を送信する必要なく、同一の共有秘密を生成するタスクを実行します。

生成されたシークレットは対称キーです。つまり、メッセージの暗号化に使用したのと同じキーを使用して、反対側でメッセージを復号化できます。 これの目的は、部外者が解読できない暗号化されたトンネルで、それ以降のすべての通信をラップすることです。

セッション暗号化が確立された後、ユーザー認証段階が始まります。

サーバーへのユーザーのアクセスの認証

次の段階では、ユーザーの認証とアクセスの決定を行います。 サーバーが受け入れるものに基づいて、認証に使用できるいくつかの異なる方法があります。

最も単純な方法はおそらくパスワード認証で、サーバーはクライアントにログインしようとしているアカウントのパスワードを要求するだけです。 パスワードはネゴシエートされた暗号化を介して送信されるため、外部から安全です。

パスワードは暗号化されますが、パスワードの複雑さの制限により、この方法は一般的に推奨されません。 自動化されたスクリプトは、他の認証方法と比較して非常に簡単に通常の長さのパスワードを破ることができます。

最も一般的で推奨される代替手段は、SSHキーペアの使用です。 SSHキーペアは非対称キーです。つまり、2つの関連付けられたキーは異なる機能を果たします。

公開鍵は、秘密鍵でのみ復号化できるデータを暗号化するために使用されます。 公開鍵は自由に共有できます。なぜなら、秘密鍵は暗号化できますが、公開鍵から秘密鍵を導出する方法がないためです。

SSHキーペアを使用した認証は、前のセクションで説明したように対称暗号化が確立された後に開始されます。 手順は次のようになります。

  1. クライアントは、サーバーに対して認証するキーペアのIDを送信することから始めます。

  2. サーバーチェックは、クライアントがキーIDにログインしようとしているアカウントの `+ authorized_keys +`ファイルです。

  3. 一致するIDを持つ公開キーがファイル内で見つかった場合、サーバーは乱数を生成し、公開キーを使用して番号を暗号化します。

  4. サーバーは、この暗号化されたメッセージをクライアントに送信します。

  5. クライアントに実際に関連付けられた秘密キーがある場合、そのキーを使用してメッセージを解読し、元の番号を明らかにすることができます。

  6. クライアントは、復号化された番号を、通信の暗号化に使用されている共有セッションキーと結合し、この値のMD5ハッシュを計算します。

  7. クライアントは、このMD5ハッシュを暗号化された番号メッセージへの回答としてサーバーに送り返します。

  8. サーバーは、クライアントに送信したものと同じ共有セッションキーと元の番号を使用して、MD5値を独自に計算します。 独自の計算を、クライアントが送り返した計算と比較します。 これら2つの値が一致する場合、クライアントが秘密キーを所有していたことが証明され、クライアントが認証されます。

ご覧のとおり、キーの非対称性により、サーバーは公開キーを使用してクライアントへのメッセージを暗号化できます。 クライアントは、メッセージを正しく復号化することにより、秘密鍵を保持していることを証明できます。 使用される2種類の暗号化(対称共有シークレットキーと非対称公開秘密キー)は、それぞれこのモデルの特定の強度を活用できます。

結論

接続ネゴシエーションの手順とSSHでの作業中の暗号化の層について学習すると、リモートサーバーにログインしたときに何が起こっているかをより深く理解するのに役立ちます。 うまくいけば、さまざまなコンポーネントとアルゴリズムの関係をよりよく理解し、これらすべての要素がどのように組み合わされるかを理解できたと思います。