CH-J Server ManagerSSH를 통한 서버 관리
메뉴
모든 가이드와 글 →

SSH 호스트 키 변경: 경고의 의미와 대응 방법

서버가 새 호스트 키를 제시하는 이유를 파악하고, 다른 경로로 검증한 뒤 저장된 항목을 안전하게 교체하세요.

경고가 의미하는 것

서버는 호스트 키로 자신의 신원을 증명합니다. 키가 클라이언트에 이전에 저장된 키와 다르면 OpenSSH는 REMOTE HOST IDENTIFICATION HAS CHANGED를 표시하고 연결을 거부합니다. 클라이언트는 무해한 변경과 공격을 구별할 수 없으므로, 확인을 마칠 때까지 경고가 해결되지 않은 것으로 취급하세요.

흔한 원인

일반적인 원인으로는 서버 재설치, 이미지에서 복원하거나 복제한 가상 머신, 다른 컴퓨터에 재할당된 주소, 서로 다른 노드로 연결을 보내는 로드 밸런서가 있습니다. 공격자가 연결을 가로채도 같은 경고가 나타납니다. 예상하지 못한 변경이라면 작업을 멈추고 비밀번호를 입력하지 마세요.

지문 비교

제공업체 콘솔이나 하이퍼바이저 콘솔처럼 이 SSH 연결에 의존하지 않는 경로로 서버에서 실제 지문을 확인하세요. ssh-keyscan 명령은 네트워크가 제시하는 값만 보여 주므로 그 자체로는 아무것도 증명하지 못합니다. 콘솔에서 확인한 값과 비교하는 용도로만 유용합니다.

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

ssh-keyscan -t ed25519 server.example | ssh-keygen -lf -

기존 항목 교체

지문이 일치하는 것을 확인한 후에만 기존 항목을 제거하고 다시 연결하세요. 비표준 포트는 대괄호를 사용한 별도의 항목으로 기록됩니다. ssh-keygen은 이전 파일을 known_hosts.old로 보관합니다. StrictHostKeyChecking을 끄거나 known_hosts 파일 전체를 삭제하지 마세요. 모든 서버에 대한 보호가 사라집니다.

ssh-keygen -R server.example
ssh-keygen -R '[server.example]:2222'
ssh user@server.example

재설치 후 경고 방지

서버를 재구축하면서 기존 신원을 유지하려면 /etc/ssh의 호스트 키를 안전하게 백업하고 동일한 소유자와 권한으로 복원하세요. 복제본은 반대로 처리해야 합니다. 하나의 이미지에서 만든 각 컴퓨터에는 고유한 호스트 키가 필요합니다. 그렇지 않으면 여러 서버가 하나의 신원을 공유하게 됩니다.

CH-J Server Manager의 호스트 키

앱은 호스트 키의 SHA-256 지문을 OpenSSH의 known_hosts 파일과 별도로 자체 암호화 저장소에 보관합니다. 변경이 발생하면 연결을 차단하고 알려진 지문과 새 지문을 보여 줍니다. 확인해야만 항목이 교체되며 취소하면 아무것도 바뀌지 않습니다. Alpha 0.1.1에서는 각 점프 호스트도 검사하며 키가 변경되면 진행 중인 전송이 중단됩니다. 앱이 새 지문을 대신 검증할 수는 없으므로 다른 경로를 통한 확인은 여전히 사용자가 해야 합니다.

자세한 문서

OpenSSH: ssh →

OpenSSH: ssh-keygen →

생체 인증 잠금 해제 및 보안 →