서버 관리자가 사용할 개인 키를 보냈습니다. 왜?

회사의 준비 및 라이브 서버를 배포 루프에 연결하기 위해 서버에 액세스해야합니다. 측면의 관리자가 두 인스턴스를 설정 한 다음 서버에 사용자를 만들어 SSH로 연결할 수 있도록했습니다. 이것에 익숙합니다.

내 마음에 지금 일어날 일은 공개 키를 전송하여 승인 된 키 폴더 안에 넣을 수 있다는 것입니다. 그러나 그들은 나에게 파일 id_rsa내부 -----BEGIN RSA PRIVATE KEY-----에 이메일을 포함 하는 파일 이름 을 보냈습니다 . 이것이 정상입니까?

나는 주위를 둘러 보았고 처음부터 자체 키를 생성하고 설정하는 데 많은 양의 리소스를 찾을 수 있었지만 서버의 개인 키 에서 시작 하는 것에 대해서는 아무것도 없습니다 . 나 자신을 위해 키를 생성하기 위해 이것을 사용해야합니까?

나는 시스템 관리자에게 직접 요청하지만 바보처럼 보이고 우리 사이의 모든 사람들을 낭비하고 싶지 않습니다. 그가 보낸 키를 무시하고 공개 키를 승인 된 폴더에 넣도록 요청해야합니까?

내 마음에 지금 일어날 일은 공개 키를 전송하여 승인 된 키 폴더 안에 넣을 수 있다는 것입니다.

지금 무슨 일이 일어나야하는지 "마음 속에"있는 것은 맞습니다.

전자 메일은 안전한 통신 채널이 아니므로 적절한 보안의 관점에서 개인 키가 손상되었음을 고려해야합니다.

기술력과 외교관에 따라 몇 가지 다른 일을 할 수 있습니다. 다음 중 하나를 권장합니다.

1. 자신의 키 페어를 생성하고 공개 키를 자신이 보낸 이메일에 첨부하여 다음과 같이 말합니다.

   감사! 전자 메일은 개인 키를위한 안전한 배포 방법이 아니므로 공개 키를 대신 배치 해 주시겠습니까? 첨부되어 있습니다.

2. 전송 한 개인 키는 전자 메일을 통해 전송 된 후에 손상된 것으로 간주되므로 감사하고 그들 자신의 키 쌍 설치에 반대하는지 물어보십시오.

   고유 한 키 쌍을 생성하고, 보낸 키를 사용하여 처음 로그인 한 다음, 해당 액세스 권한을 사용 authorized_keys하여 새 공개 키를 포함하도록 파일을 편집하십시오 (그리고 손상된 개인 키에 해당하는 공개 키를 제거하십시오).

결론 : 당신은 바보처럼 보이지 않습니다. 그러나 다른 관리자는 바보처럼 보이게 만들 수 있습니다. 좋은 외교는 그것을 피할 수 있습니다.

MontyHarder의 의견에 대한 답변으로 수정 :

내가 제안한 행동 중 어느 것도 "다른 관리자에게 자신이 잘못한 것을 말하지 않고 문제를 해결하는 것"과 관련이 없습니다. 나는 버스에서 그를 던지지 않고 미묘하게 그렇게했습니다.

그러나 나는 것을 추가 할 것이다 또한 미묘한 단서가 포착되지 않은 경우 (공손) 후속 :

안녕하세요, 안전하지 않은 채널 인 이메일에 대한 내 의견에 답변하지 않으 셨습니다. 나는 이것이 다시는 일어나지 않을 것이라고 확신하고 싶다.

개인 키의 안전한 처리에 대해이 점을 지적하는 이유를 알고 있습니까?

베스트,

남자 이름

그가 보낸 키를 무시하고 공개 키를 승인 된 폴더에 넣도록 요청해야합니까?

그렇습니다. 정확히 당신이해야 할 일입니다. 개인 키와 요점들이 있다는 것입니다 개인 이 개인 키가있는 경우에만 의미합니다. 관리자로부터 해당 키를 받았으므로 키도 가지고 있습니다. 그래서 그는 언제든지 당신을 사칭 할 수 있습니다.

보안 채널을 통해 키를 보냈는지 여부는 관련이 없습니다. 개인 키를 직접 받았더라도 아무 것도 변경하지 않습니다. 민감한 암호화 키를 전자 메일로 보내는 것이 핵심이라고 의견에 동의하지만 관리자는 일종의 보안 정책을 가장하지 않습니다.

나에게 그것은 관리자가 당신을 위해 개인 / 공개 키 쌍을 생성하고, 공개 키를 authorized_keys에 추가하고 개인 키를 보내는 것처럼 보입니다. 이렇게하면 서버와의 ssh 세션에이 개인 키만 사용해야합니다. 키 쌍을 직접 생성하거나 관리자에게 공개 키를 손상된 (항상 최악의 경우 : P) 개인 키로 보낼 필요가 없습니다.

그러나 암호화되지 않은 메일을 통해 귀하에게 전송 된 개인 키는 신뢰하지 않습니다.

내 접근 방식은 개인 키를 사용하여 한 번 로그인하고 서버의 authorized_keys에 자신의 공개 키를 추가하고 (원래 공개 키 대체)이 전자 메일 키를 버리는 것입니다. 그런 다음 관리자에게 개인 키를 제공했지만 관리자에게 감사를 표시 할 수 있지만 이러한 정보 / 키를 전자 메일을 통해 보내지 않기를 원할 것입니다.