여기에 설명 된대로 서버에서 공개 / 개인 키 쌍을 생성하고 authorized_keys 목록에 공개 키를 추가 한 후 개인 키를 각 클라이언트에 복사하는 것이 안전합니까 ( http://www.rebol.com/docs/ ssh-auto-login.html ) 각 클라이언트를 영구적으로 제어한다고 가정하십니까? (예 : 동일한 사용자, 많은 컴퓨터).
일반적인 절차는 클라이언트에서 공개 / 개인 키 쌍을 생성 한 다음 여기에 설명 된대로 클라이언트의 공개 키를 서버의 authorized_keys 목록에 추가하는 것입니다 ( http://www.linuxproblem.org/art_9.html ). 이 방법을 사용하면 클라이언트 컴퓨터가 여러 대인 경우 각 컴퓨터를 Authorized_keys 목록에 연결하고 시간이 지남에 따라 유지 관리해야합니다.
답변:
축하합니다. 잘못된 조언이있는 인터넷 자습서를 찾았습니다.
여러 컴퓨터에 단일 키 쌍을 사용하는 문제 는 컴퓨터 중 하나 가 손상된 경우에 발생합니다 . 그런 다음 어디에서나 키 페어를 취소하고 해당 키 페어를 사용하고있는 모든 단일 컴퓨터를 다시 입력해야합니다. 손상된 키로 인한 손상을 제한하려면 항상 시스템 및 사용자마다 고유 한 키 쌍을 사용해야합니다.
이 튜토리얼에서는 서버 에서 키 쌍을 생성 하고 개인 키를 클라이언트에 복사하는 것은 놀랍게도 나쁜 조언 입니다. 이것은 완전히 뒤로입니다. 대신 클라이언트 에서 키 쌍을 생성 하고 공개 키를 서버에 복사해야합니다. 이 작업 ssh-copy-id을 정확하게 수행 하는 도우미 스크립트도 있으며 모든 권한이 올바른지 확인하고 클라이언트가 서버의 호스트 키를 가져옵니다.
예를 들어 자동화 된 스크립트와 같이 사용자의 ID 키를 중앙에서 관리하려는 상황이있을 수 있지만이 경우 실제로는 세 번째 호스트 또는 꼭두각시와 같은 구성 관리 시스템에서 수행해야합니다.
이 튜토리얼에 설명 된 프로토콜의 가장 큰 문제점은 "개인 키를 클라이언트 시스템에 다운로드"하는 방법을 안전한 방법으로 지정하지 않는다는 것입니다 (즉, 도청 방지). 보안 채널이없는 경우 인터넷 (HTTP, FTP, 이메일 등)을 통해 키가 분명하게 전송됩니다. HTTPS를 사용할 수 있지만 실제 인증서가없는 경우 MITM이 키를 스니핑하도록 할 수 있습니다. 당신이 생각하는 방식대로하세요. 클라이언트 컴퓨터에서 키 쌍을 생성하고 공개 키를 서버로 전송 한 다음 파일의 체크섬을 확인하여 전송 중에 수정되지 않았는지 확인하십시오.