SSH Host Key Verification Failed 트러블슈팅 (연재 1/3)

학습 주제

• 공부 주제: SSH Host Key Verification Failed 오류 원인과 해결
• 학습 날짜: 2026년 7월 17일

탐구 과정

평소처럼 ssh -p 2224 jcw@chanwook.kr 명령어로 개인 서버에 접속하려는데, 갑자기 화면 가득 경고 메시지가 떴다.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
...
Host key verification failed.

처음 봤을 때는 "혹시 서버가 해킹당한 건가" 싶어서 살짝 당황했다. 메시지에 대문자로 "누군가 나쁜 짓을 하고 있을 수도 있다(NASTY)"는 문구까지 있으니 더 불안했다. 하지만 최근에 서버를 재설치하거나 설정을 건드린 기억이 있어서, 진짜 공격이라기보다는 서버 쪽 키 자체가 바뀐 것 아닐까 하는 생각이 들었다. 이 부분을 확인해보기로 했다.

핵심 학습 내용

이 오류가 뜨는 이유는 SSH의 보안 검증 방식과 관련이 있다.

• SSH로 서버에 처음 접속하면, 클라이언트는 그 서버의 **호스트 키(host key)**를 known_hosts 파일에 저장해둔다.
• 이후 접속할 때마다 서버가 보내는 키와 저장된 키를 비교해서, 같으면 "믿을 수 있는 서버"로 판단하고 연결을 진행한다.
• 그런데 서버가 재설치되거나 SSH 설정이 초기화되면 새로운 호스트 키가 생성된다. 이때 클라이언트에 저장된 옛날 키와 서버가 보내는 새 키가 달라지니, SSH는 "혹시 중간자 공격(man-in-the-middle)일 수도 있다"고 판단해서 아예 접속을 막아버린다.

즉, 이 경고는 무조건 위험 신호가 아니라 **"서버의 지문이 바뀌었다"**는 사실을 알려주는 안전장치인 셈이다. 문제는 서버가 실제로 바뀐 게 맞는지 아닌지를 사용자가 판단해야 한다는 점이다.

해결 방법은 두 가지로 정리할 수 있었다.

1. 명령어로 옛날 키 삭제

ssh-keygen -R [chanwook.kr]:2224

-R 옵션은 known_hosts에서 해당 호스트에 대한 기록을 찾아서 지워주는 역할을 한다. 포트가 기본값(22)이 아닌 경우 [호스트]:포트 형식으로 지정해야 한다는 점이 특이했다.

2. 파일을 직접 열어서 수동으로 삭제

명령어가 안 먹힐 경우를 대비해, known_hosts 파일을 직접 열어서 지우는 방법도 있었다.

C:\Users\JCU\.ssh\known_hosts

이 파일을 메모장으로 열고, 에러 메시지에 나온 줄 번호(내 경우엔 23번째 줄)를 찾아 해당 줄만 통째로 삭제하면 된다. 에러 메시지에 이미 known_hosts:23처럼 줄 번호가 친절하게 찍혀 나온다는 걸 이번에 처음 알았다.

옛날 키를 지운 후 다시 접속하면, SSH가 "이 서버를 정말 신뢰하겠냐"고 한 번 더 물어보고, yes를 입력하면 새 키가 저장되면서 정상적으로 로그인이 된다.

이해한 내용

• known_hosts 파일은 일종의 "내가 접속해본 서버들의 신원 기록부"라는 걸 이해했다. 서버 하나당 한 줄씩 기록되고, 그 줄에 호스트명(또는 IP+포트)과 공개키 지문이 저장돼 있다.
• 이 경고는 보안 사고를 막기 위한 정상적인 방어 로직이지, 무조건 나쁜 상황을 의미하는 게 아니다. 다만 "정말 서버가 바뀐 게 맞는지"를 확인하지 않고 무조건 키를 지워버리는 습관은 위험할 수 있다는 점도 함께 인지하게 됐다. 만약 서버를 건드린 기억이 없는데 이 경고가 뜬다면, 그건 진짜 조사해봐야 할 신호다.
• ssh-keygen -R이 단순히 키를 삭제하는 명령이라는 것도 새로 알았다. 지금까지는 오류가 나면 파일을 직접 열어서 지우는 것만 알고 있었는데, 명령어 한 줄로 처리할 수 있다는 걸 배웠다.

실전 적용

• 앞으로 서버를 재설치하거나 SSH 데몬을 새로 설정할 때마다 이 오류가 반복될 텐데, 그때마다 파일을 뒤지지 않고 ssh-keygen -R 명령어로 빠르게 해결할 수 있게 됐다.
• 개인 서버뿐 아니라 클라우드 인스턴스(EC2 등)를 재생성했을 때도 똑같은 문제가 생기는 걸 본 적이 있어서, 같은 원리로 대응하면 될 것 같다.
• 다음엔 이 상황이 왜 생겼는지도 한 번 짚어보고 싶다. 서버를 진짜 재설치했는지, 아니면 SSH 설정 파일(sshd_config)만 건드린 건지 로그를 확인해보는 습관을 들여야겠다.

추가 학습 계획

• known_hosts 파일의 각 줄이 실제로 어떤 형식(호스트, 키 타입, 공개키)으로 구성돼 있는지 자세히 뜯어보고 싶다.
• SSH 호스트 키가 애초에 어떻게 생성되고, 서버 관리자로서 이 키를 안전하게 백업/이전하는 방법이 있는지 알아볼 예정이다.
• StrictHostKeyChecking 옵션을 조정해서 특정 상황에서 경고를 다르게 처리하는 방법도 다음에 살펴볼 주제로 남겨둔다.