클라이언트와 서버에서 SSH 키를 생성하는 것의 장단점

클라이언트와 서버에서 SSH 키를 생성하는 것의 장단점

다른 사용자가 내 ec2 인스턴스에 SSH로 접속할 수 있도록 하려면 ec2 인스턴스에서 해당 사용자에 대한 SSH 키를 생성한 다음 해당 사용자의 로컬 시스템에 프라이빗 키를 복사하고 새 인스턴스에 대한 SSH 키를 로컬 시스템에 생성합니다. 사용자를 선택하고 공개 키를 ec2 인스턴스 인증 키에 복사하시겠습니까?

개인 키가 아닌 공개 키만 복사하면 되므로 사용자가 로컬 컴퓨터에서 SSH 키를 생성했다면 더 안전할까요?

답변1

두 접근 방식의 장점을 설명하기 전에 이러한 종류의 업계 표준은 서버가 아닌 클라이언트 시스템에서 키 쌍을 생성하는 것이며, 그 이유는 주로 이것이 더 나은 사용자 경험을 제공하기 때문이라는 점을 지적하겠습니다.

이제 장단점에 관한 한 그들은 서로를 거의 보완하므로 각 방법의 장점만 나열하겠습니다.

클라이언트 측에서 키를 생성합니다.

  • SSH와의 직접적이고 간단한 통합. SSH 자체를 사용하여 키를 생성하고 이것이 유일한 키인 경우 기본적으로 올바른 위치에 자동으로 표시되므로 기술적인 지식이 없는 사용자도 작업을 더 쉽게 할 수 있습니다.
  • 이론적으로 클라이언트 시스템에서 키를 생성하는 데 사용되는 엔트로피 품질은 EC2 인스턴스보다 더 나을 수 있습니다(VM은 엔트로피가 매우 낮음).
  • 사용자는 항상 개인 키가 어디에 있는지 정확히 알고 있으며 이는 키의 보안을 확인하는 데 중요합니다.
  • 사용자가 이미 SSH 키(일반적으로 SSH를 많이 사용하는 사람들이 자주 사용하는 키)를 가지고 있는 경우 여러 키 쌍을 관리할 필요(고통스럽습니다) 대신 공개 키만 보낼 수 있습니다.

EC2 인스턴스에서 키를 생성합니다.

  • EC2 인스턴스의 원하는 위치에 키를 복사하는 것은 매우 간단합니다.
  • 클라이언트 시스템의 부하를 줄입니다.
  • 최소 보안 요구 사항을 적용하기가 더 쉽습니다.

공개 키 대신 개인 키를 복사하는 경우 보안에 미치는 영향에 대해 위에서 명시적으로 언급한 내용은 없습니다. 보안에 미치는 영향은 복사에 사용하는 메커니즘이 얼마나 안전한지에 전적으로 달려 있기 때문입니다.

관련 정보