CentOS 7에서 SSH 접속 시 Host key verification failed 오류를 해결하는 방법

적용 환경

오류가 발생하는 이유

SSH는 처음 접속한 서버의 호스트 키를 클라이언트의 ~/.ssh/known_hosts에 저장하고, 이후 같은 호스트에 접속할 때 서버가 제시하는 키와 저장된 키를 비교합니다. 두 키가 다르면 서버가 바뀌었거나 통신 경로가 변조되었을 가능성을 구분할 수 없기 때문에 접속을 중단할 수 있습니다.

대표적인 정상 변경 사유는 다음과 같습니다.

• CentOS 7 서버를 재설치하여 SSH 호스트 키가 새로 생성된 경우
• 관리자가 /etc/ssh/ssh_host_*_key를 재생성한 경우
• VPS 또는 서버의 IP 주소가 다른 시스템에 재할당된 경우
• 도메인의 DNS 레코드가 다른 서버를 가리키도록 변경된 경우
• 로드밸런서, 클러스터 또는 VIP 뒤의 여러 서버가 서로 다른 SSH 호스트 키를 사용하는 경우

서버 호스트 키 지문 확인

SSH 접속이 차단된 상태라면 VPS 웹 콘솔, KVM 또는 물리 콘솔처럼 SSH와 별개의 신뢰할 수 있는 경로로 CentOS 7 서버에 접속합니다. 먼저 실제 서버의 공개 호스트 키 파일을 확인합니다.

ls -l /etc/ssh/ssh_host_*_key.pub

각 공개키의 SHA256 지문을 확인하려면 다음 명령을 실행합니다.

for key in /etc/ssh/ssh_host_*_key.pub; do
  ssh-keygen -lf "$key"
done

클라이언트의 SSH 경고에 표시된 키 종류와 지문을 서버 콘솔에서 확인한 값과 비교합니다. 예를 들어 경고가 ECDSA 키를 가리킨다면 아래와 같이 해당 키만 확인할 수도 있습니다.

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

서버 콘솔에서 확인한 지문과 SSH 접속 화면에 표시된 새 지문이 일치하고, 서버 재설치나 키 변경이 정상 작업이었다는 사실까지 확인된 경우에만 기존 클라이언트 키를 갱신합니다.

클라이언트의 known_hosts 확인

SSH를 실행하는 클라이언트에서 현재 저장된 호스트 키를 확인합니다. 아래 예시의 도메인과 IP 주소는 실제 접속 대상으로 변경하십시오.

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

접속 오류 메시지에는 일반적으로 충돌하는 키가 저장된 파일과 행 번호가 함께 표시됩니다. 기본 사용자 키 데이터베이스는 ~/.ssh/known_hosts이며, 시스템 전체 키는 /etc/ssh/ssh_known_hosts에 있을 수 있습니다.

더 자세한 접속 과정을 확인하려면 SSH 디버그 출력을 사용합니다.

ssh -vvv [email protected]

출력에서 어떤 known_hosts 파일을 읽었는지, 어떤 호스트 키 알고리즘을 사용했는지, 어느 키에서 불일치가 발생했는지 확인할 수 있습니다.

기존 호스트 키를 안전하게 제거

새 서버 지문이 정상임을 확인했다면 먼저 현재 known_hosts 파일을 백업합니다.

cp -a ~/.ssh/known_hosts ~/.ssh/known_hosts.backup

도메인으로 접속하는 경우

도메인에 저장된 기존 키를 제거합니다.

ssh-keygen -R server.example.com

IP 주소로 접속하는 경우

IP 주소 자체가 known_hosts에 저장되어 있다면 해당 항목도 제거합니다.

ssh-keygen -R 203.0.113.10

기본 포트가 아닌 SSH 포트를 사용하는 경우

SSH가 22번이 아닌 다른 포트를 사용하면 known_hosts에 [호스트]:포트 형식으로 저장될 수 있습니다. 예를 들어 2222번 포트를 사용한다면 다음과 같이 제거합니다.

ssh-keygen -R '[203.0.113.10]:2222'
ssh-keygen -R '[server.example.com]:2222'

SSH 재접속 및 정상 여부 확인

기존 키를 제거한 뒤 다시 SSH 접속을 시도합니다.

ssh [email protected]

처음 접속하는 서버처럼 새 호스트 키 지문과 확인 질문이 나타날 수 있습니다. 이때 표시된 지문을 앞서 서버 콘솔에서 확인한 지문과 다시 비교한 다음 일치할 때만 승인합니다.

접속에 성공한 뒤 새 키가 저장되었는지 확인합니다.

ssh-keygen -F 203.0.113.10

다시 접속했을 때 호스트 키 경고가 반복되지 않고 정상적으로 인증 단계가 진행되면 known_hosts 갱신이 완료된 것입니다.

자주 발생하는 상황별 점검

StrictHostKeyChecking을 끄는 방법은 왜 권장하지 않나요?

호스트 키 검증은 SSH가 접속 대상 서버의 신원을 확인하는 핵심 보안 기능입니다. 오류를 없애기 위해 StrictHostKeyChecking=no 또는 사용자 호스트 키 파일을 무시하는 설정을 상시 적용하면 서버 위장이나 중간자 공격을 탐지하기 어려워질 수 있습니다. 장애 복구에서는 검증 기능을 끄는 대신 실제 서버의 지문을 확인하고 오래된 키만 갱신하는 방식을 사용하십시오.

원상복구

잘못된 known_hosts 항목을 제거했거나 이전 상태로 되돌려야 한다면 앞서 만든 백업 파일을 확인합니다.

ls -l ~/.ssh/known_hosts ~/.ssh/known_hosts.backup

현재 파일을 별도로 보존한 뒤 백업본을 복원할 수 있습니다.

mv ~/.ssh/known_hosts ~/.ssh/known_hosts.after-change
cp -a ~/.ssh/known_hosts.backup ~/.ssh/known_hosts

복원 후에는 기존 키가 현재 서버 키와 다시 충돌할 수 있으므로, SSH 접속 전에 현재 서버의 호스트 키 지문과 백업된 항목이 실제로 맞는지 확인하십시오.

관련 VISION IDC 기술자료

• SSH key 로그인 방법
• CentOS SSH 포트 변경 방법

자주 묻는 질문

서버를 재설치했다면 known_hosts 키를 바로 삭제해도 되나요?

재설치가 실제로 이루어졌다는 점과 현재 서버가 제시하는 새 호스트 키 지문을 콘솔에서 확인한 뒤 삭제하는 것이 안전합니다. 같은 IP가 다른 서버에 할당된 경우에도 동일한 경고가 발생할 수 있습니다.

known_hosts 파일 전체를 삭제해도 되나요?

권장하지 않습니다. 파일 전체를 삭제하면 지금까지 신뢰한 모든 SSH 서버의 키 기록이 사라집니다. ssh-keygen -R로 문제가 발생한 호스트만 제거하십시오.

IP와 도메인 양쪽 모두 지워야 하나요?

둘 다 사용해 접속한 이력이 있다면 각각 별도 항목이 저장되어 있을 수 있습니다. ssh-keygen -F로 먼저 확인한 뒤 현재 서버와 충돌하는 항목만 제거하면 됩니다.

서버 자체의 SSH 호스트 키를 다시 만들면 해결되나요?

단순히 클라이언트의 이전 기록과 현재 서버 키가 불일치하는 문제라면 서버 키를 다시 생성할 필요가 없습니다. 이유 없이 서버 호스트 키를 재생성하면 기존 모든 클라이언트에서 다시 경고가 발생하므로 원인을 먼저 확인해야 합니다.

공식 참고자료

• Red Hat — Red Hat Enterprise Linux 7 System Administrator's Guide, OpenSSH Client: 서버 호스트 키 지문 확인과 ssh-keygen -R을 이용한 기존 키 제거 절차를 확인했습니다. 공식 문서 (조회일: 2026-09-10)
• OpenBSD / OpenSSH — ssh-keygen(1): -R hostname 및 [hostname]:port 형식의 호스트 키 제거 동작을 확인했습니다. 공식 매뉴얼 (조회일: 2026-09-10)
• OpenBSD / OpenSSH — ssh_config(5): StrictHostKeyChecking의 호스트 키 검증 동작과 기본 사용자 호스트 키 파일을 확인했습니다. 공식 매뉴얼 (조회일: 2026-09-10)
• The CentOS Project — CentOS Linux: CentOS Linux 7의 지원 종료일이 2024년 6월 30일임을 확인했습니다. 공식 안내 (조회일: 2026-09-10)