[태그:] SSH 호스트 키 검증

SSH로 정상 접속하던 리눅스 서버에 다시 연결하려는데 갑자기 WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!라는 경고와 함께 Host Key Verification Failed 오류가 발생한 경험이 있으신가요? 서버를 재설치하거나 클라우드 인스턴스를 교체한 뒤, 또는 동일한 IP 주소에 다른 서버를 연결한 이후에 이런 문제가 발생할 수 있습니다.

서버는 정상적으로 실행 중이고 네트워크 연결에도 문제가 없어 보이는데 SSH 접속만 거부되면 비밀번호나 SSH 포트 설정부터 확인하기 쉽습니다. 하지만 이 오류는 대부분 사용자 계정 인증 이전에 수행되는 서버 신원 확인 과정에서 문제가 발견됐다는 의미입니다.

SSH 클라이언트는 이전에 접속했던 서버의 공개 호스트 키를 known_hosts 파일에 저장하고, 다음 접속에서 서버가 제시하는 키와 비교합니다. 저장된 키와 현재 서버의 키가 다르면 서버가 실제로 교체된 것인지, 설정이 변경된 것인지, 또는 다른 서버로 연결되고 있는지 확인해야 합니다.

이때 인터넷에서 찾은 명령어로 known_hosts를 무조건 삭제하거나 호스트 키 검증 기능을 끄는 것은 안전한 해결 방법이 아닙니다. 이번 글에서는 오류 메시지 확인 → 저장된 호스트 키 조회 → 서버 신원 검증 → 문제가 있는 항목 수정 → SSH 재접속 순서로 해결 방법을 살펴봅니다.

SSH Host Key Verification Failed 핵심 명령어 한눈에 보기

SSH 호스트 키 오류가 발생했다면 아래 명령어로 저장된 키와 연결 상태를 확인할 수 있습니다. 예제의 192.0.2.10은 설명용 IP 주소이므로 실제 서버 주소로 변경해야 합니다.

주의할 점은 ssh-keygen -R 명령어를 실행하기 전에 서버의 호스트 키가 변경된 이유와 새 키의 지문을 신뢰할 수 있는 경로로 확인해야 한다는 것입니다. 저장된 키를 삭제하는 작업 자체가 새 서버의 신원을 보증하지는 않습니다.

1. Host Key Verification Failed 오류가 발생하는 원인

SSH는 암호화된 연결을 만드는 과정에서 접속 대상 서버의 신원을 확인합니다. 이때 사용하는 것이 서버의 SSH Host Key입니다. 사용자의 로그인에 사용하는 SSH 개인 키와는 역할이 다릅니다.

클라이언트는 이전에 신뢰한 서버의 공개 호스트 키를 일반적으로 ~/.ssh/known_hosts에 저장합니다. 이후 동일한 서버 주소로 연결할 때 현재 서버가 제시한 키와 비교합니다.

대표적인 오류 원인은 다음과 같습니다.

• 서버 재설치: 운영체제 재설치 과정에서 SSH 호스트 키가 새로 생성된 경우
• 클라우드 인스턴스 교체: 동일한 IP에 새로운 가상 서버가 연결된 경우
• SSH 호스트 키 교체: 보안 정책이나 관리 작업으로 서버 키가 변경된 경우
• DNS 또는 IP 변경: 기존 서버가 아닌 다른 서버로 연결되는 경우
• known_hosts 문제: 오래된 키, 잘못된 항목 또는 신뢰할 수 없는 키가 저장된 경우
• 보안 위협: 중간자 공격이나 연결 경로 변조 가능성이 있는 경우

특히 중요한 것은 호스트 키 불일치가 반드시 공격을 의미하지는 않지만, 공격 가능성을 배제할 수 있는 오류도 아니라는 점입니다.

따라서 최근 서버 교체 이력이 없는데 갑자기 키가 달라졌다면 기존 항목을 삭제하기 전에 서버 관리자나 클라우드 콘솔 등을 통해 원인을 확인해야 합니다.

2. SSH 오류 메시지에서 확인해야 할 부분

호스트 키가 변경된 서버에 접속하면 다음과 비슷한 경고가 나타날 수 있습니다.

$ ssh user@192.0.2.10

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
The fingerprint for the ED25519 key sent by the remote host is
SHA256:EXAMPLE_FINGERPRINT_NOT_A_REAL_KEY

Offending ED25519 key in /home/user/.ssh/known_hosts:12
Host key verification failed.

위 내용은 설명을 위해 일부를 간략화한 출력 예시입니다. 실제 메시지의 문구와 순서는 OpenSSH 버전 및 설정에 따라 달라질 수 있습니다.

여기서 가장 중요한 정보는 다음 세 가지입니다.

• ED25519: 서버가 제시한 호스트 키의 알고리즘
• SHA256 지문: 현재 연결 대상 서버가 제시한 키의 식별값
• known_hosts:12: 충돌이 감지된 저장 키의 파일 위치와 줄 번호

이 메시지가 나타났다면 SSH 클라이언트가 기존에 저장된 서버 신원과 현재 연결 대상의 신원이 일치하지 않는다고 판단한 것입니다.

이 단계에서 바로 known_hosts 파일 전체를 삭제하기보다 문제가 발생한 호스트와 해당 키를 확인하는 것이 좋습니다.

3. known_hosts 파일에 저장된 서버 키 확인하기

OpenSSH는 사용자가 신뢰한 서버 호스트 키를 일반적으로 ~/.ssh/known_hosts 파일에 저장합니다.

특정 IP 주소에 저장된 항목을 검색하려면 다음 명령어를 사용합니다.

ssh-keygen -F 192.0.2.10

이 명령어는 해시 처리된 호스트 이름이 저장된 경우에도 해당 호스트의 항목을 검색하는 데 사용할 수 있습니다.

SSH 접속에 2222번과 같은 비표준 포트를 사용했다면 호스트와 포트를 함께 지정해야 할 수 있습니다.

ssh-keygen -F '[192.0.2.10]:2222'

기존 항목을 직접 확인하려면 다음 명령어를 사용할 수도 있습니다.

cat ~/.ssh/known_hosts

다만 파일에는 여러 서버의 키가 저장되어 있을 수 있고, 호스트 이름이 해시 처리되어 있다면 내용을 직접 읽어도 어떤 서버인지 구분하기 어렵습니다.

따라서 특정 서버의 키를 확인할 때는 ssh-keygen -F 명령어를 우선 사용하는 것이 편리합니다.

4. 서버의 새로운 호스트 키 지문을 안전하게 확인하기

기존 키를 수정하기 전에 가장 중요한 작업은 현재 접속하려는 서버가 실제로 신뢰할 수 있는 서버인지 확인하는 것입니다.

서버에 클라우드 제공업체의 웹 콘솔, 가상 머신 콘솔 또는 별도의 관리 경로로 접근할 수 있다면 해당 서버에서 직접 호스트 공개 키의 지문을 확인할 수 있습니다.

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

출력되는 SHA256 지문을 SSH 클라이언트가 보여준 지문과 비교합니다. 두 지문이 일치하고 서버 변경 사유도 확인됐다면 새로운 호스트 키를 신뢰할 근거가 됩니다.

단, 서버가 RSA나 ECDSA 등 다른 알고리즘의 호스트 키를 제시했다면 실제 제시된 키와 동일한 알고리즘의 공개 키 지문을 비교해야 합니다.

SSH 연결 자체가 의심되는 상황에서 해당 SSH 연결을 통해서만 새 키를 확인하는 것은 독립적인 신원 검증이 아닙니다. 가능하면 클라우드 콘솔이나 신뢰할 수 있는 서버 관리자 등 별도의 경로를 사용해야 합니다.

5. ssh-keygen -R로 잘못된 호스트 키 항목 수정하기

서버가 정상적으로 재설치되었거나 호스트 키가 정당하게 변경된 사실을 확인했다면 기존에 저장된 키 항목을 제거할 수 있습니다.

먼저 필요하다면 known_hosts 파일을 백업합니다.

cp ~/.ssh/known_hosts ~/.ssh/known_hosts.bak

그다음 해당 서버의 기존 항목만 제거합니다.

ssh-keygen -R 192.0.2.10

비표준 포트를 사용하는 경우에는 다음과 같이 지정합니다.

ssh-keygen -R '[192.0.2.10]:2222'

이 명령어는 지정한 호스트에 해당하는 항목을 known_hosts 파일에서 제거하는 데 사용됩니다.

도메인 이름과 IP 주소를 각각 사용해 접속한 적이 있다면 두 이름에 대한 저장 항목을 별도로 확인해야 할 수 있습니다.

ssh-keygen -F server.example.com
ssh-keygen -F 192.0.2.10

중요한 것은 파일 전체를 삭제하지 않고 문제가 확인된 호스트의 항목만 정리하는 것입니다.

6. SSH 재접속 시 새 호스트 키 등록하기

기존 키 항목을 정리한 뒤에는 SSH 연결을 다시 시도합니다.

ssh user@192.0.2.10

처음 접속하는 서버로 인식되면 다음과 같은 확인 메시지가 나타날 수 있습니다.

The authenticity of host '192.0.2.10' can't be established.
ED25519 key fingerprint is SHA256:EXAMPLE_FINGERPRINT_NOT_A_REAL_KEY

Are you sure you want to continue connecting (yes/no/[fingerprint])?

여기에서 바로 yes를 입력하는 것이 아니라 앞서 신뢰할 수 있는 경로에서 확인한 서버의 호스트 키 지문과 화면에 표시된 지문이 일치하는지 비교해야 합니다.

지문이 일치하고 접속 대상이 올바르다는 사실을 확인했다면 새 키를 등록하고 접속을 계속할 수 있습니다.

반대로 지문이 일치하지 않는다면 연결을 중단하고 DNS, IP 주소, 서버 교체 여부, 네트워크 경로를 다시 확인해야 합니다.

7. StrictHostKeyChecking=no를 사용해도 될까?

SSH 호스트 키 오류를 검색하면 다음과 같은 명령어를 해결 방법으로 소개하는 경우가 있습니다.

ssh -o StrictHostKeyChecking=no user@192.0.2.10

하지만 StrictHostKeyChecking=no는 일부 호스트 키 확인 동작을 완화하는 옵션이며, 기존 호스트 키가 변경된 상황에서도 연결을 무조건 안전하게 만들어주지는 않습니다. OpenSSH 버전과 설정에 따라 연결 제한이나 경고가 남을 수 있습니다.

또한 다음과 같이 호스트 키 저장을 사실상 무력화하는 방식도 운영 서버에서는 피하는 것이 좋습니다.

ssh -o UserKnownHostsFile=/dev/null \
    -o StrictHostKeyChecking=no \
    user@192.0.2.10

이런 설정은 서버 신원 확인을 약화시켜 잘못된 서버에 연결하거나 중간자 공격을 감지하지 못할 위험을 높입니다.

호스트 키 오류를 해결하기 위해 보안 검증 기능을 끄는 것보다 실제 서버의 키를 확인하고 known_hosts 항목을 올바르게 갱신하는 것이 권장되는 방법입니다.

8. known_hosts를 수정했는데 오류가 계속 발생하는 경우

기존 항목을 제거했는데도 같은 오류가 반복된다면 SSH 클라이언트가 다른 설정 파일이나 호스트 이름을 사용하고 있을 가능성을 확인해야 합니다.

먼저 SSH 상세 로그를 확인합니다.

ssh -vvv user@192.0.2.10

현재 적용되는 SSH 설정을 확인하려면 다음 명령어도 사용할 수 있습니다.

ssh -G 192.0.2.10

특히 userknownhostsfile, globalknownhostsfile, hostname, port, hostkeyalias 등의 설정을 확인합니다.

환경에 따라 사용자별 known_hosts 외에 시스템 전역의 호스트 키 파일이 사용될 수도 있습니다.

또한 DNS가 변경됐거나 로드밸런서 뒤의 여러 서버가 서로 다른 호스트 키를 제시한다면 연결할 때마다 키가 달라지는 현상이 발생할 수 있습니다. 이 경우 단순히 키를 반복 삭제하기보다 서버 구성과 접속 경로를 확인해야 합니다.

실전 해결 순서

SSH 접속 시 Host Key Verification Failed 오류가 발생했다면 다음 순서로 확인하는 것이 좋습니다.

# 1. 상세 오류 메시지 확인
ssh -vvv user@192.0.2.10

# 2. 기존에 저장된 서버 키 검색
ssh-keygen -F 192.0.2.10

# 3. 서버 콘솔에서 실제 키 지문 확인
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

# 4. 서버 신원 검증 후 기존 항목 백업
cp ~/.ssh/known_hosts ~/.ssh/known_hosts.bak

# 5. 확인된 기존 호스트 키 항목 제거
ssh-keygen -R 192.0.2.10

# 6. SSH 재접속 및 지문 비교
ssh user@192.0.2.10

3단계는 SSH 클라이언트가 아니라 신뢰할 수 있는 별도의 경로로 접근한 실제 서버에서 실행하는 명령어입니다. 서버 지문을 검증하지 못했다면 5~6단계로 바로 진행하지 않는 것이 안전합니다.

정리

SSH 접속 시 Host Key Verification Failed 오류가 발생했다면 비밀번호나 SSH 포트 문제를 먼저 의심하기보다 서버의 호스트 키 검증 과정에서 무엇이 달라졌는지 확인해야 합니다.

서버 재설치나 인스턴스 교체처럼 정당한 변경이 있었다면 새 호스트 키의 지문을 검증한 뒤 ssh-keygen -R로 기존 항목을 정리하고 다시 연결하면 됩니다.

반대로 서버 변경 이력이 없는데 갑자기 호스트 키가 달라졌다면 known_hosts 파일을 바로 삭제하거나 StrictHostKeyChecking을 끄지 말고 서버 신원과 연결 경로부터 확인하는 것이 중요합니다.

핵심은 오류 메시지 확인 → 기존 키 조회 → 새 키 지문 검증 → known_hosts 수정 → 안전한 재접속 순서를 지키는 것입니다.