SSH와 “매우 긴 암호”를 비교하고 있는지 잘 모르겠습니다. SSH는 사용자 로그인과 암호를 원격 서버로 보내는 안전한 수단을 제공합니다. 또는 클라이언트의 공개 키를 사용할 수 있습니다. 비대칭 키는 사용자가 잘못된 암호를 생성하지 않기 때문에 일반적으로 깨지기가 더 어렵습니다. 이러한 이유로 공개 키 기반 인증이 선호됩니다. 사용자 (및 IP)에 대한 특정 공개 키를 허용 목록에 추가 할 수 있으므로 누구나 사용자 이름으로 그리고 모든 컴퓨터에서 로그인 할 수 없습니다. 이 화이트리스트는 /home/<user>/.ssh/authorized_keys에 포함되어 있습니다.
SSH의 기초 :
-
서버는 RSA 공개 키를 클라이언트. 클라이언트는 계속하기 전에이 키를 신뢰하는지 수동으로 확인합니다.
-
SSH는 Diffie Hellman을 사용하여 공유 비밀 값을 설정합니다.
-
많은 키 교환 데이터와 함께 공유 비밀이 함께 해시되고 서버의 개인 키를 사용하여 서명됩니다.
-
클라이언트는 이전에 서버의 개인 키를 사용하여이 서명을 확인할 수 있습니다. 신뢰할 수있는 공개 키입니다.
-
이제 양쪽에 세션 키를 생성하는 데 필요한 모든 정보가 있습니다.
From section 7.2 of RFC4253
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와 같은 보안 통신의 필요성을 이해합니다. 보안 통신은 채널이 암호화됨을 의미합니다.
일반적으로 모든 암호화 알고리즘은 다음 두 범주 중 하나에 속합니다.
- 대칭 암호화. 하나의 열쇠. 암호화 및 복호화에 동일한 키가 사용됩니다. 빠른. 예 : AES.
- 비대칭 암호화. 두 개의 키. 둘 중 하나를 암호화에 사용할 수 있지만 다른 하나만 해독 할 수 있습니다. 대칭 알고리즘보다 훨씬 느립니다. 예 : RSA.
대칭 암호화는 빠르므로 두 당사자 간의 많은 데이터를 포함하는 통신에 적합합니다. 암호화 및 암호 해독에 동일한 키를 사용합니다.이 키는 매우 긴 암호 개념과 유사합니다. 문제 : 처음에 키 / 암호를 어떻게 공유합니까? 키 / 비밀번호를 먼저 공유하는 방법을 알아 내지 않고는 대칭 암호화 알고리즘에만 구축 된 보안 채널을 사용할 수 없습니다.
비대칭 알고리즘이 들어오는 곳이지만 속도가 훨씬 느립니다. 대칭 알고리즘. 많은 양의 데이터를 전송하는 것은 비현실적이지만 대칭 암호화 키 / 암호와 같은 작은 것을 전송하거나 교환하는 경우 괜찮습니다. 이 작업이 완료되면 이제 통신에 대칭 암호화를 사용할 수 있습니다.
비대칭 암호화를위한 두 키 중 하나는 공개 키이고 다른 하나는 개인 키로 지정됩니다. 공개 키는 모든 사람에게 배포 될 수 있습니다. 그러나 개인 키는 비밀로 유지되어야합니다.
You (has pub) Server (has prv + pub) asym-encrypt(pub, sym-key/pwd) ----> asym-decrypt(prv, encrypted-data) => sym-key/pwd
pub = 공개 키, prv = 개인 키
어쨌든이 설명은 SSH가 실제로 수행하는 작업의 단순화. 강조 할만한 다른 두 가지 사항 :
-
Diffie Hellman은 일반적인 키 교환 비대칭 알고리즘입니다. Diffie Hellman을 사용하면 실제로 대칭 키를 만들 필요가 없습니다. . 양 당사자는 키 교환 중에 대칭 키를 함께 생성하는데, 이는 훌륭한 보안 기능입니다. " Diffie-Hellman 키 교환 " 일반 영어 를 참조하세요.
-
내 설명에서는 서버의 공개 키를 찾았으며 올바른 키라고 믿고 있다고 가정했습니다.하지만 어떤 공개 키를 사용할 지에 대해서는주의해야합니다. 신뢰. 공개 키를 신뢰하려면 디지털 서명해야합니다. 서명 된 공개 키는 인증서라고도합니다.
이렇게하면 긴 암호와 관련된 질문이 해결되기를 바랍니다. 더 의미있는 방식으로 더 깊이 파고들 수있는 충분한 정보가 있습니다.