Ubuntu 포스트 양자 SSH 설정 및 확인 방법

포스트 양자 SSH에서 변경된 사항

포스트 양자 SSH는 이미 대부분의 사용자에게 활성화되어 있으며, 별도의 설정이 필요하지 않습니다. 최신 OpenSSH 클라이언트가 최신 OpenSSH 서버와 통신할 때 기본적으로 하이브리드 포스트 양자 키 교환(hybrid post-quantum key exchange)을 선택하므로, 공격자가 오늘 트래픽을 기록해 두었다가 수년 뒤에 복호화하더라도 세션 키를 보호할 수 있습니다. 이 보호 기능은 실질적이지만, "양자 내성 SSH(quantum-safe SSH)"라는 표현이 암시하는 것보다는 좁은 범위에 적용됩니다.

먼저 두 가지 용어를 정의합니다. SSH(secure shell)는 서버에 로그인할 때 사용하는 프로토콜입니다. 보통 "kex"라고 표기하는 키 교환은 모든 SSH 연결의 첫 번째 단계로, 양쪽 끝단이 공유 비밀값을 합의하고 그 비밀값으로 이후의 모든 데이터를 암호화합니다. 변경된 부분은 바로 이 키 교환 단계입니다. 그 외의 다른 부분은 변경되지 않았습니다.

이 페이지를 맹신하지 말고 명령어를 직접 실행하십시오

아래에 나열된 모든 알고리즘 이름은 직접 실행할 수 있는 명령어의 결과물입니다. 이는 의도된 것입니다. 기본값은 OpenSSH가 릴리스될 때마다 변경되므로, 2년 전에 작성된 가이드는 현재 시스템이 선호하지 않는 알고리즘을 언급할 수 있으며, 이를 알려줄 방법도 없습니다. 이 명령어들을 익히면 본 문서를 포함하여 관련 기사에 의존할 필요가 없어집니다.

현재 빌드에서 지원하는 기능부터 확인하십시오.

ssh -V
ssh -Q kex

ssh -V는 OpenSSH_으로 시작하는 버전 정보와 Ubuntu 패키지 접미사, OpenSSL 버전을 출력합니다. ssh -Q kex은 키 교환 알고리즘을 한 줄에 하나씩 출력합니다. 포스트 양자 암호(post-quantum) 지원이 포함된 빌드라면 해당 목록에서 mlkem768x25519-sha256나 sntrup761x25519-sha512@openssh.com과 같은 이름을 발견할 수 있으며, 이는 curve25519-sha256와 같은 고전적인 알고리즘 이름들과 함께 나열됩니다.

빌드가 지원하는 것과 실제 제공하는 것은 다릅니다

대부분의 게시물에서 간과하는 중요한 차이점입니다. ssh -Q kex는 이 바이너리가 무엇을 할 수 있는지에 대한 질문에만 답합니다. 사용자가 실제로 궁금해하는 질문, 즉 이 연결이 실제로 무엇을 제안할 것인가에 대해서는 답하지 않습니다. 이 두 목록은 서로 다르며, 그 차이로 인해 과거의 잘못된 조언이 실제 피해를 입히기도 합니다.

ssh -G example.com | grep -i '^kexalgorithms'
sudo sshd -T | grep -i '^kexalgorithms'

ssh -G <host>은 ~/.ssh/config과 /etc/ssh/ssh_config이 적용된 후 해당 호스트에 대한 클라이언트의 유효 구성을 출력합니다. sshd -T는 서버에 대해 동일한 작업을 수행합니다. 각 명령은 우선순위 순서대로 단일 kexalgorithms 라인을 출력하며, 해당 라인의 첫 번째 이름이 해당 측의 첫 번째 선택입니다. 그 라인이 실제 네트워크를 통해 전송되는 내용입니다.

이 차이는 이론적인 것이 아닙니다. 2021-03-03에 릴리스된 OpenSSH 8.5는 sntrup761x25519-sha512@openssh.com을 추가했지만 기본 목록에서는 의도적으로 제외했습니다. 해당 릴리스에서 ssh -Q kex는 해당 알고리즘을 보여주지만 ssh -G은 그렇지 않습니다. 이는 바이너리가 포스트 양자 키 교환을 수행할 수 있음에도 불구하고, 어떤 연결에서도 이를 요청하지 않는다는 것을 의미합니다.

연결이 협상한 알고리즘 확인하기

ssh -v example.com 2>&1 | grep 'kex: algorithm'

현재 클라이언트와 서버 사이에서 다음 명령을 실행하면 출력 결과를 확인할 수 있습니다.

debug1: kex: algorithm: mlkem768x25519-sha256

mlkem768x25519-sha256는 하이브리드 방식입니다. 이 방식은 FIPS 203으로 표준화된 ML-KEM(module-lattice key encapsulation mechanism) 768 파라미터 세트를 X25519 타원 곡선 Diffie-Hellman과 함께 실행하며, 두 출력값을 혼합하여 세션 키를 생성합니다.

구형 서버를 대상으로 할 경우 대신 다음과 같은 결과가 나타날 수 있습니다.

debug1: kex: algorithm: curve25519-sha256

이 이름에는 양자 내성 알고리즘이 포함되어 있지 않습니다. curve25519-sha256는 타원 곡선 Diffie-Hellman 단독 방식이며, 대형 양자 컴퓨터가 이를 해독할 수 있습니다. 기본값이 변경된 이유가 바로 여기에 있습니다.

단 하나의 구형 장비가 세션 수준을 낮추는 이유는 협상 규칙 때문입니다. 클라이언트는 우선순위에 따라 알고리즘 목록을 전송하고, 서버도 자신의 목록을 전송합니다. 최종적으로 선택되는 알고리즘은 클라이언트 목록에 있으면서 서버 목록에도 포함된 첫 번째 이름입니다. 클라이언트의 우선순위가 우선하므로, 두 종단 중 더 구형인 장비가 협상 수준을 결정하게 됩니다. 따라서 ML-KEM을 지원하지 않는 서버에 접속할 때는 노트북을 업그레이드하더라도 세션 보안 수준이 향상되지 않습니다.

ssh -v은 단순히 이 한 줄을 확인하는 것 이상의 가치가 있습니다. 로그인 자체가 거부될 때 Permission denied (publickey) 오류의 원인을 추적하는 곳도 바로 이 출력 결과이기 때문입니다.

grep을 제거하고 ssh -v을 사용하면 다음 섹션에서 다룰 내용을 포함하여 협상 과정의 나머지 부분을 모두 볼 수 있습니다.

debug1: kex: host key algorithm: ssh-ed25519

어떤 OpenSSH 릴리스부터 하이브리드 교환이 기본값이 되었는가

업스트림 릴리스 노트에 명확한 순서가 나와 있습니다. 버전 번호보다 날짜가 더 중요한데, 이는 해당 기능이 얼마나 오랫동안 조용히 운영되어 왔는지를 보여주기 때문입니다.

• 8.5 (2021-03-03 릴리스): sntrup761x25519-sha512@openssh.com가 추가되었으나 기본적으로 비활성화되었습니다.
• 9.0 (2022-04-08 릴리스): 해당 기능이 활성화되었습니다. 릴리스 노트에 따르면 OpenSSH는 "기본적으로 하이브리드 Streamlined NTRU Prime + x25519 키 교환 방식을 사용"하게 됩니다. 이 릴리스부터 양자 내성 키 교환이 일반적인 사례가 되었습니다.
• 9.9 (2024-09-19 릴리스): mlkem768x25519-sha256이 두 번째 옵션으로 추가되었습니다. 같은 릴리스에서 기존 방식에 IANA 등록 명칭인 sntrup761x25519-sha512을 부여했으므로, 최신 빌드에서는 두 가지 표기법 모두로 나열됩니다.
• 10.0 (2025-04-09 릴리스): mlkem768x25519-sha256가 키 합의를 위한 기본값이 되었습니다.
• 10.1 (2025-10-06 릴리스): 양자 내성 요소가 없는 키 교환으로 연결이 협상될 경우 클라이언트 경고가 추가되었습니다. 이는 ssh_config의 WarnWeakCrypto 옵션으로 제어되며 기본적으로 켜져 있습니다.

2022년 4월은 기억해 둘 만한 날짜입니다. OpenSSH 9.0 이상을 실행하는 모든 기기 쌍은 그 이후로 별도의 설정이나 ssh를 입력하는 사용자에게 알림 없이 양자 내성 키 교환을 수행해 왔습니다.

어떤 Ubuntu 릴리스에 포함되어 있는가

Ubuntu는 릴리스 시점에 특정 OpenSSH 버전을 고정하고, 버전 번호를 올리지 않은 채 보안 패치만 백포트합니다. 따라서 기본 알고리즘은 사용 중인 Ubuntu 릴리스에 따라 결정됩니다. 목록을 신뢰하기보다 ssh -V 명령을 사용하여 현재 사용 중인 장비를 직접 확인하십시오. 2026년 8월 기준으로 아카이브에는 다음 버전들이 포함되어 있습니다:

• 22.04 LTS는 1:8.9p1을 포함하며, 이는 9.0 기본값 이전 버전이므로 기본 설치 시 curve25519-sha256로 협상합니다.
• 24.04 LTS는 1:9.6p1를 포함하며, 이는 9.0 이후 9.9 이전 버전이므로 기본값은 sntrup761x25519-sha512@openssh.com이며 ML-KEM을 지원하지 않습니다.
• 25.10은 1:10.0p1을 포함하며, 기본값은 mlkem768x25519-sha256입니다.
• 26.04 LTS는 1:10.2p1을 포함하며, 기본값은 mlkem768x25519-sha256이고 포스트 양자(post-quantum) 방식이 아닌 연결에 대해 경고를 표시합니다.

실제 두 장비 쌍으로 확인해 보겠습니다. 26.04 노트북이 24.04 서버에 연결합니다. 클라이언트의 첫 번째 선택인 mlkem768x25519-sha256는 9.6 서버의 목록에 없습니다. 서버가 지원하는 클라이언트의 다음 포스트 양자 선택 항목은 sntrup761x25519-sha512@openssh.com이며, 이는 ssh -v이 보고하는 이름과 일치합니다. 별도의 설정 없이도 2024년에 구축된 서버를 대상으로 키 교환 단계에서 포스트 양자 보안이 적용된 세션이 생성됩니다.

22.04의 경우는 반대로 작동하며, 왜 ssh -Q kex만으로는 오해의 소지가 있는지 정확히 보여줍니다. OpenSSH 8.9는 sntrup761x25519-sha512@openssh.com라는 이름을 알고 있으므로 해당 장비에서 ssh -Q kex을 실행하면 목록에 나타나지만, 기본 제안에는 포함되지 않아 협상은 curve25519-sha256로 결정됩니다. 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.

이 경고는 클라이언트가 아닌 접속 대상 서버에 대한 사실입니다. 해결책은 서버를 업그레이드하는 것입니다. WarnWeakCrypto no를 설정하면 메시지는 사라지지만 연결 방식에는 아무런 변화가 없습니다.

하이브리드 방식의 필요성과 '지금 수집하고 나중에 복호화'의 의미

위협의 형태는 명확합니다. 트래픽을 볼 수 있는 공격자는 오늘 암호화된 바이트를 기록하여 저장합니다. 공격자는 현재 이를 읽을 수 없습니다. 하지만 X25519를 해독할 수 있을 만큼 충분히 큰 양자 컴퓨터가 등장할 때까지 데이터를 보관한 뒤, 그때 복호화합니다. 이를 '지금 수집하고 나중에 복호화(harvest now, decrypt later)' 또는 '지금 저장하고 나중에 복호화(store now, decrypt later)'라고 합니다. 이 공격은 현재 시점에서 공격자에게 특별한 기술을 요구하지 않습니다. 단지 디스크 공간과 인내심만 있으면 됩니다.

암호화에는 이러한 문제가 있지만 서명에는 해당하지 않으며, 이러한 비대칭성이 모든 것을 결정합니다. 기록된 암호문은 내부 데이터가 민감하게 유지되는 한 가치를 지닙니다. 반면 서명은 검증되는 순간에만 위조 불가능하면 됩니다. 2035년에 서명 알고리즘을 깨뜨리면 2035년의 서버를 사칭할 수는 있지만, 과거로 돌아가 2026년의 로그인 기록을 위조할 수는 없습니다. 따라서 키 교환 방식을 먼저 수정해야 했으며, 서명 방식은 나중에 변경해도 됩니다.

하이브리드 방식이란 두 알고리즘을 모두 실행하고 그 결과를 합쳐 세션 키를 생성하는 것을 의미합니다. mlkem768x25519-sha256 뒤에 숨겨진 비밀을 복구하려면 공격자는 ML-KEM 768과 X25519를 모두 깨뜨려야 합니다. 이러한 조합은 의도적인 것입니다. ML-KEM은 X25519보다 훨씬 최신 기술이며 암호 분석가들의 공격을 받은 시간이 훨씬 짧습니다. 따라서 새로운 알고리즘에서 결함이 발견되더라도 기존에 확보했던 보안 수준은 그대로 유지됩니다.

보호되는 항목과 그렇지 않은 항목

키 교환은 보호됩니다. 세션을 암호화하는 공유 비밀값은 하이브리드 교환 방식을 통해 생성되었으므로, 오늘 기록된 세션 데이터는 향후 양자 컴퓨터가 등장하더라도 해독할 수 없습니다.

호스트 키는 보호되지 않습니다. debug1: kex: host key algorithm: ssh-ed25519 라인은 고전적인 서명 방식을 명시하며, rsa-sha2-512 및 ECDSA(타원 곡선 디지털 서명 알고리즘) 유형도 마찬가지입니다. 양자 컴퓨터를 보유한 공격자는 해당 서명을 위조하여 서버를 사칭할 수 있지만, 이는 미래의 실시간 연결 중에만 가능하며 현재 기록된 트래픽에 대해서는 불가능합니다.

로그인 키 또한 보호되지 않습니다. ~/.ssh/id_ed25519에 사용된 키는 동일한 유형의 고전적 서명이며, 같은 논리가 적용됩니다. 올해 해당 키를 보호하는 것은 키가 저장된 위치와 접근 권한이므로, 합리적인 SSH 키 관리를 실천하는 것이 이 페이지에 언급된 어떤 알고리즘 이름보다 실질적인 위험을 훨씬 더 크게 줄여줍니다.

현재 전환할 수 있는 대안이 없으므로 이와 관련하여 사용자가 취할 수 있는 조치는 없습니다. OpenSSH는 향후 릴리스에서 양자 내성 서명을 지원할 예정이라고 밝혔습니다. 해당 기능이 포함된 버전이 출시되기 전까지 OpenSSH에는 양자 내성 호스트 키 유형이나 사용자 키 유형이 없으며, ssh-keygen 또한 제공할 수 있는 것이 없습니다. 양자 내성 키를 생성하라고 안내하는 가이드는 아직 존재하지 않는 소프트웨어를 설명하고 있는 것입니다.

동일한 서버에서 사용하는 TLS는 별개의 문제이며 답변 또한 다릅니다. TLS(전송 계층 보안)는 웹 서버가 포트 443에서 사용하는 프로토콜이며, 이는 서로 다른 일정에 따라 운영되는 별도의 코드베이스입니다. OpenSSH를 업그레이드해도 TLS 설정에는 아무런 변화가 없습니다. 만약 동일한 VPS에서 사설 서비스를 위해 자체 서명 인증서를 사용 중이라면, 해당 인증서의 서명과 키 교환 방식은 OpenSSL과 웹 서버에 의해 결정되므로 해당 스택에 맞춰 별도로 확인해야 합니다.

현명한 운영자가 지금 해야 할 일

OpenSSH를 최신 상태로 유지하는 것, 그것으로 충분합니다. 이것이 이 문제에 대한 전체 전략입니다. sudo apt update && sudo apt upgrade은 사용 중인 Ubuntu 릴리스가 제공하는 버전을 유지하게 해주며, 더 새로운 Ubuntu 릴리스로 업그레이드하는 것이 곧 더 새로운 OpenSSH로 이동하는 방법입니다. 자동 보안 업데이트를 활성화하면 기억하지 않아도 패치가 자동으로 적용됩니다. 단순히 알고리즘 이름을 쫓아 소스 코드에서 OpenSSH를 직접 빌드하는 것은 좋지 않은 선택입니다. 서버에서 가장 노출된 서비스에 대한 배포판의 보안 업데이트를 포기하는 셈이기 때문입니다. 그럼에도 소스를 가져온다면, 빌드하기 전에 게시된 체크섬과 다운로드 파일이 일치하는지 확인하십시오.

KexAlgorithms 라인을 직접 작성하지 마십시오. 이는 상황을 확실하게 악화시키는 유일한 행동입니다. 2018년의 보안 강화 가이드는 2018년 당시에는 옳았을지 모르지만, 이를 sshd_config에 붙여넣으면 기본 목록에 추가되는 것이 아니라 아예 대체해 버립니다. 그 이후에 개발된 모든 알고리즘이 제외되므로, 원래 mlkem768x25519-sha256로 협상했을 서버가 고정된 목록에 살아남은 알고리즘으로 조용히 격하됩니다. 인계받은 서버라면 sudo sshd -T | grep -i '^kexalgorithms'를 실행해 보십시오. 해당 라인이 동일한 릴리스의 신규 설치 환경보다 짧다면 누군가 이를 고정해 둔 것입니다.

목록을 변경해야 할 타당한 이유가 있다면, 기존 목록을 대체하지 말고 추가하십시오. OpenSSH는 맨 앞에 +이 있으면 추가, -가 있으면 제거, ^가 있으면 맨 앞으로 이동하는 것으로 해석합니다.

KexAlgorithms ^mlkem768x25519-sha256

설정 파일을 신뢰하기 전에 반드시 테스트하십시오. sudo sshd -t은 설정을 구문 분석하며, 유효할 경우 아무것도 출력하지 않습니다. 빌드에 포함되지 않은 알고리즘을 KexAlgorithms 라인에 지정하면 sshd가 시작되지 않습니다. 원격 서버에서 이런 일이 발생하면 다시 접속할 수 없게 되므로, 작업 중에는 반드시 두 번째 세션을 열어 두십시오. 양쪽의 알고리즘 목록이 겹치지 않으면 클라이언트는 다음과 같이 명확하게 알립니다.

Unable to negotiate with 203.0.113.10 port 22: no matching key exchange method found. Their offer: curve25519-sha256,ecdh-sha2-nistp256

"양자 내성(quantum-safe)"이라는 마케팅 문구는 특정 계층에 대한 주장으로 읽어야 합니다. 제품이 양자 내성을 갖췄다고 주장하는 공급업체는 그들이 명시한 특정 계층만을 설명하는 것이며, 해당 계층은 보통 어딘가의 키 교환 방식입니다. 정확한 알고리즘 이름과 적용되는 프로토콜을 물어보십시오. 2026년 8월 기준 OpenSSH에 대한 정직한 설명은 키 교환은 하이브리드 포스트 양자(post-quantum) 방식이지만 서명은 고전적인 방식을 사용한다는 것입니다. 그보다 더 넓은 범위의 주장을 한다면 ssh -Q kex 출력에서 찾을 수 있는 이름이 함께 제시되어야 합니다.

지루한 기본 작업을 계속하십시오. 포스트 양자 키 교환 방식도 추측 가능한 비밀번호나, 노트북에 복사했다가 도난당한 개인 키 문제까지 해결해주지는 못합니다. 실제로 서버가 침해되는 원인은 바로 그런 것들이며, VPS에서의 표준 SSH 보안 강화가 여전히 대부분의 역할을 수행합니다. 여기서 다룬 협상 단계가 생소하다면, SSH 연결 시 발생하는 과정을 통해 이 페이지에서 전제로 하는 단계들을 확인하십시오.

FAQ

내 SSH 연결은 이미 양자 내성(post-quantum)인가요?

ssh -v yourserver 2>&1 | grep 'kex: algorithm'를 실행하고 출력되는 이름을 확인하십시오. mlkem768x25519-sha256과 sntrup761x25519-sha512@openssh.com은 하이브리드 양자 내성 교환 방식입니다. curve25519-sha256, ecdh-sha2-nistp256 및 기타 diffie-hellman-group 이름이 포함된 방식은 고전적인 방식입니다. 양쪽 끝단 모두 양자 내성 이름을 제공하는 버전을 사용해야 합니다. 협상 과정에서 서버가 지원하는 클라이언트의 첫 번째 선택지를 채택하므로, 구형 장비가 보안 수준의 상한선을 결정하게 됩니다.

양자 내성 키 교환이 기본값이 된 OpenSSH 릴리스는 무엇인가요?

2022년 4월 8일에 릴리스된 OpenSSH 9.0에서 sntrup761x25519-sha512@openssh.com가 기본 키 교환 방식으로 설정되었습니다. 2024년 9월 19일에 릴리스된 OpenSSH 9.9에서는 mlkem768x25519-sha256이 추가되었으며, 2025년 4월 9일에 릴리스된 OpenSSH 10.0에서는 이를 기본값으로 변경했습니다. 2025년 10월 6일에 릴리스된 OpenSSH 10.1부터는 연결 시 양자 내성 방식을 협상하지 않을 경우 경고를 출력하기 시작했습니다. 사용 중인 Ubuntu 릴리스에 따라 제공되는 버전이 다르므로, ssh -Q kex 및 ssh -G <host>을 사용하여 현재 빌드 상태를 확인하십시오.

양자 내성 SSH 키를 생성해야 하나요?

아니요, OpenSSH에는 아직 해당 키 유형이 존재하지 않습니다. 현재까지의 양자 내성 작업은 키 교환 과정에 국한되어 있으며, 사용자 측의 키 파일 생성이나 별도의 설정이 필요하지 않습니다. 호스트 키와 로그인 키는 여전히 Ed25519나 RSA와 같은 고전적인 서명 방식을 사용하며, 업스트림에서는 향후 릴리스에서 양자 내성 서명을 지원할 예정이라고 밝혔습니다. 계속해서 Ed25519 키를 사용하고 해당 키가 저장된 위치를 안전하게 보호하십시오.

왜 ssh에서 연결이 양자 내성이 아니라는 경고가 뜨나요?

OpenSSH 10.1 이상 버전에서는 협상된 교환 방식에 양자 내성 요소가 포함되지 않은 경우 ** WARNING: connection is not using a post-quantum key exchange algorithm.를 출력합니다. 이 경고는 클라이언트가 아닌 서버에 관한 것입니다. 클라이언트는 양자 내성 방식을 제안했으나 서버가 이를 수락하지 않았기 때문입니다. 서버의 OpenSSH를 업그레이드하거나, 서버의 sshd_config 파일 내 KexAlgorithms 라인에 최신 방식이 제외되도록 고정(pinning)되어 있지 않은지 확인하십시오. WarnWeakCrypto no를 설정하면 메시지는 숨길 수 있으나, 연결의 보안 수준은 이전과 동일하게 유지됩니다.