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)되면 보안이 무력화된다고 지적합니다.

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

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

1994년 2월 3일, CERT는 권고문 CA-94:01 "지속적인 네트워크 모니터링 공격(Ongoing Network Monitoring Attacks)"을 발표했습니다. 이 권고문은 침입자들이 인터넷 전역에 걸쳐 수만 대의 시스템에 대한 접근 정보를 탈취했음을 보고했습니다. 침입자들이 사용한 도구는 네트워크 인터페이스를 무차별 모드(promiscuous mode)로 전환한 뒤, 모든 새로운 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을 수정하지 않고 제거한 이유

제거 작업은 3번의 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)' 방식은 첫 연결의 안전성이 연결된 네트워크의 안전성에 전적으로 의존함을 의미합니다. 이 격차는 메울 수 있습니다. 연결하기 전에 제공자의 콘솔이나 서버 빌드 로그에서 지문(fingerprint)을 확인하십시오. DNS에 SSHFP 레코드(RFC 4255)로 게시할 수도 있으나, 이는 DNSSEC를 사용하는 경우에만 의미가 있습니다. 또는 자체 인증 기관(CA)으로 호스트 키에 서명하여, 클라이언트가 개별 키가 아닌 CA를 신뢰하도록 설정할 수 있습니다. 실제로는 대부분의 사용자가 확인 없이 프롬프트를 수락하며, 이러한 현실을 인정하는 것이 중요합니다.

공개 키가 비밀번호를 대체하게 된 이유

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

두 번째 이유는 산술적인 문제입니다. 공개 주소에서 포트 22를 열어 둔 서버에는 24시간 자동 로그인 시도가 들어오며, 비밀번호는 추측할 수 있는 문자열입니다. 키는 현실적으로 추측할 수 없습니다. PasswordAuthentication no을(를) 설정하면 이 공격 범주 전체가 차단되므로 모든 보안 강화 점검 목록에 포함됩니다. 또한 키가 잘못되었을 때 예전처럼 복구할 수 있었던 대체 수단도 제거됩니다. 따라서 접속이 차단되기 전에 모두 Permission denied (publickey)를 보고하는 여러 오류를 구분하는 방법을 익혀야 합니다. 비밀번호 없이 운영하면 키가 계속 늘어나며, 키를 12개 보유한 agent는 서버가 시도 횟수 제한에 도달해 연결을 끊을 때까지 키를 하나씩 모두 제시합니다. 따라서 올바른 키가 로드되어 있어도 Too many authentication failures 오류로 로그인이 실패할 수 있는 이유가 여기에 있습니다. 키 생성과 교체는 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 collision)을 일으킬 수 있기 때문입니다. 오래된 서버에 접속할 때 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(모듈 격자 기반 키 캡슐화 메커니즘)을 기반으로 하는 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는 이를 전송 계층, 인증 계층, 연결 계층(2006년 1월 RFC 4251~4254)으로 분리했습니다. 또한 무결성 검증에 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 키를 사용하면 이러한 문제를 모두 피할 수 있습니다.