SSH 접속 시 "no matching host key type found. Their offer: ssh-rsa" 에러 해결 방법

SSH로 서버에 접속하려는데 갑자기 이런 에러가 발생했다면, 당황스러우실 겁니다. 이전에는 잘 되던 접속이 어느 날 갑자기 안 된다면 더욱 그렇죠. 이 글에서는 이 문제의 원인과 해결 방법을 쉽게 이해할 수 있도록 설명드리겠습니다.

$ ssh user@211.47.xx.xx
Unable to negotiate with 211.47.xx.xx port 22: no matching host key type found. Their offer: ssh-rsa

 

SSH 접속 시 "no matching host key type found. Their offer: ssh-rsa" 에러 해결 방법

 

📋 목차

1. 에러가 발생하는 이유
2. OpenSSH 버전별 변경사항
3. 보안 이슈 이해하기
4. 해결 방법 (OS별)
5. 영구적 해결 vs 임시 해결

---

🔍 에러가 발생하는 이유

간단한 비유로 이해하기

SSH 접속은 마치 은행의 보안 금고를 여는 것과 같습니다. 클라이언트(여러분)와 서버(은행)가 서로를 확인하기 위해 **호스트 키(Host Key)**라는 일종의 디지털 서명을 사용합니다.

ssh-rsa는 오래된 형태의 보안 열쇠입니다. 예전에는 안전했지만, 시간이 지나면서 보안 취약점이 발견되었습니다. 최신 OpenSSH는 더 안전한 열쇠만 사용하도록 정책이 변경되었고, 그 결과 오래된 ssh-rsa를 거부하게 된 것입니다.

기술적 배경

• RSA-SHA1 알고리즘: ssh-rsa는 SHA-1 해시 알고리즘을 사용합니다
• SHA-1의 취약점: 2017년 구글이 SHA-1 충돌 공격에 성공하면서 보안성이 의심받기 시작
• OpenSSH의 결정: 보안 강화를 위해 RSA-SHA1 기반 호스트 키를 기본적으로 비활성화

---

📊 OpenSSH 버전별 변경사항

OpenSSH 버전 변경 내용 시기

7.x 이하	ssh-rsa 정상 지원	~2020년
8.2 (2020.02)	ssh-rsa 사용 시 경고 표시	2020년 2월
8.8 (2021.09)	ssh-rsa 기본 비활성화 🔴	2021년 9월
9.0 이상	더 강력한 보안 정책 적용	2022년 이후

왜 갑자기 에러가 발생했을까?

• 시스템 업데이트로 OpenSSH가 8.8 이상으로 업그레이드됨
• Ubuntu 22.04, Debian 12, Fedora 35 이상 등 최신 배포판은 기본적으로 OpenSSH 8.8+ 탑재
• 서버는 오래되어 ssh-rsa만 제공하지만, 클라이언트가 이를 거부

---

🔐 보안 이슈 이해하기

SSH-RSA가 왜 문제인가?

1. SHA-1 해시 취약점
   • 충돌 공격(Collision Attack) 가능성
   • 이론적으로 위조된 서버로 접속 유도 가능
2. 더 안전한 대안들
   • rsa-sha2-256: RSA 키 + SHA-256 해시
   • rsa-sha2-512: RSA 키 + SHA-512 해시
   • ecdsa-sha2-nistp256: 타원곡선 암호화
   • ssh-ed25519: 최신 표준, 가장 권장됨

실제 위험도는?

실무에서는 즉각적인 위험이 크지 않습니다. 하지만:

• 내부망 서버라도 보안 표준 준수 중요
• 규정 준수(Compliance) 요구사항
• 미래를 대비한 보안 업그레이드 필요

---

💡 해결 방법

🔴 방법 1: 임시 해결 (즉시 접속 필요 시)

Linux / macOS

# 명령어에 옵션 추가
ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa user@211.47.xx.xx

Windows (PowerShell)

ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa user@211.47.xx.xx

장점: 즉시 접속 가능
단점: 매번 긴 명령어 입력 필요, 보안 경고 무시

---

🟢 방법 2: 영구 해결 (권장)

Linux / macOS

Step 1: SSH 설정 파일 편집

# 사용자별 설정
nano ~/.ssh/config

# 또는 시스템 전체 설정 (관리자 권한 필요)
sudo nano /etc/ssh/ssh_config

Step 2: 다음 내용 추가

# 특정 서버만 ssh-rsa 허용
Host 211.47.xx.xx
    HostKeyAlgorithms +ssh-rsa
    PubkeyAcceptedAlgorithms +ssh-rsa

# 또는 모든 서버에 적용 (비권장)
Host *
    HostKeyAlgorithms +ssh-rsa
    PubkeyAcceptedAlgorithms +ssh-rsa

Step 3: 파일 권한 확인

chmod 600 ~/.ssh/config

Windows

방법 A: SSH Config 파일 사용 (Windows 10/11)

위치: C:\Users\사용자명\.ssh\config

# 메모장으로 편집
notepad C:\Users\%USERNAME%\.ssh\config

내용은 Linux와 동일

방법 B: PuTTY 사용 시

1. Connection → SSH → Kex 메뉴
2. "Algorithm selection policy" 수정
3. rsa-sha2-512, rsa-sha2-256, ssh-rsa 순서로 배치

---

⭐ 방법 3: 서버 측 근본 해결 (최선의 방법)

서버 관리 권한이 있다면:

# 서버에서 실행
sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key
sudo ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key

# sshd_config 편집
sudo nano /etc/ssh/sshd_config

# 다음 라인 추가/수정
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256
PubkeyAcceptedAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256

# SSH 서비스 재시작
sudo systemctl restart sshd

---

🎯 영구적 해결 vs 임시 해결

언제 임시 해결을 사용하나?

✅ 긴급하게 서버 접속이 필요한 경우
✅ 서버 관리 권한이 없는 경우
✅ 일회성 작업인 경우

언제 영구 해결을 사용하나?

✅ 자주 접속하는 서버인 경우
✅ 보안 정책을 명확히 관리하고 싶은 경우
✅ 팀원들과 설정을 공유해야 하는 경우

---

🔧 트러블슈팅

여전히 접속이 안 된다면?

1. OpenSSH 버전 확인
2. ssh -V
3. 상세 로그 확인
4. ssh -vvv user@211.47.xx.xx
5. 방화벽 확인
6. telnet 211.47.xx.xx 22
7. known_hosts 초기화
8. ssh-keygen -R 211.47.xx.xx

---

📝 요약 체크리스트

• [ ] OpenSSH 버전이 8.8 이상인지 확인
• [ ] 임시 접속이 필요하면 -o 옵션 사용
• [ ] 정기적으로 접속한다면 ~/.ssh/config 설정
• [ ] 가능하면 서버 측에서 최신 호스트 키 생성
• [ ] 보안 정책과 편의성의 균형 고려

---

🚀 마치며

이 에러는 보안 강화를 위한 불가피한 변화입니다. 귀찮을 수 있지만, 장기적으로는 더 안전한 SSH 환경을 만드는 데 기여합니다.

우선 설명드린 임시 해결 방법으로 급한 불을 끄고, 시간을 내어 서버 관리자와 협의하여 서버 측 호스트 키를 업그레이드하는 것이 가장 좋습니다.

 

---