SSH Host key verification failed 해결: 지문·포트·known_hosts 확인 순서

Host key verification failed가 나오면 known_hosts를 통째로 지우지 말고, 실제 접속할 호스트·포트와 서버 호스트 키 지문을 신뢰 가능한 별도 경로에서 먼저 확인하세요. 정당한 서버 교체가 확인된 뒤 해당 항목만 갱신합니다. 이 오류는 서버 신원 확인 문제이며 사용자의 개인 키로 로그인하는 Permission denied (publickey)와 해결 순서가 다릅니다. 아래는 OpenSSH를 쓰는 Linux·macOS·CI 환경의 문서 기반 절차입니다.

원인 구분: 새 서버·바뀐 키·잘못된 접속 대상

서버 재설치로 호스트 키가 바뀌었을 수도 있지만 DNS·프록시·포트 설정 때문에 다른 서버에 닿았을 수도 있습니다. 경고는 공격 가능성도 포함하므로 “오래된 캐시”로 단정하지 않습니다. GitHub 공식 오류 설명도 신뢰할 키를 확인할 수 없다면 접속을 멈추고 관리자에게 확인하도록 안내합니다. 확인창에 나타난 새 지문만 보고 같은 연결에서 신원을 확정하지 마세요.

관찰한 증상	먼저 확인할 것	피할 처리
처음 접속하는 호스트	공식 공개 키·관리자 지문과 대상 주소	확인 없이 자동 신뢰
REMOTE HOST IDENTIFICATION HAS CHANGED	변경 이력·DNS·포트·공식 지문	known_hosts 전체 삭제
CI에서만 실패	실행 사용자·HOME·실제 known_hosts 경로	개인 노트북 설정만 수정
Permission denied (publickey)	사용자 계정·개인 키·authorized_keys	호스트 키를 계속 삭제

1. 현재 접속 설정과 해당 항목을 읽는다

같은 별칭이라도 HostName, Port, ProxyJump, HostKeyAlias 등에 따라 검사 대상이 달라질 수 있습니다. 실제 SSH를 실행하는 사용자와 설정 파일을 기준으로 봅니다. 다음 예시의 deploy-example은 직접 관리하는 접속 별칭으로 바꿔야 합니다. ssh -G는 접속하지 않고 평가한 설정을 출력하지만 환경에 따라 주소·사용자 정보가 포함되므로 전체 출력을 공개하지 않습니다. ssh 공식 옵션으로 설치 버전의 지원 여부를 확인하세요.

ssh -V
ssh -G deploy-example

# 기본 포트가 아닌 2222를 쓰는 예시: 읽기만 수행
ssh-keygen -F "[deploy.example.com]:2222" \
  -f "$HOME/.ssh/known_hosts"

이 예시의 도메인과 포트는 설명용이며 실제 서버를 대상으로 실행한 기록이 아닙니다. 유효 설정에 다른 UserKnownHostsFile이나 시스템 파일이 있으면 그 파일을 확인합니다. 해시된 호스트명도 ssh-keygen -F로 찾을 수 있습니다. 항목이 없다는 결과와 키가 바뀌었다는 결과를 같은 원인으로 처리하지 마세요. ssh-keygen의 -F·-f 설명이 검색 기준입니다.

2. 새 지문을 독립된 신뢰 경로와 비교한다

서버 관리자에게 승인된 관리 콘솔 등 별도 경로에서 호스트 공개 키 지문을 확인받습니다. 공개 서비스라면 해당 서비스의 공식 최신 지문과 교체 공지를 확인합니다. 개인 키 파일이 아니라 서버의 호스트 공개 키가 비교 대상입니다. 키 알고리즘과 SHA256 지문을 정확히 맞추고 서버 교체 이력·호스트·포트가 모두 일치할 때만 다음 단계로 갑니다.

ssh-keyscan은 서버가 제시하는 공개 키를 모으는 도구이지 서버가 진짜라는 사실을 보증하는 도구가 아닙니다. CI 시작 때 수집한 키를 검증 없이 신뢰 목록에 넣으면 잘못된 서버도 신뢰할 수 있습니다. 공식 keyscan 주의사항을 기준으로 수집과 지문 검증을 분리합니다. 확인할 근거가 없다면 접속 실패를 유지하고 담당자에게 확인하는 것이 맞습니다.

3. 확인된 변경만 해당 파일·항목에 반영한다

변경이 정당하다는 근거를 확보한 뒤 현재 known_hosts를 승인된 위치에 백업하고, 유효 설정에서 사용하는 정확한 파일의 해당 호스트·포트만 제거·교체합니다. 아래 제거 명령은 읽기 작업이 아니며 조건을 확인한 뒤 실행해야 합니다. 다른 호스트의 신뢰 기록이나 시스템 전체 파일을 함께 지우지 않습니다.

# 정당한 키 교체 확인·파일 백업 후에만 실행하는 예시
ssh-keygen -R "[deploy.example.com]:2222" \
  -f "$HOME/.ssh/known_hosts"

# 별도 경로로 검증한 새 공개 키를 해당 파일에 등록한 뒤
# 기존의 호스트 키 검사 정책을 유지하며 재접속

StrictHostKeyChecking=no 또는 UserKnownHostsFile=/dev/null로 오류를 숨기는 방식은 이 절차의 해결책이 아닙니다. accept-new도 처음 보는 키의 출처를 검증해 주거나 이미 바뀐 키를 자동 승인하는 기능이 아닙니다. OpenSSH 설정 문서에 맞춰 조직의 호스트 검증 정책을 유지하세요. 불일치가 남으면 백업을 보존한 채 주소·포트·설정 경로를 다시 진단합니다.

확인 방법: 같은 실행 사용자와 접속 경로로 재검증한다

호스트·포트·공개 키 알고리즘·검증한 지문·변경 근거와 시각을 기록하고, 실제 배포를 실행하는 동일 사용자·컨테이너·러너에서 확인합니다. 호스트 검증을 통과한 뒤 사용자 인증 오류가 나오면 별도 문제로 분리합니다. 배포를 무조건 재실행하거나 키를 다시 지우는 대신 어느 단계가 바뀌었는지 남겨야 합니다. 지문 확인 성공이 배포 성공을 뜻하지도 않습니다.

CI 컨테이너가 매번 새로 만들어지면 개인 홈의 기록이 지속되지 않을 수 있습니다. 검증한 공개 호스트 키를 승인된 배포 설정으로 공급하고 러너의 경로·권한을 확인하세요. 단순 누락과 실제 키 변경을 구별해 실패 이유를 남깁니다. 공개 키와 known_hosts에도 서버 주소 등의 운영 정보가 들어갈 수 있으므로 로그를 공유할 때 필요한 부분만 남깁니다.

FAQ

서버를 재설치했으니 삭제해도 되나요? 재설치 이력만으로는 충분하지 않습니다. 새 서버의 실제 호스트 키 지문을 별도 신뢰 경로에서 대조한 뒤 해당 항목만 바꿉니다.

ssh-keyscan 출력이 있으면 믿어도 되나요? 수집 성공과 신원 검증은 다릅니다. 공식 지문이나 관리자 확인과 비교해야 합니다.

개인 키를 다시 발급하면 해결되나요? 서버 호스트 키와 사용자 인증 키는 다른 역할입니다. 어느 단계의 오류인지 먼저 확인하세요.

공식 출처와 관련 글

공식 자료 확인일은 2026년 10월 15일입니다. 설정·명령 예시는 문서로 확인했으며 AWS 계정이나 운영 서버에서 직접 실행한 결과가 아닙니다. 실제 적용 전 설치 버전·권한·대상 환경을 확인하세요. 가격과 기능은 확인일 기준으로 설명합니다.

GitHub: Host key verification failed와 신뢰 가능한 키 확인

OpenSSH: StrictHostKeyChecking·UserKnownHostsFile

OpenSSH: 호스트 검색·지문 조회·항목 제거

OpenSSH: 수집한 키의 검증과 중간자 공격 주의

OpenSSH: 유효 설정 확인과 서버 신원 검증

관련 문제를 함께 확인하려면 GitHub Actions SSH publickey 오류와 배포 인증 구분 글을 참고하세요.

직접 생성한 개념 이미지입니다. 실제 서버 지문이나 접속 화면이 아니며 키 수집과 서버 신원 검증을 구분합니다.