ssh公開/秘密鍵ペア
Sshの実際の動作を理解するのに問題があります。私はそれがメッセージを暗号化するために公開鍵暗号を使用していることを知っています。ただし、公開鍵と秘密鍵のペアを最初に生成しなくても、サーバーにSSHで接続できます。 .sshフォルダーを確認しましたが、そこに.pubファイルがないので、サーバーが認識している公開鍵がないと思います。そもそも公開鍵がない場合、サーバーはどのようにして暗号化されたメッセージを送信できますか？
これらは実際には2つの異なるものです。あなたが話している公開鍵と秘密鍵のペアはauthenticationのためのものです。
Sshサーバーに接続すると、クライアントとサーバーは、通信の暗号化に使用するキーをネゴシエートします。 Diffie-Hellmann鍵交換アルゴリズム から派生したいくつかのアルゴリズム。ブラウザでhttpsプロトコルを介してページにアクセスする場合も同じ方法が使用されます。
Sshプロトコルの内部動作に興味がある場合は、チェックアウトしてください here 。それは開いています;）
edit：しかし、私はDennisに同意します。暗号化フォーラムがこれに適しています。
@klaustopherが説明するように、SSHトンネルはDiffie-Hellman鍵交換を使用して、クライアントとサーバー間の共有秘密を確立します。この共有シークレットは対称暗号化で使用され、後で交換されるすべてのデータの整合性を暗号化してチェックします。
DH +対称暗号自体も問題ありませんが、その半分しか機能しません。 DHプロトコルが実行されると、クライアントとサーバーの両方が、誰かとの安全なトンネルを確立したことを認識します。しかし、彼らはだれを知りません。彼らは、これが接続の存続期間を通して同じエンティティになることを知っています。そのため、これは、クライアント、サーバー、またはその両方を偽装するアクティブな攻撃者に対して脆弱です。有名な 中間者攻撃 は、二重のなりすましの場合です（攻撃者がクライアントと話すと偽のサーバーとして機能し、サーバーと話すと偽のクライアントとして機能します）。 。
完全に安全なトンネルを安全に機密データと機密コマンドを送信するために、クライアントとサーバーは相互に認証する必要があります。プロトコルの最初のステップで、サーバー signs 彼が送信するもの（彼のDiffie-Hellmanプロトコルの半分）。クライアントは、既知のサーバー公開鍵（クライアントが.ssh/known_hostsに保存するもの）に関して署名を検証します。署名が検証されると、クライアントは、意図したサーバーを装った攻撃者ではなく、本物のサーバーとのDHキー交換を行っていることを認識します。つまり、クライアントは機密データをトンネル経由で安全に送信できます。特に、DHが完了すると、最初の交換は次のようになります。
- （サーバー）OK、新しいクライアント。私たちはDHを行いました、私は署名しました、あなたは確認しました、あなたは私が正しいサーバーであることを知っています。あなたは誰 ？
- （クライアント）ボブです。
- （サーバー）証明してください！
- （クライアント）これが私のパスワードです：bobisthemasteroftheuniverse
- （サーバー）わかりました、私doは "Bob"ユーザーを知っています。それが正しいパスワードです。ようこそ、ボブ。
クライアントによるサーバーの認証（署名検証アルゴリズムによる）のおかげで、クライアントは自分のパスワードをトンネルで安全に送信できることがわかります。
SSHプロトコルまた、は、署名ベースのクライアント認証をサポートしています。サーバーによるDHと署名は、以前と同様に行われます。ただし、プロトコルは次のようになります。
- （サーバー）OK、新しいクライアント。私たちはDHを行いました、私は署名しました、あなたは確認しました、あなたは私が正しいサーバーであることを知っています。あなたは誰 ？
- （クライアント）ボブです。キーペアを持っています！公開鍵IDは（...）
- （サーバー）ええ、それを見てみましょう。ここにランダムなデータの束があります、私はそれに署名するように要求します：（...）
- （クライアント）チャレンジで新しく生成された署名は次のとおりです：（...）
- （サーバー）よかった。私は「ボブ」を知っています。彼の
.ssh/authorized_keysには、あなたが送信したIDと一致する公開鍵が含まれており、私のチャレンジの署名は、その公開鍵に関して正しく検証されます。ようこそ、ボブ。
HTTPSでもほぼ同じことが起こります。多くのローカルな違いがあります。 HTTPSクライアントは、前回のアクセス時の証明書を記憶するのではなく、証明書を検証することによってサーバーの公開鍵を認識します。そしてパスワードは実際のウェブページの形をとることができます。しかし、交換の要点は同じです。クライアントは、公開鍵を検証することによって適切なサーバーと通信することを確認し、次にサーバーは、適切なクライアントと通信することを確認します（サーバーが本当に知りたい場合whois the client）ある種の認証プロトコルwithinをトンネル内で実行する。