SSH Host key verification failed 해결

문제

전에 접속했던 호스트에 ssh를 시도했는데, 프롬프트 대신 해시 문자 벽과 거부가 돌아옵니다.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
...
Offending ECDSA key in /home/you/.ssh/known_hosts:12
...
Host key verification failed.

연결이 즉시 멈춥니다. 무엇을 입력해도 통하지 않습니다.

이 오류가 실제로 뜻하는 것

SSH는 당신이 수락한 모든 서버의 공개 키를 ~/.ssh/known_hosts에 기억합니다(시스템 전역 항목은 /etc/ssh/ssh_known_hosts에도 있습니다). 접속할 때마다 다시 검사합니다 — 이 호스트가 제시하는 키가 지난번 저장한 것과 일치하는가? 답이 아니오면, 묻지도 추측하지도 않고 중단합니다.

그 거부는 오작동이 아니라 기능입니다. SSH의 보안 모델 전체가 *최초 신뢰(trust on first use)*입니다. 호스트를 한 번 검증하면 SSH가 그 키를 고정하고, 이후 키가 바뀌면 감지합니다. 바뀐 키의 설명은 딱 둘뿐이고, SSH는 제자리에서 둘을 구분하지 못합니다.

1. 서버가 정당하게 새 키를 갖게 됐다.
2. 무언가가 자기 키로 서버를 사칭하고 있다 — 중간자(man-in-the-middle).

1번은 흔하고 지루합니다. 2번은 드물고 심각합니다. 경고가 요란한 건 2번의 가능성이 높아서가 아니라 2번의 대가가 크기 때문입니다. 당신 할 일은 실제로 어느 쪽인지 가려내는 것입니다.

다음 행동을 가르는 갈림길

known_hosts를 건드리기 전에 한 가지만 답하세요. 이 호스트의 키가 바뀌었을 만한 이유가 있는가?

• 있다면 — 당신이나 팀이 방금 OS를 재설치, VM 재생성, 클라우드 인스턴스 재활용, 컨테이너 재배포를 했거나, 호스트명이 로드밸런서 뒤 여러 머신 풀을 가리켜 다른 노드에 닿았거나 — 새 키는 정확히 예상되는 결과입니다. 무해한 다수입니다. 새 지문을 확인(아래)한 뒤 옛 항목을 지우세요.
• 없다면 — 당신 쪽은 아무것도 안 바뀌었고, 안정적이어야 할 서버가 갑자기 다른 키를 갖고 있다면 — 속도를 늦추세요. 그게 의심할 만한 패턴입니다. 경고를 없애려고 지우지 말고, 먼저 독립 경로로 키를 검증하고, 안 되면 접속하지 마세요.

거의 모두가 저지르는 실수는 모든 경우를 “있다면”으로 취급하고 반사적으로 ssh-keygen -R을 치는 것입니다. 그러면 안 되는 그 한 번 전까지는 잘 작동합니다 — 그리고 증거를 지우고 응답한 쪽을 신뢰해버린 뒤에는 그때가 그때였는지 알 방법이 없습니다.

지우기 전에 검증하라

두 경우 모두 옳은 수순은 같습니다. 의심스러운 그 연결을 타지 않는 어딘가에서 호스트의 진짜 지문을 구해 대조하세요.

• 클라우드 서버: 업체 웹 콘솔이나 인스턴스 첫 부팅 로그에 거의 항상 SSH 호스트 키 지문이 찍힙니다. 클라이언트가 지금 보여주는 것과 대조하세요.
• 직접 관리하는 서버: 다른 경로(콘솔, 대역외 관리)로 들어가 로컬에서 키를 읽으세요 — ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub. 그게 정답지입니다.
• 독립 경로가 아예 없다면: 변경을 안전하게 검증할 수 없고, “그냥 지우지 뭐”가 바로 이 경고가 당신이 무심코 내리지 못하게 막으려는 결정입니다.

최신 OpenSSH는 기본으로 SHA256 지문(SHA256:…)을 보여줍니다. 기록이 옛 MD5 16진 형식이라면 ssh-keygen -E md5 -lf로 맞는 형식을 출력하세요.

가장 흔한 원인 3가지

1. 서버가 재구축됐거나 IP가 재할당됐다. OS 재설치, VM 재생성, 컨테이너 재생성, 또는 클라우드 업체가 당신의 옛 IP를 남의 새 인스턴스에 넘긴 경우 전부 정당한 새 호스트 키를 만듭니다. 단연 가장 흔한 원인이고, 사람들이 옳게 예상하는 것 — 그래도 검증은 해야 합니다.
2. 이름 하나에 머신 여럿. 로드밸런싱·라운드로빈 풀로 해석되는 호스트명은 지난번과 다른 백엔드에 당신을 붙일 수 있고, 각 백엔드는 자기 호스트 키를 가집니다. 어느 노드에 닿느냐에 따라 “변경”이 왔다 갔다 합니다. 해법은 키를 반복해 지우는 게 아니라, 모든 노드가 키를 공유하게 하거나 맞는 키를 고정하는 것입니다.
3. 키 타입 변경, 또는 첫 접속 엄격 검사 실패. 저장한 것과 다른 키 타입을 SSH가 이제 협상하거나(예: 서버가 Ed25519를 추가했는데 RSA를 고정해둔 경우), 스크립트·CI에서 StrictHostKeyChecking=yes로 처음 접속하면, 진짜 불일치 없이도 검증 실패가 날 수 있습니다. 단서는 “IDENTIFICATION HAS CHANGED” 배너의 부재입니다 — 그 배너는 진짜 충돌일 때만 뜹니다.

DechoNet으로 진단

• IP 진단 — 호스트명 뒤의 IP를 조회해 지금 무엇과 엮여 있는지 보세요. 클라우드 업체가 IP를 재할당했거나, 예상과 다른 네트워크·소유자로 매핑된다면, 그것만으로 정당한 키 변경이 설명됩니다 — “변경”이 공격자가 아니라 인프라임을 알려줍니다.
• 역방향 DNS 진단 — 그 IP의 PTR 레코드를 확인하세요. 역방향 이름이 갑자기 다른 호스트·업체에 속한다면, 반대편 머신이 정말 바뀌었다는 강한 방증입니다.
• 포트 진단 — 22번(또는 커스텀 SSH 포트)이 실제로 열려 밖에서 응답하는지 확인해, “키가 바뀌었다”와 “내가 생각한 서버에 아예 닿지도 못하고 있다”를 분리하세요.

해결 체크리스트

• 경고를 끝까지 읽으세요. “REMOTE HOST IDENTIFICATION HAS CHANGED”가 있으면 진짜 키 불일치이고, 없으면 변경이 아니라 엄격 검사나 첫 접속 문제입니다.
• 예상 질문을 던지세요 — 이 호스트의 키가 바뀌었을 알려진 이유가 있는가? 재구축, 재배포, IP 재할당, 로드밸런싱 풀?
• 독립 경로(업체 콘솔, 대역외 로그인, 서버에서 직접 ssh-keygen -lf)로 새 지문을 검증하세요. 번거롭다고 건너뛰지 마세요.
• 검증된 뒤에만 낡은 항목을 지우세요: ssh-keygen -R 호스트명. SSH가 정확한 명령·파일·줄 번호를 경고에 찍어줍니다 — 그걸 쓰세요.
• 다시 접속해 물으면 새 키를 수락하세요. 클라이언트가 많다면, 각자 눈감고 재수락하게 두지 말고 고쳐진 키를 배포하세요.
• 키를 검증하지 못했다면 접속하지 마세요. 설명·검증 불가능한 변경은 입증 전까지 잠재적 가로채기로 다루세요.

언제 에스컬레이션하나

• 당신 쪽은 아무것도 안 바뀌었는데 어떤 독립 경로로도 진짜 지문을 일치시킬 수 없다면, 멈추고 중간자 가능성으로 다루세요 — 보고하고, 무엇이든 신뢰하기 전에 다른 네트워크로 그 호스트에 닿아보세요.
• 한 호스트명에서 오류가 켜졌다 꺼졌다 한다면, 거의 확실히 키가 어긋난 다중 호스트 풀에 닿고 있는 것 — 반복 삭제로 덮을 게 아니라 인프라 수정(호스트 키 통일)입니다.
• SSH가 말을 안 들을 때 함께 볼 연결 실패: 서비스에 아예 닿지 못할 때의 ssh: connect to host port 22: Connection refused — 닿았는데 키를 못 믿는 것과는 다른 문제입니다.