클라이언트(컴퓨터 3)는 공개 키에 액세스할 수 있습니다.

개인 키가 혼동되었을 수 있습니다.문서개인키를 사용하세요.

공개/개인 키 쌍을 생성할 때 대부분의 구현에서는 개인 키와 공개 키가 포함된 개인 키 파일을 생성합니다. 편의를 위해 많은 구현에서는 공개 키를 별도의 파일에 기록하기도 합니다.

~에 따르면RFC 4252 섹션 7공개 키는 인증 중에 클라이언트에서 제공됩니다. 그러므로 고객이 이를 갖고 있어야 합니다.

openssh를 사용하면 ssh-keygen개인 키 파일에서 공개 키를 추출할 수 있습니다.

ssh-keygen -y -f ~/.ssh/id_rsa

---

인증 메커니즘

https://www.rfc-editor.org/rfc/rfc4252#section-7

클라이언트가 로그인을 시도하기 전에가능한허용되는 것이 무엇인지 확인하는 것부터 시작하세요. 이 확인에는 사용 가능한 개인 키와 일치하는 공개 키를 보내는 것이 포함될 수 있으며, 이를 통해 서버는 사용할 공개/개인 키를 나타낼 수 있습니다.

...서명 작업에는 비용이 많이 드는 계산이 필요합니다. 불필요한 처리 및 사용자 상호 작용을 피하기 위해 "공개 키" 방법을 사용한 인증이 허용되는지 여부를 쿼리하기 위해 다음 메시지가 제공됩니다.

  byte      SSH_MSG_USERAUTH_REQUEST
  string    user name in ISO-10646 UTF-8 encoding [RFC3629]
  string    service name in US-ASCII
  string    "publickey"
  boolean   FALSE
  string    public key algorithm name
  string    public key blob

그런 다음 로그인을 시도합니다.

실제 인증을 수행하기 위해 클라이언트는
개인 키를 사용하여 생성된 서명을 보낼 수 있습니다. 클라이언트는
먼저 키가
허용되는지 확인하지 않고 서명을 직접 보낼 수 있습니다. 서명은 다음 패킷을 사용하여 전송됩니다.

  byte      SSH_MSG_USERAUTH_REQUEST
  string    user name
  string    service name
  string    "publickey"
  boolean   TRUE
  string    public key algorithm name
  string    public key to be used for authentication
  string    signature

여기에는 공개 키와 개인 키를 사용하여 생성된 서명이 포함됩니다. 공개 키는 "인증된 키"가 많기 때문에 서버 SSH에 유용합니다. 서버는 모든 서명을 테스트할 필요가 없습니다.

일부 유사한 알고리즘과 달리 SSH는 시도 응답을 사용하지 않습니다. 이제 맞다아니요4단계(클라이언트 시작 1회, 서버 챌린지 2회, 클라이언트 서명 3회, 서버 확인 4회)를 사용하여 두 단계를 수행합니다.

1. 고객 서명세션 식별자(즉, 이전에 생성된 해시 값DH 키 교환)
2. 그런 다음 서버는 다음을 확인합니다.
   • 지정된 공개 키가 허용됩니다(사용자의 인증된 키 중).
   • 세션 식별자를 생성하기 위해 지정된 공개 키를 사용하여 서명을 해독합니다.

---

왜 일부 사람들은 이것에 대해 혼란스러워합니까?

공개-개인 키 인증 기술은 클라이언트가 공개 키를 보유할 것을 요구하지 않습니다. 클라이언트는 개인 키를 사용하여 서명만 작성하면 됩니다. 서버는 일치하는 공개 키를 사용하여 서명을 확인하기만 하면 됩니다.

그러나 SSH를 사용하면 클라이언트가 여러 개의 개인 키를 가질 수 있고, 서버는 사용자가 여러 개의 인증된 키를 가질 수 있습니다. 클라이언트에 10개의 키가 있고 서버가 10개의 키를 허용하지만 한 쌍만 일치하는 경우 클라이언트는 10개의 서명을 보내야 하며 서버는 10개의 키에 대해 각 서명을 확인해야 합니다(총 100개 확인). 이는 계산 비용이 많이 듭니다. 이와 대조적으로 SSH는 단일 서명 확인만으로 동일한 상황을 처리합니다.

공개 키는 개인 키가 유효한지 확인하는 데에만 사용됩니다.

로컬 시스템에서 SSH를 통해 개인 키를 인증하면 원격 시스템에서 챌린지를 생성합니다. 그런 다음 로컬 컴퓨터는 개인 키를 사용하여 이를 암호화하고 챌린지를 다시 보냅니다. 그러면 서버는 공개 키를 사용하여 메시지를 해독하고 챌린지가 유효한 한 연결을 허용합니다.
개인 키를 절대 공유해서는 안 됩니다.