SSH: Host key verification failed

안녕하세요, BlueByte입니다. 서버에 ssh로 접속하려는데 — 또는 SSH로 git push하려는데 — 프롬프트 대신 Host key verification failed가, 때로는 원격 신원이 바뀌었다는 해시 경고 아래에 뜹니다. 기기가 망가진 것도, 반드시 공격인 것도 아닙니다. SSH가 제 일을 하는 것뿐입니다 — 서버가 내민 key가 지난번에 기록해 둔 것과 다른 것입니다. 오늘은 이 메시지의 두 형태, key가 더 이상 맞지 않는 이유, 새 key를 믿어도 되는지 확인하는 법, 오래된 항목을 지우는 법, 그리고 재발을 막는 법까지 하나씩 짚어보겠습니다.

둘 다 "Host key verification failed"로 끝나는 두 메시지

두 가지 다른 상황이 이 오류를 냅니다. 첫째는 바뀐 key입니다:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
...
Offending ECDSA key in /home/you/.ssh/known_hosts:12
Host key verification failed.

중요한 줄은 Offending ... key in ~/.ssh/known_hosts:12입니다 — 더 이상 맞지 않는, 기록된 key의 정확한 파일과 줄 번호를 알려줍니다. 둘째는 엄격 검사 상태에서의 첫 접속으로, 스크립트와 CI에서 흔합니다:

No ECDSA host key is known for github.com and you have requested strict checking.
Host key verification failed.

여기엔 충돌이 없습니다 — SSH가 그 호스트 기록이 없을 뿐이고, StrictHostKeyChecking이 스스로 검증할 수 없는 key를 받아들이지 못하게 막는 것입니다.

known_hosts가 막아 주는 것

처음 접속할 때 SSH는 서버의 공개 host key를 ~/.ssh/known_hosts에 저장합니다(최초 신뢰, trust on first use). 이후 접속마다 서버가 내미는 key를 그 기록과 비교합니다. 불일치는 트래픽이 가로채질 때 나타날 바로 그 조건이므로, SSH는 새 key를 조용히 믿는 대신 거부합니다. 그래서 해결책은 "검사를 끄는 것"이 절대 아닙니다 — 새 key가 진짜임을 확인한 뒤 기록하는 것입니다.

key가 더 이상 맞지 않는 이유

대부분은 악의가 아니라 평범한 이유입니다.

• 서버 재구축·재프로비저닝 — OS를 새로 깔면 host key가 새로 생성되어, 같은 이름이나 IP가 이제 다른 key로 응답함.
• IP·호스트명 재사용 — 클라우드 인스턴스가 반납됐다 내게 다시 할당되거나, DHCP가 그 주소를 다른 기기에 줌.
• 제공자의 key 교체 — 예를 들어 GitHub은 2023년에 RSA host key를 교체했고, 옛 key를 캐시해 둔 모두가 이 오류를 만남.
• 생각한 것과 다른 호스트에 닿음 — 이름 앞의 로드밸런서·bastion·jump host.

엄격 검사 형태는 그저 기록한 적 없는 호스트인데, 대화형 "정말 접속할까요?" 프롬프트가 금지된 환경이라는 뜻입니다.

먼저, 문제의 항목을 찾기

파일 전체를 지우지 마세요. ssh-keygen -F로 저장된 key를 정확히 찾습니다:

ssh-keygen -F github.com

known_hosts에서 일치하는 줄을 출력합니다. 오류에 Offending ... :12 줄이 이미 있다면 같은 정보입니다 — ~/.ssh/known_hosts의 12번째 줄입니다.

믿기 전에 새 key를 검증하기

이건 건너뛰면 안 되는 단계입니다. 서버의 현재 지문을 읽어, 서버 자신이 아니라 믿을 수 있는 출처와 대조합니다:

ssh-keyscan github.com | ssh-keygen -lf -

호스트가 지금 내미는 SHA256 지문을 출력합니다. 이를 제공자가 공표한 값과 비교하세요 — 예를 들어 GitHub은 자사 지문(Ed25519 key는 SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU)을 문서에 실어 둡니다. 직접 재구축한 서버라면 그 장비에서 ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub로 지문을 읽으세요. 지문이 맞으면 새 key는 진짜입니다.

오래된 key를 지우고 다시 접속하기

검증했으면 옛 항목을 지우고 SSH가 새 key를 기록하게 둡니다:

ssh-keygen -R github.com

-R은 그 호스트의 모든 key를 known_hosts에서 제거하고 known_hosts.old로 백업을 남깁니다. 다시 접속하면 SSH가 새 key 수락을 묻습니다. 엄격 검사 상황이라면 검증한 key를 직접 추가하세요:

ssh-keyscan github.com >> ~/.ssh/known_hosts

지문을 확인한 key만 덧붙이세요 — ssh-keyscan만으로는 응답하는 무엇이든 그대로 믿습니다.

실제 사례: 같은 IP에 재구축된 서버

10.0.4.20의 스테이징 장비를 다시 이미징했습니다. 다음 ssh deploy@10.0.4.20에서 REMOTE HOST IDENTIFICATION HAS CHANGED 블록이 Offending ED25519 key in ~/.ssh/known_hosts:8과 함께 떴습니다. 재구축을 제가 직접 했기에, 콘솔에서 ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub로 새 지문을 읽고, 노트북에서 ssh-keygen -R 10.0.4.20을 실행하고, 다시 접속해, 내밀어진 지문을 콘솔의 것과 비교한 뒤 수락했습니다. 1분도 안 걸렸고, 검사는 제 할 일을 정확히 했습니다 — 신원이 바뀌었음을 알리고, 그 변경이 제 것임을 확인하게 만든 것이죠.

"Permission denied (publickey)"·"Connection refused"와 어떻게 다른가

Host key verification failed는 서버의 신원에 관한 것으로, 인증 이전에 SSH가 서버가 누구인지 확인할 때 일어납니다. Permission denied (publickey)는 반대 방향입니다: 믿는 서버에는 닿았지만 로그인에 내 key가 받아들여지지 않은 것입니다. Connection refused는 그보다 더 앞입니다 — SSH 포트에서 아무도 응답하지 않아, 확인할 key 자체가 없었던 것입니다. 셋 중 무엇을 받았는지 읽으면 핸드셰이크의 어디를 봐야 할지 알 수 있습니다.