%20%EC%9C%A0%EC%A7%80%ED%95%A0%20%EC%88%98%20%EC%9E%88%EB%82%98%EC%9A%94%3F.png)
이것을 하지 말라는 말을 듣지 않도록 이것을 미리 밝히십시오.
- 문제의 컴퓨터는 모두 인터넷 액세스가 거의 또는 전혀 없는 로컬 네트워크에 있습니다(회사 네트워크에 제대로 연결되어 있지도 않습니다).
- 중간자 공격을 설정할 수 있는 능력이 있는 모든 사람은 이미 해당 시스템에 루트를 갖고 있습니다.
- 머신은 QA 절차의 일부로 다시 설치되므로 새 호스트 키를 갖는 것이 중요합니다(다른 머신이 어떻게 반응하는지 확인해야 합니다). 나는 단지 내 기계를 더 사용하기 좋게 만들려고 노력할 뿐입니다.
호스트 키를 변경하는 컴퓨터에 재설치를 많이 수행합니다. 이를 위해서는 내 컴퓨터에 들어가서 ~/.ssh/known_hosts
이전 키를 날려버리고 새 키를 추가해야 합니다. 이것은 골치 아픈 문제이므로 이를 자동화하는 방법을 고려하기 시작했습니다.
나는 호스트 키를 맹목적으로 받아들이고 싶지 않으므로 호스트 키를 무시하도록 OpenSSH를 패치하는 것은 중단되었습니다. 나는 ssh
돌아오는 오류를 감지 ssh
하고 이전 키를 삭제하거나 종료하라는 메시지를 표시하는 명령 주위에 래퍼를 만드는 것을 고려했습니다 . 또한 화이트리스트에 있는 시스템(지속적으로 재설치되는 약 20개의 시스템이 있음)에서 최신 호스트 키를 가져오고 known_hosts
.
이 프로세스를 어떻게 자동화하시겠습니까?
답변1
재설치/IP가 동일하게 유지되는 이유에 따라 특정 호스트/IP/패턴에 대해 ~/.ssh/config에서 "StrictHostKeyChecking"을 설정하는 방법을 살펴보겠습니다.
이것이 가능하지 않다면 재설치 프로세스에서 호스트의 키 로드를 자동화하는 방법을 살펴보십시오.
답변2
/etc/ssh/ssh_known_hosts
Puppet과 같은 구성 관리 시스템을 사용하는 경우 클라이언트 시스템이 중앙 서버에 체크인할 때 이를 사용하여 호스트로 파일을 업데이트된 상태로 유지할 수 있습니다 . 그런 다음 StrictHostKeyChecking
구성 파일에서 옵션을 활성화할 수 있습니다 .
이것이 바로 Puppet 마스터 서버에 체크인하는 Amazon EC2 인스턴스로 수행하는 작업입니다. 우리는 Puppet 서버를 EC2 인스턴스에 대한 요새 점프박스 역할을 하며 SSH로 연결할 수 있는 유일한 시스템입니다. 그런 다음 /etc/ssh/ssh_known_hosts
호스트 키와 /etc/hosts
EC2의 퍼블릭 DNS IP 주소를 업데이트하는 파일로 파일을 업데이트된 상태로 유지합니다.
답변3
ssh-keyscan
당신은 openssh와 함께 배포되는 를 원합니다 . 로부터매뉴얼 페이지:
ssh-keyscan is a utility for gathering the public ssh host keys of a num‐
ber of hosts. It was designed to aid in building and verifying
ssh_known_hosts files.
재설치의 일부로 최신 키 목록이 있는 머신을 확보하고 이를 실행한 다음 업데이트된 Known_hosts 파일을 나머지 머신에 배포하십시오.
또는 다른 사람들이 언급했듯이 StrictHostKeyChecking을 끌 수 있습니다. 이로 인해 중간자 공격이 발생할 수 있지만 사용자 환경에서는 걱정할 필요가 없습니다.