SSH의 역사: Telnet부터 OpenSSH까지의 발전 과정

SSH 역사의 시작

SSH의 역사는 도난당한 비밀번호와 함께 시작되었습니다. 1995년 이전에는 원격 Unix 장비에 로그인하려면 telnet이나 rlogin을 사용해야 했으며, 두 방식 모두 비밀번호를 네트워크상에 읽을 수 있는 텍스트 형태로 전송했습니다. 네트워크 트래픽을 감시할 수 있는 사람이라면 누구나 비밀번호를 읽을 수 있었고, 1990년대 초반에는 실제로 이러한 일이 대규모로 발생하고 있었습니다.

SSH는 이 문제에 대한 한 개인의 해결책으로, 1995년에 작성되어 무료로 배포되었습니다. 그 이후 프로토콜은 한 차례 재설계되었으며, 오늘날 거의 모든 사람이 사용하는 프로그램은 수차례 파생된 결과물입니다. 아래의 날짜들은 중요한 의미를 갖는데, 각 단계가 특정 보안 실패에 대한 대응이었기 때문입니다.

Telnet과 rlogin이 실제로 전송한 데이터

Telnet은 1983년 5월 Jon Postel과 Joyce Reynolds가 발표한 RFC 854에 정의되어 있습니다. 이 문서는 TCP를 통해 전달되는 터미널 세션을 설명하며, 어떠한 암호화도 포함하지 않습니다. 사용자가 입력하는 모든 바이트는 비밀번호를 포함하여 평문으로 전송되므로, 경로상의 모든 장비가 이를 읽을 수 있습니다.

rlogin은 Berkeley Unix에서 파생되었으며, 이후 RFC 1282(BSD Rlogin, B. Kantor, 1991년 12월)에 기술되었습니다. 이 프로토콜은 읽기 쉬운 비밀번호보다 더 위험한 요소인 '호스트 기반 신뢰(host-based trust)'를 추가했습니다. 서버는 특정 호스트로부터 오는 로그인 요청을 비밀번호 없이 수락하도록 설정될 수 있었습니다. 해당 RFC에는 "주의 사항(A Cautionary Tale)"이라는 섹션이 있는데, 여기에는 "신뢰된 호스트로부터의 비밀번호 인증을 우회하는 것은, 그중 단 하나의 시스템만 침해되어도 설정된 모든 시스템을 위험에 노출한다"라고 명시되어 있습니다. 또한 이 신뢰는 호스트 이름을 기반으로 하므로, DNS(domain name system)가 침해되거나 주소가 스푸핑(spoofing)되면 무력화된다는 점도 지적합니다.

두 설계 모두 해당 프로토콜이 탄생한 당시의 네트워크 환경에는 적합했습니다. 초기 이더넷은 공유 매체였으며, 세그먼트 내의 모든 기기가 모든 프레임을 수신하고 자신에게 오지 않은 프레임은 무시하도록 설계되었습니다. 무차별 모드(promiscuous mode)를 사용하여 이를 무시하지 않는 기기는 다른 모든 사용자의 트래픽을 볼 수 있었습니다. 수천 명의 학생에게 셸 계정을 제공하는 대학 환경에서, 하나의 계정이 침해되면 해당 계정은 학과 전체의 비밀번호를 수집하는 도구가 되었습니다.

수정 사항이 포함되지 않았던 1994년 권고문

1994년 2월 3일, CERT는 CA-94:01 "지속적인 네트워크 모니터링 공격" 권고문을 발표했습니다. 이 보고서에 따르면 침입자들이 인터넷 전역에 걸쳐 수만 대의 시스템에 대한 접근 정보를 탈취했습니다. 공격자들이 사용한 도구는 네트워크 인터페이스를 promiscuous 모드로 전환한 뒤, 모든 새로운 telnet, rlogin, FTP 세션의 시작 부분을 기록했습니다. 바로 이 부분이 사용자 이름과 비밀번호를 포함하고 있습니다.

CERT는 각 사이트에 네트워크로 접근 가능한 모든 계정의 비밀번호를 변경할 것을 권고했습니다. 해당 프로토콜의 특성을 고려하면 함정은 명확합니다. 새로 설정한 비밀번호조차 처음 사용되는 순간 동일한 회선을 통해 평문으로 전송되기 때문입니다. telnet이나 rlogin 프로토콜 내부에는 이를 해결할 수 있는 방법이 없었으며, 두 프로토콜 모두 보안 기능을 추가할 공간 자체가 존재하지 않았습니다.

헬싱키에서의 스니핑 공격이 SSH를 탄생시킨 이유

1995년 헬싱키 공과대학교의 네트워크는 CERT가 경고했던 유형의 패스워드 스니핑 공격을 받았습니다. 당시 연구원이었던 Tatu Ylönen은 이를 대체할 프로그램을 작성하여 1995년 7월 프리웨어로 공개했습니다. 그는 이를 Secure Shell이라고 불렀습니다.

이 프로그램의 성공은 두 가지 설계 결정 덕분이었습니다. 첫째, 세션이 암호화되어 네트워크 세그먼트의 도청자는 아무런 유용한 정보를 얻을 수 없었습니다. 둘째, 서버가 키를 통해 자신의 신원을 증명함으로써 클라이언트는 접속 대상이 올바른 장비인지 확인할 수 있었습니다. 이는 rlogin의 호스트 이름 신뢰 방식이 남겨둔 보안 허점을 해결한 것입니다.

또한 사용자들이 이미 익숙하게 사용하던 명령어와 호환된 점도 확산에 기여했습니다. ssh은 rsh와 rlogin를 대체했고, scp은 rcp을 대체했습니다. 전환 비용은 새로운 워크플로가 아닌 습관의 변화 정도에 불과했습니다. 1995년 말, 사용자 기반은 50개국 약 20,000명에 달했습니다. 그해 12월, Ylönen은 해당 소프트웨어를 개발하고 판매하기 위해 SSH Communications Security를 설립했습니다.

무료 릴리스에서 상용 제품으로

SSH가 비즈니스 모델로 자리 잡으면서 소스 코드 라이선스가 변경되었습니다. 이후 릴리스에는 타인이 해당 코드를 활용하는 범위를 제한하는 조항이 포함되었으며, 누구나 자유롭게 재사용할 수 있었던 마지막 릴리스는 ssh 1.2.12였습니다. 이는 부적절한 일이 아닙니다. 단지 전 세계 개발자가 기반으로 삼을 수 있는 SSH 버전의 발전이 멈추고, 외부에서 따라갈 수 없는 곳에서 개발이 계속되었다는 의미일 뿐입니다. 라이선스는 어떤 코드가 살아남을지를 결정하며, 이러한 패턴은 오픈 소스 라이선스가 현대 인프라를 형성한 방식에서 자세히 읽어볼 가치가 있습니다.

1999년 OpenBSD가 OpenSSH를 포크한 이유

1999년 초 Björn Grönvall은 마지막 무료 릴리스로 돌아가 버그 수정을 시작했습니다. 그의 버전은 OSSH라고 불렸으며, SSH 1.3 프로토콜만 지원했습니다.

OpenBSD 프로젝트는 OSSH를 가져와 재구축했습니다. 프로젝트 자체 기록에 따르면 Theo de Raadt, Niels Provos, Markus Friedl, Bob Beck, Aaron Campbell, Dug Song이 코드 정리, 감사, 확장 작업을 수행했습니다. 그 결과물인 OpenSSH 1.2.2는 1999년 12월 1일 OpenBSD 2.6과 함께 배포되었습니다.

왜 작은 운영체제 프로젝트의 포크가 거의 모든 머신에 탑재되었을까요? OpenBSD가 요구한 기능 때문입니다. OpenBSD는 기본 설정에서 안전하도록 설계된 감사 완료된 기본 시스템을 제공합니다. 따라서 암호화된 원격 로그인은 아무런 제약이 없는 라이선스 하에 기본 시스템에 포함되어야 했습니다. 감사된 코드와 자유로운 라이선스는 다른 모든 운영체제 공급업체가 원하던 것이기도 했습니다. Damien Miller, Philip Hands 등은 거의 즉시 포터블 브랜치를 시작했으며, 10.5p1와 같은 버전의 p이 여기서 유래했습니다. OpenBSD는 깔끔한 버전을 개발하고, 포터블 브랜치는 다른 환경을 위한 접착제 역할을 합니다. Unix가 오늘날 우리가 사용하는 시스템으로 분화된 방식이 바로 이러한 접착제가 필요한 이유입니다.

두 번째 프로토콜 버전에 대한 지원이 뒤따랐습니다. OpenSSH 2.0은 2000년 6월 15일 OpenBSD 2.7과 함께 배포되었습니다.

SSH-2가 버전 업데이트가 아닌 새로운 프로토콜인 이유

SSH-1은 암호화된 스트림의 무결성을 CRC-32로 보호했습니다. 이는 공격자를 방어하기보다는 전송 오류를 잡아내기 위해 설계된 체크섬입니다. 1998년 CORE SDI의 Ariel Futoransky와 Emiliano Kargieman은 이 설계가 어떤 결과를 초래하는지 증명했습니다. CBC 또는 CFB 암호화 모드와 CRC-32 검사를 사용할 때, 평문을 16바이트만 알고 있는 공격자라도 수신자가 정상적인 데이터로 인식하는 암호문을 삽입할 수 있으며, 이는 곧 서버에서 명령을 실행할 수 있음을 의미합니다.

이 결함은 프로토콜 자체에 내재되어 있었기에 호환성을 깨뜨리지 않고는 수정할 수 없었습니다. 구현체들은 대신 deattack.c이라는 파일에 공격을 감지하는 코드를 추가하여 공격이 발생하는 즉시 차단하려 했습니다. 2001년 2월, 이 감지 코드 자체에서 정수 오버플로우 취약점인 CVE-2001-0144가 발견되었고, 이는 해당 패치를 적용한 서버와 클라이언트에 대한 원격 코드 실행으로 이어졌습니다. 수정할 수 없는 설계는 패치를 계속 쌓게 만들고, 그 패치들은 다시 새로운 버그를 불러옵니다.

SSH-2는 IETF의 secsh 워킹 그룹에서 개발되어 2006년 1월 RFC로 발표되었습니다. 아키텍처는 RFC 4251, 전송 계층은 RFC 4253, 사용자 인증은 RFC 4252, 연결 계층은 RFC 4254에 정의되어 있습니다. 계층을 분리한 것이 핵심인데, 각 계층을 독립적으로 교체할 수 있기 때문입니다. 이후의 역사는 대부분 이러한 교체 과정입니다.

두 가지 변화가 두드러집니다. 무결성 검증 방식이 CRC-32에서 공유 비밀키를 사용하는 HMAC(hash-based message authentication code)으로 변경되어, MAC을 계산할 수 없는 공격자는 패킷을 위조할 수 없게 되었습니다. 또한 키 교환 방식은 Diffie-Hellman으로 변경되었습니다. SSH-1에서는 클라이언트가 세션 키를 선택하고 서버의 RSA 키로 암호화하여 전송했기 때문에, 나중에 서버의 개인키를 탈취한 사람은 기록된 세션을 복호화할 수 있었습니다. Diffie-Hellman은 전송되지 않는 새로운 비밀키를 세션마다 생성하므로, 트래픽을 기록해 두었다가 나중에 호스트 키를 훔쳐도 아무것도 얻을 수 없습니다. 이러한 특성을 전방 보안(forward secrecy)이라고 합니다.

SSH-2는 SSH-1과 네트워크상에서 호환되지 않습니다. 이것이 숫자가 소수점 단위가 아닌 정수 단위로 변경된 이유입니다.

SSH-1이 수정되지 않고 제거된 이유

제거 작업은 세 번의 OpenSSH 릴리스에 걸쳐 진행되었습니다. 2015년 8월 11일에 배포된 7.0 버전에서는 컴파일 시점에 프로토콜 1을 기본적으로 비활성화했습니다. 2016년 12월 19일의 7.4 버전에서는 서버 측 지원을 제거했습니다. 2017년 10월 3일의 7.6 버전에서는 클라이언트 측 코드와 관련 설정 옵션 및 문서를 모두 삭제했습니다.

구형 장비를 위해 옵션으로 남겨두는 것이 더 친절한 선택이었을 수 있으나, CRC-32 탐지기는 왜 그러한 선택이 거부되었는지를 설명해 줍니다. 오버플로우는 프로토콜 1 코드가 컴파일되어 포함되었을 때만 발생할 수 있었으며, 이는 대부분의 관리자가 자신의 시스템에서 비활성 상태라고 믿었던 경로에 존재했습니다. 배포된 코드는 공격에 노출될 수 있습니다. 삭제된 코드는 노출될 수 없습니다.

첫 SSH 연결 시 호스트 키 경고가 발생하는 이유

암호화는 통신 내용이 비공개임을 보장하지만, 상대방이 누구인지는 알려주지 않습니다. 공격자가 경로상에 위치하여 서버 대신 응답한다면, 공격자와 완벽하게 암호화된 세션을 맺게 되는데 이를 중간자 공격(machine-in-the-middle attack)이라고 합니다. SSH는 호스트 키를 통해 이에 대응합니다. 서버는 자신이 키 쌍의 개인 키를 보유하고 있음을 증명하고, 클라이언트는 해당 키를 지난번에 기록해 둔 값과 대조합니다. 연결 자체의 메커니즘이 궁금하다면 SSH 연결 시 발생하는 과정을 참조하십시오.

첫 연결 시에는 이전 기록이 없으므로 클라이언트는 비교할 대상이 없으며 사용자에게 다음과 같이 질문해야 합니다.

The authenticity of host 'vps.example.com (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:BQ0Qs2jVXhH2lPZ2rM0aQ0mQ8f9pQ0m3nH0oQ1bYqkE.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

yes라고 응답하면 해당 키가 ~/.ssh/known_hosts에 저장됩니다. 이후의 모든 연결은 저장된 값과 비교하며, 일치하지 않을 경우 프로그램에서 가장 강력한 경고 메시지를 출력합니다.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

첫 번째 프롬프트에 대한 정직한 해석은, 이 프로토콜이 유일하게 취약한 순간을 인정하고 있다는 것입니다. 최초 사용 시 신뢰(Trust on first use)란 첫 연결의 안전성이 오직 연결을 시도하는 네트워크의 안전성에만 의존한다는 뜻입니다. 이 격차를 줄일 수 있는 방법이 있습니다. 연결하기 전에 제공자의 콘솔이나 서버 빌드 로그에서 핑거프린트를 확인하십시오. DNS에 SSHFP 레코드(RFC 4255)로 게시할 수도 있으나, 이는 DNSSEC를 사용하는 경우에만 가치가 있습니다. 또는 자체 인증 기관(CA)으로 호스트 키에 서명하여, 클라이언트가 개별 키가 아닌 CA를 신뢰하도록 설정할 수 있습니다. 실제로는 대부분의 사용자가 확인 없이 프롬프트를 수락하며, 이러한 현실을 인정하는 것이 중요합니다.

공개 키가 비밀번호를 대체하게 된 과정

공개 키 인증은 초기 SSH 릴리스부터 존재했지만, 일반적인 관행으로 자리 잡기까지는 수년이 걸렸습니다. 이 메커니즘은 비대칭적입니다. 클라이언트는 챌린지에 서명함으로써 개인 키를 보유하고 있음을 증명하며, 개인 키는 클라이언트 외부로 절대 유출되지 않습니다. 비밀번호는 이와 반대입니다. SSH가 암호화된 채널 내부에서 비밀번호를 전송하더라도, 서버는 실제 비밀 값을 수신하게 됩니다. 따라서 서버가 침해당하거나 악의적인 서버일 경우, 공격자는 탈취한 비밀번호를 다른 곳에서 재사용할 수 있습니다.

두 번째 이유는 산술적인 차이입니다. 공용 주소에서 22번 포트를 열어둔 모든 서버는 24시간 내내 자동화된 로그인 시도를 받으며, 비밀번호는 추측 가능한 문자열입니다. 반면 키는 현실적으로 추측이 불가능합니다. PasswordAuthentication no를 설정하면 이러한 유형의 공격을 완전히 차단할 수 있으며, 이것이 모든 보안 강화 체크리스트에 해당 항목이 포함되는 이유입니다. 키 생성 및 교체 방법은 SSH 키 관리 기초에서, 서버 측 설정은 VPS에서 SSH 보안 강화하기에서 다룹니다.

SSH 알고리즘 목록이 계속 변경되는 이유

계층화된 프로토콜을 사용하면 새로운 프로토콜을 도입하지 않고도 알고리즘을 퇴출할 수 있습니다. OpenSSH는 이러한 유연성을 꾸준히 활용해 왔으며, 릴리스 날짜를 통해 그 속도를 확인할 수 있습니다.

Ed25519는 2014년 1월 30일 OpenSSH 6.5에서 chacha20-poly1305 암호 및 bcrypt로 보호되는 개인 키 형식과 함께 도입되었습니다. Ed25519 서명은 서명별 난수(nonce)를 결정론적으로 생성하므로, 서명 시점에 난수 생성기가 취약하더라도 개인 키가 유출되지 않습니다. 이는 실제 사고에서 DSA 및 ECDSA 개인 키가 복구되었던 바로 그 방식입니다.

DSA는 반대 방향을 걸었습니다. OpenSSH 7.0은 2015년에 런타임에서 ssh-dss 호스트 및 사용자 키를 비활성화했습니다. 해당 알고리즘은 160비트 개인 키와 SHA-1 사용으로 제한되기 때문입니다. 2024년 7월 1일에 릴리스된 버전 9.8에서는 컴파일 타임에 DSA를 비활성화했습니다. 2025년 4월 9일 버전 10.0에서는 이를 제거하며 프로젝트 측의 표현을 빌리자면 "2015년에 시작된 폐기 과정을 완료"했습니다. 비활성화에서 삭제까지 10년이 걸린 셈입니다.

RSA는 사라지지 않았지만, 구형 서명 형식은 퇴출되었습니다. 2021년 9월 26일 OpenSSH 8.8은 SHA-1을 사용하는 RSA 서명을 기본적으로 수락하지 않게 되었습니다. 릴리스 노트는 그 이유를 명확히 밝히고 있습니다. SHA-1은 암호학적으로 깨졌으며, 50,000달러 미만의 비용으로 선택 접두사 충돌(chosen-prefix collisions)을 일으킬 수 있기 때문입니다. 오래된 서버에 접속할 때 sign_and_send_pubkey: no mutual signature supported를 만난 적이 있다면, 바로 이 변경 사항 때문입니다. 사용자의 키는 문제가 없습니다. 상대방이 요청한 서명 알고리즘이 문제인 것입니다.

현재 키 교환 과정에서도 동일한 절차가 진행 중이며, 이번에는 위협보다 앞서 대응하고 있습니다. 오늘 캡처된 트래픽은 향후 양자 컴퓨터를 보유한 누군가에 의해 저장되었다가 복호화될 수 있으므로, 그러한 기계가 존재하기 전에 키 합의 방식을 변경해야 했습니다. 2022년 4월 8일 OpenSSH 9.0은 하이브리드 키 교환을 기본값으로 설정했습니다. sntrup761x25519-sha512@openssh.com는 양자 내성 알고리즘과 X25519 교환을 결합하므로, 새로운 알고리즘이 기대에 미치지 못하더라도 결과적으로 기존 방식보다 약해지지 않습니다. 2024년 9월 19일 OpenSSH 9.9는 2024년 NIST에서 표준화한 ML-KEM(module lattice key encapsulation mechanism) 기반의 mlkem768x25519-sha256을 추가했습니다. OpenSSH 10.0은 이를 키 합의의 기본값으로 설정했으며, 프로젝트의 양자 내성 페이지에서 그 이유를 설명합니다. 2025년 10월 6일 OpenSSH 10.1은 상대방이 이를 지원하지 않을 경우 경고를 표시하기 시작했습니다.

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded.

이 경고는 기본적으로 활성화되어 있으며 ssh_config의 WarnWeakCrypto 옵션으로 제어됩니다. 이것이 실무적으로 무엇을 의미하며, 해당 경고를 발생시키는 서버를 어떻게 처리해야 하는지는 양자 내성 SSH 키 교환 기본값에서 다룹니다.

현재 서버에 이 역사가 갖는 의미

사용자가 입력하는 명령어는 1995년 이후 거의 변하지 않았습니다. 하지만 그 아래의 거의 모든 요소는 교체되었습니다. 무결성 검사, 키 교환, 서명 알고리즘, 코드 베이스 자체가 바뀌었습니다. 이러한 변화가 가능했던 이유는 각 교체 작업이 의도적인 제거로 마무리되었기 때문이며, 각 제거 과정은 누군가에게는 호환성 문제를 일으켰습니다.

따라서 SSH 보안은 대부분 사용 중인 버전에 의해 결정됩니다. 기본 설정에는 어떤 알고리즘을 제공하고, 어떤 것을 거부하며, 어떤 경고를 표시할지에 대한 결정 사항이 포함되어 있습니다. 오래된 서버는 해당 릴리스가 허용했던 방식을 계속 제공하며, 구형 클라이언트와 통신하기 위해 보안 수준을 낮추는 협상을 계속할 것입니다. 2026년 8월 기준으로 현재 릴리스는 2026년 8월 11일에 발표된 OpenSSH 10.5입니다. 3년 동안 아무도 관리하지 않은 서버의 버전과 최신 버전 사이의 격차가 곧 보안 문제의 크기입니다. 이 버전을 확인하는 작업은 새로운 VPS를 설정하는 첫 10분 안에 포함되어야 합니다.

FAQ

SSH는 누가, 왜 만들었습니까?

헬싱키 공과대학교의 연구원이었던 Tatu Ylönen은 1995년 대학 네트워크에서 발생한 패스워드 스니핑 공격을 겪은 뒤 SSH를 개발했습니다. 당시 사용하던 원격 로그인 도구인 telnet과 rlogin은 패스워드를 평문으로 전송했기 때문에, 공유 네트워크 세그먼트를 모니터링하던 누구나 자격 증명을 탈취할 수 있었습니다. 그는 1995년 7월 이 프로그램을 프리웨어로 공개했습니다. 그해 말에는 50개국에서 약 20,000명의 사용자가 확보되었고, 1995년 12월 그는 SSH Communications Security를 설립했습니다.

SSH-1과 SSH-2의 차이점은 무엇입니까?

두 프로토콜은 서로 호환되지 않는 별개의 프로토콜입니다. SSH-1은 무결성 검증을 위해 CRC-32를 사용하고 클라이언트가 서버의 RSA 키로 암호화된 세션 키를 전송하는 단일 모놀리식 프로토콜이었습니다. SSH-2는 작업을 전송 계층, 인증 계층, 연결 계층으로 분리하며(RFC 4251~4254, 2006년 1월), 무결성을 위해 HMAC을 사용하고 Diffie-Hellman 방식으로 세션 키를 생성합니다. 따라서 나중에 호스트 키가 탈취되더라도 이미 기록된 트래픽은 비공개로 유지됩니다. SSH-1은 단계적으로 OpenSSH에서 제거되었으며, 2017년 10월 버전 7.6을 끝으로 완전히 사라졌습니다.

왜 OpenSSH가 기존 SSH 구현을 대체했습니까?

기존 SSH 개발이 제한적인 라이선스를 가진 상용 제품으로 전환되면서, 자유롭게 재사용 가능한 마지막 릴리스는 ssh 1.2.12에 머물렀습니다. 1999년 초 Björn Grönvall이 해당 릴리스를 OSSH로 부활시켰고, OpenBSD 팀은 이를 포크하여 OpenSSH를 만들었습니다. OpenSSH는 1999년 12월 1일 OpenBSD 2.6과 함께 배포되었습니다. OpenBSD는 기본 시스템을 위해 제한 없는 라이선스를 가진 검증된 코드가 필요했으며, 이러한 특성 덕분에 다른 모든 운영 체제도 포터블 브랜치를 통해 동일한 구현을 탑재할 수 있게 되었습니다.

처음 연결할 때 SSH가 왜 호스트 키를 묻습니까?

클라이언트가 해당 서버를 이전에 본 적이 없어 비교할 키 정보가 없기 때문입니다. 암호화만으로는 정직한 서버와 경로 중간에 위치한 공격자를 구분할 수 없으므로, SSH는 키를 통해 서버를 식별하고 확인된 내용을 ~/.ssh/known_hosts에 기록합니다. 첫 연결은 대조할 저장된 값이 없는 유일한 순간이기에 클라이언트가 사용자에게 직접 확인을 요청하는 것입니다. 제공자의 콘솔이나 서버 자체에서 얻은 지문(fingerprint)과 대조하십시오. 이후 발생하는 REMOTE HOST IDENTIFICATION HAS CHANGED 메시지는 원인을 파악할 때까지 실제 보안 위협으로 간주해야 합니다.

업그레이드 후 왜 이전 SSH 키가 작동하지 않습니까?

OpenSSH는 정해진 일정에 따라 오래된 알고리즘을 퇴출하기 때문입니다. DSA(ssh-dss) 키는 2015년 OpenSSH 7.0에서 기본적으로 비활성화되었고, 2025년 4월 9일 OpenSSH 10.0에서 완전히 제거되었습니다. RSA 키는 여전히 작동하지만, SHA-1을 사용하는 서명은 2021년 9월 OpenSSH 8.8에서 기본적으로 비활성화되었습니다. 이 경우 오래된 서버에 접속할 때 sign_and_send_pubkey: no mutual signature supported 오류가 발생합니다. 2014년 1월 OpenSSH 6.5부터 사용 가능한 Ed25519 키를 사용하면 이러한 문제를 모두 피할 수 있습니다.