Ubuntu 포스트 양자 SSH 설정 확인 및 변경 사항

포스트 양자 SSH의 변경 사항

포스트 양자(post-quantum) SSH는 이미 대부분의 사용자에게 적용되었으며, 별도의 설정은 필요하지 않습니다. 최신 OpenSSH 클라이언트가 최신 OpenSSH 서버와 통신할 때 기본적으로 하이브리드 포스트 양자 키 교환 방식을 선택하기 때문입니다. 따라서 오늘날 네트워크 트래픽을 기록해 두었다가 수년 뒤에 해독하려는 공격자로부터 세션 키를 보호할 수 있습니다. 이 보호 기능은 실질적이지만, "양자 내성(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는 하이브리드 방식입니다. 이는 매개변수 세트 768의 ML-KEM(FIPS 203으로 표준화된 모듈 격자 기반 키 캡슐화 메커니즘)과 X25519 타원 곡선 Diffie-Hellman을 함께 실행하며, 두 출력값을 혼합하여 세션 키를 생성합니다.

구형 서버를 상대할 때는 대신 다음과 같은 결과가 나타날 수 있습니다:

debug1: kex: algorithm: curve25519-sha256

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

단 하나의 구형 장비가 세션 전체의 수준을 낮추는 이유는 협상 규칙 하나로 설명됩니다. 클라이언트는 선호도 순서대로 알고리즘 목록을 보내고, 서버도 자신의 목록을 보냅니다. 이때 선택되는 알고리즘은 클라이언트 목록에 있으면서 서버 목록에도 포함된 첫 번째 이름입니다. 클라이언트의 선호도가 우선하므로, 양쪽 끝단 중 더 구형인 장비가 협상 수준을 결정하게 됩니다. 따라서 노트북을 업그레이드하더라도 ML-KEM을 지원하지 않는 서버와의 세션은 업그레이드되지 않습니다.

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이고 포스트 양자 암호화가 아닌 연결에 대해 경고합니다.

실제 두 기기를 사용하여 확인해 보십시오. 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-04-08에 릴리스된 OpenSSH 9.0에서 sntrup761x25519-sha512@openssh.com가 기본 키 교환 방식으로 설정되었습니다. 2024-09-19에 릴리스된 OpenSSH 9.9에서는 mlkem768x25519-sha256가 추가되었고, 2025-04-09에 릴리스된 OpenSSH 10.0에서는 이를 기본값으로 변경했습니다. 2025-10-06에 릴리스된 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 설정에 최신 방식이 제외되어 있는지 확인하십시오. WarnWeakCrypto no을 설정하면 메시지는 숨길 수 있지만, 연결의 보안 수준은 이전과 동일하게 유지됩니다.