"Host key verification failed": 의미와 해결 방법

이 오류가 실제로 의미하는 것

"Host key verification failed"(흔히 더 크게 WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! 와 함께 표시됨)는 서버가 클라이언트가 이전 연결에서 기억하던 것과 다른 식별 키를 제시하고 있다는 뜻입니다. 이것은 정확히 중간자 공격처럼 보이기 때문에 SSH는 계속 진행하기를 거부합니다. 그러나 솔직히 말하면, 대부분의 경우 공격이 아닙니다 ── 서버 재설치, IP 재사용, 또는 VM 복원입니다. 올바른 대응은 키가 왜 바뀌었는지 먼저 파악하고, 그런 다음에야 옛 키를 제거하는 것입니다. 반사적으로 삭제하지 마세요.

호스트 키가 바뀌는 이유(무해 vs 의심스러움)

1단계 — 새 키를 대역 외로 검증하기

콘솔/물리적 접근(또는 이미 신뢰할 수 있는 임의의 세션)이 있다면, 서버에서 현재 핑거프린트를 출력하세요:

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

그것을 클라이언트 경고에 표시된 핑거프린트와 비교하세요. 일치하면 → 변경은 진짜이고 무해합니다. 옛 항목 제거로 진행하세요. 일치하지 않고 그 변경을 설명할 수 없다면 → 멈추고, 어떤 자격 증명도 입력하기 전에 조사하세요. (SSH가 이렇게 동작하는 이유는 호스트 키 TOFU 설명을 참조하세요.)

2단계 — 옛 키를 제거하고 재연결하기

데스크톱에서는 known_hosts에서 오래된 항목을 삭제합니다:

ssh-keygen -R hostname-or-ip
# then reconnect and accept the new fingerprint
ssh user@host

모바일 클라이언트에는 편집할 파일이 없습니다 ── 기억된 키는 앱 안에 저장됩니다. TermAI에서는 키가 바뀌면 두 핑거프린트를 모두 보여주는 경고가 표시됩니다. 변경이 정당하다고 확인했으면 새 키를 수락하거나(또는 연결 설정에서 저장된 호스트 키를 지우고) 재연결하세요. 그러면 새 키가 고정되어 OpenSSH와 동일한 TOFU 모델이 됩니다.

이런 번거로움 피하기

• 안정적인 주소. 가정 네트워크에서 "키가 바뀜" 잡음의 대부분은 DHCP가 머신을 IP 사이에서 뒤섞기 때문입니다. Tailscale을 쓰면 각 머신이 하나의 주소를 유지하므로 같은 IP에서 다른 머신에 연결하는 일이 사라지고 키도 "바뀌지" 않게 됩니다.
• 재설치 시 호스트 키를 보존하세요. /etc/ssh/ssh_host_*를 백업하고 재구축 후 복원하면 클라이언트는 아무것도 눈치채지 못합니다.
• 검사를 끄지 마세요. StrictHostKeyChecking no는 SSH가 MITM에 대해 가진 유일한 방어를 꺼버립니다. 대신 원인을 고치세요.

FAQ

"REMOTE HOST IDENTIFICATION HAS CHANGED"는 항상 공격인가요?
아니요 ── 보통은 재설치, 복원한 VM, 또는 그 IP가 이제 다른 머신에 속하기 때문입니다. 하지만 MITM 역시 이렇게 보이므로, 수락하기 전에 새 핑거프린트를 대역 외로 검증하세요.

빠르게 고치려면?
변경이 정당하다고 확인한 뒤: 데스크톱에서는 ssh-keygen -R host, 모바일 클라이언트에서는 저장된 호스트 키를 수락/지운 다음 재연결하세요.

휴대폰은 알려진 호스트 키를 어디에 저장하나요?
SSH 앱 안입니다(known_hosts 파일이 아님). TermAI는 연결마다 키를 고정하고, 하나가 바뀌면 두 핑거프린트를 모두 보여주며 경고합니다.

핵심 요약

• 의미: 서버의 식별 키가 클라이언트가 고정한 것과 다름
• 보통 무해: 재설치, IP 재사용, 복원한 VM ── 하지만 수락 전에 검증할 것
• 검증: 서버에서 ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub를 실행해 핑거프린트를 비교
• 수정: ssh-keygen -R host(데스크톱) / 앱 내에서 새 키 수락(모바일); 검사는 절대 끄지 말 것