SSH 연결의 구조: 세 겹의 역할
SSH-2는 RFC 4251(구조), 4252(인증), 4253(전송 계층), 4254(연결)로 나뉩니다. 전송 계층이 키 교환과 서버 인증, 암호화를 맡고, 그 위에서 사용자 인증이 이뤄지며, 맨 위의 연결 계층이 셸·포트 포워딩 같은 채널을 하나의 암호화 연결에 여러 개 실어 나릅니다. 이 순서 덕분에 사용자 비밀번호나 서명은 이미 암호화된 통로 안에서 오가고, 서버가 진짜인지는 그보다 먼저 호스트 키로 확인됩니다.
인증 방식 비교
| 방식 | 원리 | 주의할 점 |
|---|---|---|
| password | 서버에 비밀번호를 암호화된 채널로 전달 | 반복 대입 시도에 노출되기 쉬움 |
| publickey | 개인키로 서명, 서버가 등록된 공개키로 검증 | 개인키 유출·패스프레이즈 미설정 주의 |
| keyboard-interactive | 서버가 묻는 질문에 응답(일회용 비밀번호 등) | 서버 설정에 따라 동작이 다름 |
| GSSAPI | Kerberos 등 기존 인증 시스템과 연동한 단일 로그인 | 인프라 구성이 필요 |
유닉스 계열에서 허용할 공개키 목록은 흔히 사용자의 ~/.ssh/authorized_keys에 두며, 이 파일이 소유자와 루트 외에 쓰기 가능하면 SSH가 무시하는 경우가 있다고 위키백과는 설명합니다.
호스트 키 검증: "처음 보는 지문"의 의미
처음 접속하는 서버가 보내는 호스트 키 지문을 확인하지 않고 수락하면, 공격자의 서버를 진짜로 믿게 될 수 있습니다. 위키백과도 검증되지 않은 키를 수락하면 공격자를 정당한 상대로 인정하게 된다고 경고합니다. 한 번 수락한 키는 보통 클라이언트 쪽에 기억되고(OpenSSH 클라이언트에서는 known_hosts 파일), 이후 키가 달라지면 경고가 뜹니다. 이 경고는 서버 재설치 같은 정상 사유로도 나올 수 있으므로, 무조건 무시하지도, 무조건 겁내지도 말고 서버 관리자에게 변경 여부를 확인하는 것이 올바른 대응입니다. DNS에 호스트 키 지문을 게시하는 SSHFP 레코드(RFC 4255)도 검증을 돕는 방법으로 정의되어 있습니다.
실제 사례
사례 1. 2024년 xz 백도어(CVE-2024-3094): SSH 자체가 아니라 공급망의 문제
2024년 3월 29일 공개된 이 사건은 압축 라이브러리 XZ Utils의 5.6.0과 5.6.1 버전에 악성 코드가 들어 있던 것으로, CVSS 10.0 위험도로 평가되었습니다. 위키백과에 따르면 마이크로소프트 개발자 안드레스 프로인트(Andres Freund)가 데비안 개발 버전의 성능 저하를 조사하다가 발견했습니다. 일부 리눅스 배포판이 sshd를 systemd와 연동시키는 패치를 적용하고 있어, 악성 버전이 설치된 환경에서 sshd의 동작이 변조될 수 있었습니다. 미국 CISA는 같은 날 경보에서 영향받는 버전을 안내하고 5.4.6 같은 안전한 이전 버전으로 되돌릴 것을 권고했으며, Red Hat·SUSE·데비안 등이 패키지를 되돌렸습니다. 배울 점은 SSH 프로토콜이 뚫린 것이 아니라, SSH 서버가 의존하는 주변 소프트웨어의 공급망이 오염될 수 있다는 점입니다. 프로토콜이 안전해도 배포·의존성 관리와 최신 보안 공지 확인이 별도로 필요합니다.
사례 2. 2023년 Terrapin 공격과 OpenSSH 9.6의 보완 (프로토콜 협상 단계의 약점)
OpenSSH 9.6 릴리스 노트는 Terrapin이라 불리는 공격을 설명합니다. 암호화가 시작되기 직전 단계에서 중간자가 메시지를 끼워 넣고, 암호화가 시작된 직후 같은 수의 메시지를 지워도 양쪽이 알아채지 못하는 문제입니다. OpenSSH 개발진은 영향이 제한적이며, 가장 심각한 효과는 일부 키 입력 타이밍 난독화 기능이 꺼질 수 있는 정도라고 밝혔습니다. 해결책으로는 키 교환 단계에서 예상 밖 메시지를 받으면 연결을 닫고 키 교환이 끝날 때마다 메시지 순서 카운터를 초기화하는 "strict KEX" 확장이 도입되었고, 클라이언트와 서버가 모두 지원할 때 자동으로 켜집니다. 배울 점은 표준 프로토콜도 설계의 틈이 뒤늦게 발견될 수 있고, 양쪽을 모두 업데이트해야 보완이 완성되는 경우가 있다는 점입니다.
사례 3. 가상 예시: 퇴사자의 키 정리
가상 예시입니다. 서버 10대의 authorized_keys에 개발자 B의 공개키가 등록되어 있는데 B가 퇴사했다고 해 봅시다. 계정 비밀번호만 바꾸고 공개키를 지우지 않으면 B의 개인키로는 여전히 로그인 시도가 통과할 수 있습니다. 서버 10대 모두에서 해당 공개키 줄을 제거하고, 비밀번호 로그인은 끄고, 접속 기록에서 마지막 접속을 점검하는 것이 기본 절차입니다. 서버 수가 많아질수록 "누구의 키가 어디에 등록되어 있는지" 목록을 관리하는 일이 보안의 상당 부분이 됩니다.
직접 점검해 보기: 체크리스트
- 개인키에 패스프레이즈를 설정했는지, 개인키 파일을 타인과 공유하거나 저장소에 올리지 않았는지 확인한다.
- 처음 접속하는 서버의 지문은 관리자가 알려 준 값과 대조한 뒤 수락한다.
- 서버에서 공개키 인증만 허용하고 비밀번호 로그인을 끄는 방안을 검토한다.
- 더 이상 쓰지 않는 공개키는 서버의 authorized_keys에서 제거한다.
- 서버의 OpenSSH와 주변 패키지를 배포판 보안 공지에 맞춰 업데이트한다.
흔한 오해와 정정
- 오해: SSH를 쓰면 무조건 안전하다. 실제: 호스트 키 확인을 건너뛰거나 키를 유출하거나 주변 소프트웨어가 오염되면 SSH 자체가 안전해도 사고가 납니다.
- 오해: 공개키 인증은 공개키를 서버에 보내서 비밀번호처럼 확인하는 것이다. 실제: 개인키로 서명하고 서버가 공개키로 검증하며, 개인키는 전송되지 않습니다.
- 오해: 포트만 바꾸면 해킹을 막을 수 있다. 실제: 자동 스캔의 소음을 줄일 뿐 인증 설정이 본질입니다.
- 오해: SFTP와 FTPS는 같은 것이다. 실제: SFTP는 SSH 위에서 동작하고 FTPS는 FTP에 TLS를 입힌 별개 방식입니다.
한계와 더 알아볼 점
SSH는 전송 구간과 인증을 보호하지만, 서버 안에서 일어나는 일(권한 설정, 악성 파일, 내부자 행위)까지 막아 주지는 않습니다. 개인키 관리는 결국 사용자와 조직의 운영 문제입니다. 위키백과는 2023년 HTTP/3 위에서 동작하는 SSH3라는 제안이 소개되었다고 적고 있는데, 아직 일반적인 표준 도구가 아니므로 실무에서는 SSH-2와 OpenSSH를 기준으로 생각하면 됩니다.
HTTPS 연결 원리도 궁금하다면
SSH와 마찬가지로 암호화 키 교환 과정을 거치는 HTTPS의 원리가 궁금하다면TLS 핸드셰이크로 알아보는 HTTPS 연결 원리도 확인해보세요. 이전 세대 원격 접속 방식은 텔넷 프로토콜 가이드에서 비교해 볼 수 있습니다.
파일 전송에 SSH를 활용한다면
SSH 연결 위에서 동작하는 파일 전송 방식이 궁금하다면 FTP와 SFTP 차이 완전정복도 참고해보세요. SSH와 용도가 겹쳐 보이는 기술은 VPN 기초 가이드에서 비교해 볼 수 있습니다.
자주 묻는 질문
SSH 기본 포트(22번)를 바꾸면 더 안전해지나요?
포트를 바꾼다고 근본적인 보안 수준이 올라가는 것은 아니지만, 무작위로 22번 포트를 스캔하며 접속을 시도하는 자동화된 공격 시도를 줄이는 효과는 있습니다. 다만 이는 어디까지나 보조적인 방법이며, 비밀번호 로그인을 막고 공개키 인증만 허용하는 등 근본적인 보안 설정이 훨씬 중요합니다.
SSH와 VPN은 같은 건가요?
아니요, 서로 다른 목적을 가진 기술입니다. SSH는 특정 서버나 서비스에 대한 접속·터널링에 초점이 맞춰져 있는 반면, VPN은 일반적으로 기기의 네트워크 트래픽 전체(또는 대부분)를 암호화된 경로로 라우팅하는 더 넓은 범위의 기술입니다.
xz 사건 때 SSH를 쓰던 사람은 모두 위험했나요?
영향 범위는 XZ Utils 5.6.0·5.6.1이 설치되고 sshd가 해당 라이브러리를 불러오도록 구성된 일부 배포판 환경에 한정되었다고 보고되었습니다. 자신의 환경이 해당되는지는 배포판의 보안 공지와 CISA 경보 등 공식 안내로 확인하세요.
개인키를 잃어버리면 어떻게 되나요?
개인키는 복구할 수 없으므로 새 키 쌍을 만들어 서버에 공개키를 다시 등록해야 합니다. 분실한 키가 유출됐을 가능성이 있다면 서버에서 기존 공개키를 반드시 제거하세요.
호스트 키 경고가 뜨면 어떻게 하나요?
서버 재설치 같은 정상 사유일 수 있지만 중간자 공격의 징후일 수도 있습니다. 서버 관리자에게 변경 사실을 확인하기 전에는 접속을 계속하지 않는 것이 안전합니다.