SSH용 개인+공개 키 쌍 생성: ssh-keygen과 openssl의 차이점은 무엇입니까?

SSH용 개인+공개 키 쌍 생성: ssh-keygen과 openssl의 차이점은 무엇입니까?

SSH 인증에 사용할 개인 키와 공개 키 쌍을 만들고 싶습니다.

나는 이것의 차이점을 알 수 없습니다 :

openssl genrsa -out MyPrivateKey 4096
openssl rsa -in MyPrivateKey -pubout -out MyPublicKey

먼저 개인 RSA 키를 생성한 다음 여기에서 공개 키를 파생합니다.

ssh-keygen -b 4096 -t rsa -f MyFancyKey

그러면 'MyFancyKey' 파일에 개인 RSA 키가 생성되고 'MyFancyKey.pub'에 해당 공개 키가 생성됩니다.

개인 키의 구조는 다소 유사해 보이지만 다음으로 생성된 키는 openssl다음으로 시작합니다.
-----BEGIN RSA PRIVATE KEY-----

그리고 그 중 하나는 ssh-keygen다음으로 시작됩니다.
-----BEGIN OPENSSH PRIVATE KEY-----

이 두 종류의 키 사이에 근본적인 차이점이 있습니까?


그런 다음 해당 공개 키에는 다음이 openssl포함됩니다.

-----BEGIN PUBLIC KEY-----
  ...base64 encoded...
-----BEGIN PUBLIC KEY-----

의 내용에는 ssh-keygen한 줄만 포함되어 있습니다.
ssh-rsa XXXXXX...base64 encoded...XXXXX [email protected]

기본적으로 동일한 종류의 데이터이지만 형식이 다른가요? 아니면 정말 호환되지 않는 걸까요?

나는 이 모든 것이 SSH와 관련하여 어떻게 작동하는지 완전히 이해하려고 노력하고 있습니다. 예를 들어 해당 키에 내 사용자 이름, 컴퓨터 이름, 로컬 네트워크 이름이 있는 이유는 일반적으로 SSH에 액세스하는 데 사용되지 않습니까?다른컴퓨터? 내 컴퓨터가 아닌 내 컴퓨터에 내 사용자 이름을 사용합니다.

답변1

개인 키

이 두 종류의 키 사이에 근본적인 차이점이 있습니까?

아니요, 본질적으로 동일한 데이터입니다.

  • BEGIN RSA PRIVATE KEYASN.1 DER 직렬 구조의 Base64 인코딩인 "PKCS#1" 또는 "PEM" 키 형식을 나타냅니다. 이는 RSA 매개변수를 포함하는 기본 ASN.1 시퀀스입니다(N,이자형,,,, 등).

    이 형식은 나중에 S/MIME(따라서 ASN.1 DER 사용)이 된 PEM 이메일 보안 노력에서 비롯되었으며 일반적으로 SSL/TLS 및 기타 일반 RSA에 사용되었습니다.

    오랫동안 이는 OpenSSH의 기본 키 형식이기도 했습니다(OpenSSH는 이미 OpenSSL의 암호화 코드를 사용하고 있으므로 "키 로드" 및 "키 쓰기" 기능도 편리하게 사용할 수 있었습니다). 이는 ssh-keygen -m PEM해당 키를 생성하거나 변환하는 데 사용할 수 있음을 의미합니다 .

  • BEGIN PRIVATE KEY"PKCS#8" 키 형식(암호화되지 않음)을 나타냅니다. 내용은 PEM 형식과 매우 유사하며 동일한 RSA 매개변수가 실제로 RSA 키임을 나타내는 다른 구조 내에 중첩되어 있습니다.

    PKCS#8은 특히 PEM 형식을 보다 현대적으로 대체한다는 의미입니다. PEM에 비해 PKCS#8 형식은 외부 Base64 래퍼에서 "페이로드"(키 알고리즘, 암호화)를 더 명확하게 분리합니다. 이제 모든 메타데이터가 구조 내부에 있으므로 새 키 유형에 대해 업데이트하기가 더 쉽습니다. 새로운 형식은 또한 암호화된 키에 대해 더 나은 암호 및 KDF를 지원합니다.

    OpenSSH는 이 형식도 인식하며(키 로딩을 위한 OpenSSL 사용으로 인해) 최신 버전에서도 이를 생성할 수 있다고 생각합니다.

  • BEGIN OPENSSH PRIVATE KEYOpenSSH에서 OpenSSH용으로 개발한 형식으로, PEM/PKCS 형식과 달리 데이터 구조에 SSHv2 패킷 직렬화를 사용합니다(더 이상 DER 또는 ASN.1이 아님).

    OpenSSH가 이제 이 형식을 사용하는 한 가지 이유는 OpenSSL에 완전히 의존하지 않고 OpenSSL이 해당 키의 로드/저장을 구현할 때까지 기다리지 않고 새로운 키 알고리즘을 추가할 수 있기 때문입니다. 각각의 새로운 알고리즘에 대한 ASN.1 OID 및 구조(그 외에는 SSH와 전혀 관련이 없음)

    예를 들어, OpenSSL이 전체 Ed25519 지원을 얻는 데는 시간이 걸렸습니다. 그 동안 OpenSSH는 OpenSSL의 libcrypto를 실제 수학이나 Ed25519 키 파일 로드/저장에 사용할 수 없었습니다. 이것이 바로 이 형식이 생성되게 된 이유입니다.

    OpenSSH 형식의 또 다른 장점은 암호로 암호화된 키가 암호화 키 파생에 bcrypt를 사용한다는 것입니다. 당시 PEM 형식은 매우 약한(즉, 무차별 공격이 쉬운) KDF로 제한되었으며 PKCS#8조차도 약간 열등한 PKBDF2만 지원합니다.

  • .ppkPuTTY에는 대부분 텍스트 기반인 자체 형식이 있습니다 .

    주장된 장점은 개인 매개변수만 선택적으로 암호화하기 때문에 별도의 .pub 파일이 필요하지 않다는 것입니다. 반면 이전 PKCS 형식과 최신 OpenSSH 형식은 모두 암호화하거나 아무것도 암호화하지 않으므로 .pub 파일이 필요합니다. 잠금을 해제하기 위해 암호를 요청하기 전에 키를 제공할 수 있습니다.

    /usr/bin/puttygen이 모든 형식 간에 변환하는 데 사용할 수 있습니다 .

  • Java 소프트웨어는 기본 "Java 키 저장소" 형식이기 때문에 PKCS#12(PFX) 형식을 사용할 수 있으며 일부 소프트웨어는 SSH.COM 주장 표준 형식을 사용할 수도 있습니다.

또한보십시오:OpenSSH 공개 키 파일 형식?

공개 키

기본적으로 동일한 종류의 데이터이지만 형식이 다른가요?

예, 본질적으로 동일한 데이터입니다.

  • BEGIN PUBLIC KEY내 생각엔 PKCS#8이기도 합니다. 따라서 Base64 내부에는 이를 RSA 키로 식별하는 DER 직렬화된 ASN.1 구조가 있고 그 뒤에 키 매개변수(N,이자형).

  • 한 줄 형식은 부분적으로 OpenSSH에만 해당되지만, 중앙 Base64로 인코딩된 데이터는 SSHv2 프로토콜 자체("on the wire") 내에서 사용되는 것과 정확히 동일한 형식입니다. 짐작할 수 있듯이 인코딩된 데이터는 SSHv2 패킷 직렬화를 사용하지만 여전히 동일한 RSA를 보유합니다.N그리고이자형가치.

또한보십시오:OpenSSH 공개 키 파일 형식?

예를 들어 왜 내 사용자 이름, 내 컴퓨터 이름, 내 로컬 네트워크 이름이 해당 키에 있나요?

댓글이에요긴 파일이 있을 때 이 공개 키를 다른 공개 키와 구별하는 데 도움이 됩니다 authorized_keys.

관련 정보