この質問にはすでに回答があります：
コメント
回答
基本的に、本当に長いパスワードよりも優れている理由は何ですか？
サーバーには転送されません（非常に長いパスワードでも転送する必要があるため）。 sshの場合（壊れた暗号を使用しない限りチャネルは暗号化されます）は安全ではありませんが、理論的には中間者または悪意のある（スーパー）ユーザーによって傍受される可能性があります。リモートサーバー。
公開鍵はどのように機能しますか？
これが非対称暗号化のポイントです。秘密鍵は署名を作成し、公開鍵は署名がそれぞれの公開鍵によって作成されたことを確認できます。サーバーから提供されたデータの公開鍵と署名を送信すると、サーバーがアクセスを許可するのに十分です（公開鍵がauthorized_keysのものと一致する場合）。
コメント
回答
SSHと「非常に長いパスワード」を比較しているのが「よくわかりません」。 SSHは、ユーザーのログインとパスワードをリモートサーバーに送信するための安全な手段を提供します。または、クライアントの公開鍵を使用することもできます。非対称鍵は、ユーザーが不正なパスワードを作成する可能性がないため、一般に解読が困難です。そのため、公開鍵ベースの認証が推奨されます。ユーザー（およびIP）の特定の公開鍵をホワイトリストに登録して、誰もが自分のユーザー名で、どのコンピューターからでもログインできるようにすることができます。このホワイトリストは/home/<user>/.ssh/authorized_keysに含まれています。
SSHの基本：
-
サーバーはRSA公開鍵をクライアント。クライアントは、続行する前にこのキーを信頼していることを手動で確認します。
-
SSHはDiffieHellmanを使用して共有秘密値を確立します。
-
共有秘密と多くの鍵交換データが一緒にハッシュされ、サーバーの秘密鍵を使用して署名されます。
-
クライアントは、以前のサーバーを使用してこの署名を確認できます。信頼できる公開鍵。
-
セッション鍵の生成に必要なすべての情報が両側にあります。
セクション
RFC4253の7.2
7.2. Output from Key Exchange The key exchange produces two values: a shared secret K, and an exchange hash H. Encryption and authentication keys are derived from these. The exchange hash H from the first key exchange is additionally used as the session identifier, which is a unique identifier for this connection. It is used by authentication methods as a part of the data that is signed as a proof of possession of a private key. Once computed, the session identifier is not changed, even if keys are later re-exchanged. Each key exchange method specifies a hash function that is used in the key exchange. The same hash algorithm MUST be used in key derivation. Here, we"ll call it HASH. Encryption keys MUST be computed as HASH, of a known value and K, as follows: o Initial IV client to server: HASH(K || H || "A" || session_id) (Here K is encoded as mpint and "A" as byte and session_id as raw data. "A" means the single character A, ASCII 65). o Initial IV server to client: HASH(K || H || "B" || session_id) o Encryption key client to server: HASH(K || H || "C" || session_id) o Encryption key server to client: HASH(K || H || "D" || session_id) o Integrity key client to server: HASH(K || H || "E" || session_id) o Integrity key server to client: HASH(K || H || "F" || session_id) Key data MUST be taken from the beginning of the hash output. As many bytes as needed are taken from the beginning of the hash value. If the key length needed is longer than the output of the HASH, the key is extended by computing HASH of the concatenation of K and H and the entire key so far, and appending the resulting bytes (as many as HASH generates) to the key. This process is repeated until enough key material is available; the key is taken from the beginning of this value. In other words: K1 = HASH(K || H || X || session_id) (X is e.g., "A") K2 = HASH(K || H || K1) K3 = HASH(K || H || K1 || K2) ... key = K1 || K2 || K3 || ... This process will lose entropy if the amount of entropy in K is larger than the internal state size of HASH.
暗号化されたチャネルが確立されると、SSHプロトコルはクライアント認証に基づいて開始しますあなたがそれを与えたパラメータに基づいて。これはすべて暗号化されたチャネルを介して安全に実行されます。
概要を説明します。明らかに、SSHであれHTTPSであれ、安全な通信の必要性を理解しています。安全な通信とは、チャネルが暗号化されることを意味します。
一般的に、すべての暗号化アルゴリズムは、次の2つのカテゴリのいずれかに分類されます。
- 対称暗号化。 1キー。同じキーが暗号化と復号化に使用されます。速い。例えば。 AES。
- 非対称暗号化。 2つのキー。どちらも暗号化に使用できますが、復号化できるのはもう一方だけです。対称アルゴリズムよりもはるかに低速です。例えば。 RSA。
対称暗号化は高速であるため、2者間の大量のデータを含む通信に適しています。暗号化と復号化に同じキーを使用します。このキーは、非常に長いパスワードの概念に類似しています。問題：そもそもキー/パスワードをどのように共有しますか？キー/パスワードを最初に共有する方法を考え出さずに、対称暗号化アルゴリズムのみに基づいて構築された安全なチャネルを使用することはできません。
ここで非対称アルゴリズムが登場しますが、それよりもかなり低速です。対称アルゴリズム。大量のデータを送信することは実用的ではありませんが、対称暗号化キー/パスワードなどの小さなものを送信または交換する場合は問題ありません。これが完了すると、通信に対称暗号化を使用できるようになります。
非対称暗号化の2つの鍵の一方は公開鍵に指定され、もう一方は秘密鍵に指定されます。公開鍵はすべての人に配布できます。ただし、秘密鍵は秘密にしておく必要があります。
You (has pub) Server (has prv + pub) asym-encrypt(pub, sym-key/pwd) ----> asym-decrypt(prv, encrypted-data) => sym-key/pwd
pub =公開鍵、prv =秘密鍵
いずれの場合も、この説明はSSHが実際に行うことの簡略化。強調する価値のある他の2つのこと：
-
Diffie Hellmanは、典型的な鍵交換非対称アルゴリズムです。DiffieHellmanを使用すると、実際に対称鍵を作成する必要はありません。 。両者は、鍵交換中に対称鍵を一緒に作成します。これは、優れたセキュリティ機能です。 " Diffie-Hellman Key Exchange "を平易な英語で参照してください。
-
私の説明では、サーバーの公開鍵を見つけ、それが正しいものであると信頼していると仮定しました。ただし、どの公開鍵を使用するかについては注意が必要です。信頼。公開鍵を信頼するには、デジタル署名する必要があります。署名された公開鍵は、証明書とも呼ばれます。
これにより、長いパスワードに関する質問が解決され、公開鍵であり、より意味のある方法で深く掘り下げるのに十分な情報があります。