OpenSSH 10.5가 릴리스됐어요. SSH는 아마 개발자가 매일 쓰면서도 릴리스 노트는 가장 안 읽는 소프트웨어일 텐데요. 서버에 접속하고, git push를 하고, 배포 스크립트가 도는 그 모든 순간의 밑바닥에 OpenSSH가 있잖아요. 그런데 최근 몇 년간 OpenSSH의 변화에는 꽤 뚜렷한 방향성이 있어서, 이번 릴리스를 계기로 그 흐름을 한번 정리해 보려고 해요. 버전 하나하나의 세부 항목보다 '지금 SSH가 어디로 가고 있는가'를 알아두는 게 실무에는 더 도움이 되거든요.
흐름 1: 양자내성 암호가 기본값이 된 시대
최근 OpenSSH의 가장 큰 방향은 양자내성 암호(Post-Quantum Cryptography)의 기본 적용이에요. 이게 뭐냐면, 미래의 양자컴퓨터가 등장해도 풀 수 없도록 설계된 새로운 암호 알고리즘이에요. 양자컴퓨터는 아직 멀었는데 왜 벌써 하냐고 생각할 수 있는데, 여기엔 'harvest now, decrypt later'라는 무서운 시나리오가 있어요. 공격자가 지금 오가는 암호화된 트래픽을 일단 통째로 저장해 뒀다가, 나중에 양자컴퓨터가 생기면 그때 풀어 보는 거죠. 그러니까 오늘 보낸 데이터가 10년 뒤에 털릴 수 있다는 얘기고, 방어는 지금 시작해야 한다는 결론이 나와요. OpenSSH는 이미 ML-KEM이라는 양자내성 알고리즘과 기존의 X25519를 함께 쓰는 하이브리드 키 교환(mlkem768x25519-sha256)을 기본값으로 채택했어요. 하이브리드로 쓰는 이유도 재밌는데, 새 알고리즘에 혹시 결함이 발견되더라도 기존 알고리즘의 보안 수준은 그대로 유지되도록 이중 안전장치를 건 거예요.
흐름 2: 낡은 것은 예고하고, 그다음 제거한다
두 번째 방향은 낡은 암호 알고리즘의 단계적 퇴출이에요. 10.0 버전에서는 오랫동안 사망 선고를 받아 온 DSA 알고리즘 지원이 완전히 제거됐고, 그 전에도 SHA-1 기반 RSA 서명이나 CBC 모드 같은 약한 방식들이 차례로 기본값에서 빠져 왔어요. OpenSSH의 정책은 일관돼요. 먼저 기본값에서 끄고, 몇 버전에 걸쳐 경고하고, 그다음 코드에서 아예 들어내는 식이죠. 이번 10.5도 이런 흐름의 연장선에 있는 릴리스이니, 구체적인 변경 목록은 공식 릴리스 노트를 꼭 직접 확인해 보시길 권해요. 참고로 버전 표기에서 10.5와 10.5p1이 같이 보일 텐데, p는 portable의 약자예요. OpenSSH는 원래 OpenBSD 프로젝트의 일부라서, 리눅스 등 다른 운영체제용으로 이식한 버전에 p가 붙는 거거든요.
흐름 3: 코드 자체를 쪼개서 방어한다
세 번째는 구조적인 방어예요. 2024년에 regreSSHion이라는 이름이 붙은 심각한 원격 코드 실행 취약점(CVE-2024-6387)이 발견된 이후, OpenSSH는 sshd를 여러 개의 작은 바이너리로 쪼개는 작업을 진행해 왔어요. 접속을 받는 리스너, 세션을 처리하는 부분, 인증을 담당하는 부분을 분리해서, 어느 한 곳이 뚫려도 공격자가 가질 수 있는 권한이 최소화되도록 만드는 거죠. 이건 '취약점을 안 만들면 된다'가 아니라 '취약점이 있어도 피해를 줄인다'는 설계 철학인데, 우리가 서비스 아키텍처를 짤 때도 배울 점이 많은 접근이에요. 권한 분리와 최소 권한 원칙을 20년 넘게 실천해 온 프로젝트가 여전히 더 잘게 쪼갤 방법을 찾고 있다는 것 자체가 인상적이잖아요.
실무자를 위한 체크리스트
그래서 우리는 뭘 하면 될까요? 몇 가지만 챙기면 돼요. 먼저 ssh -V로 지금 쓰는 버전을 확인해 보세요. 배포판 패키지는 업스트림보다 한참 늦는 경우가 많거든요. 지원 알고리즘은 ssh -Q kex, ssh -Q cipher 명령으로 확인할 수 있어요. 특히 조심할 건 구형 장비예요. 오래된 스위치나 임베디드 장비는 최신 클라이언트가 기본으로 켜 주지 않는 낡은 알고리즘만 지원하는 경우가 있어서, 클라이언트를 업그레이드한 뒤 갑자기 접속이 안 될 수 있어요. 그럴 땐 -oKexAlgorithms=+... 같은 옵션으로 해당 접속에만 예외를 허용하는 게 좋고, 전역 설정으로 낡은 알고리즘을 다시 켜는 건 피해야 해요. 서버 쪽에서는 업그레이드 전에 sshd_config에서 deprecated 경고가 뜨는 옵션이 없는지 점검해 두면 좋고요.
SSH는 인프라의 현관문이에요. 현관문 자물쇠가 조용히, 그러나 꾸준히 좋아지고 있다는 건 좋은 소식이지만, 문 주인이 열쇠 관리를 안 하면 소용이 없죠. 여러분 서버의 SSH 설정, 마지막으로 점검한 게 언제인가요? 양자내성 전환 같은 흐름을 팀 차원에서 챙기고 계신지도 궁금하네요.
🔗 출처: Hacker News