OpenSSH 10.x 포스트 양자 암호화 설정 가이드: SSH 보안의 미래를 준비하자

양자 컴퓨터 시대의 SSH 보안: 왜 지금 준비해야 하는가

2026년 현재, 양자 컴퓨터의 발전 속도가 심상치 않습니다. 솔직히, 몇 년 전만 해도 "양자 컴퓨터? 아직 먼 이야기지"라고 넘겼던 분들이 많을 겁니다. 그런데 SSH(Secure Shell) 프로토콜은 서버 관리, 코드 배포, 자동화 파이프라인 등 리눅스 인프라 전반에서 쓰이고 있고, 이게 뚫리면 사실상 다 뚫리는 거나 마찬가지입니다.

"지금 수집하고, 나중에 해독한다(Harvest Now, Decrypt Later)" — 이게 현재 가장 현실적인 양자 위협 시나리오입니다. 공격자가 지금 당장 암호화된 SSH 세션을 가만히 수집해두고, 양자 컴퓨터가 충분히 발전하면 그때 한꺼번에 해독하는 거죠. 전문가들은 암호학적으로 유의미한 양자 컴퓨터(CRQC)가 2030년대 중반에 등장할 것으로 보고 있습니다. 호주는 2030년, 미국은 2035년까지 양자내성암호(PQC)로의 전환을 의무화하고 있고요.

그래서 지금이 딱 적기입니다. OpenSSH 10.0과 10.1이 출시되면서 포스트 양자 암호화가 드디어 기본값으로 들어갔거든요. 이 가이드에서는 최신 OpenSSH의 포스트 양자 암호화를 설정하고 검증하는 전 과정을 실전 중심으로 다뤄보겠습니다.

SSH에서 양자 위협이 작동하는 방식

SSH 프로토콜의 보안은 크게 두 축으로 나뉩니다:

• 키 교환(Key Exchange): Diffie-Hellman 또는 ECDH를 써서 세션키를 안전하게 공유하는 부분
• 디지털 서명(Digital Signature): RSA, ECDSA, Ed25519 등으로 서버와 사용자를 인증하는 부분

양자 컴퓨터는 쇼어 알고리즘(Shor's Algorithm)으로 RSA, Diffie-Hellman, ECDH 같은 비대칭 암호화를 효율적으로 깰 수 있습니다. 여기서 특히 위험한 건 키 교환 단계입니다. 키 교환이 깨지면 과거에 기록된 모든 세션의 대칭키가 노출되면서, 전체 통신 내용이 줄줄이 해독되기 때문이죠.

반면 디지털 서명은 좀 다릅니다. 과거 트래픽을 소급해서 해독할 위험은 없지만, 양자 컴퓨터가 등장하기 전에 서명 알고리즘 전환은 마쳐야 합니다. OpenSSH는 지금 포스트 양자 키 교환부터 우선 도입하고 있고, 포스트 양자 서명 알고리즘은 향후 릴리즈에서 추가될 예정입니다.

OpenSSH 10.x 주요 변경사항 총정리

OpenSSH 10.0 (2025년 4월)

OpenSSH 10.0은 SSH 보안 역사에서 꽤 굵직한 전환점이었습니다. 주요 변경사항을 정리하면:

• mlkem768x25519-sha256이 기본 키 교환 알고리즘으로 채택: NIST 표준화된 ML-KEM(구 Kyber)과 X25519를 결합한 하이브리드 포스트 양자 알고리즘입니다
• DSA 서명 알고리즘 완전 제거: 2015년부터 비활성화되어 있던 DSA가 코드 레벨에서 아예 삭제되었습니다
• 유한체 Diffie-Hellman(modp) 기본 비활성화: sshd에서 레거시 DH 키 교환이 기본적으로 꺼집니다
• sshd-auth 바이너리 분리: 인증 전 공격 표면을 별도 프로세스로 격리해서 보안을 강화했습니다

OpenSSH 10.1 (2025년 10월)

10.1에서는 포스트 양자 전환을 더 적극적으로 밀어붙이는 업데이트가 들어왔습니다:

• 비포스트 양자 키 교환 사용 시 경고 표시: WarnWeakCrypto 옵션으로 제어할 수 있습니다
• PKCS#11 Ed25519 키 지원: HSM에 저장된 Ed25519 키를 드디어 쓸 수 있게 됐습니다
• RefuseConnection 옵션 추가: 특정 조건에서 연결을 즉시 거부하는 새 보안 기능
• ssh-agent 소켓 위치 변경: /tmp에서 ~/.ssh/agent로 이동 (보안상 합리적인 변경)
• SHA1 SSHFP 레코드 사용 중단 예고: 향후 릴리즈에서 SHA1 기반 DNS SSHFP 레코드 지원이 중단됩니다

포스트 양자 키 교환 알고리즘 비교: mlkem768 vs sntrup761

OpenSSH는 현재 두 가지 하이브리드 포스트 양자 키 교환 알고리즘을 지원합니다. 둘 다 양자 안전 알고리즘과 고전적인 X25519를 결합한 방식이라, 한쪽이 깨져도 다른 쪽이 버텨줍니다.

항목	mlkem768x25519-sha256	sntrup761x25519-sha512
기반 PQ 알고리즘	ML-KEM (구 Kyber-768)	Streamlined NTRU Prime 761
NIST 표준화	FIPS 203 인증 완료	미인증
OpenSSH 도입 버전	9.9	9.0
기본값 채택	10.0부터 기본값	9.0~9.8 기본값
성능	일반적으로 더 빠름	9.9에서 대폭 개선
채택 증가율 (2024.10~2025.03)	+554%	+21%
해시 함수	SHA-256	SHA-512
보안 목표	IND-CCA2	IND-CCA2

개인적으로는 두 알고리즘 모두를 KexAlgorithms 목록에 넣되, mlkem768x25519-sha256을 최우선으로 배치하는 걸 추천합니다. NIST 표준화가 끝났으니 규제 준수도 깔끔하고, sntrup761을 폴백으로 두면 호환성까지 챙길 수 있거든요.

사전 준비: 현재 환경 점검

자, 그럼 본격적으로 설정에 들어가기 전에 현재 환경부터 확인해봅시다.

OpenSSH 버전 확인

제일 먼저 할 일은 지금 돌아가고 있는 OpenSSH 버전 체크입니다.

# 서버 및 클라이언트 버전 확인
ssh -V

# 출력 예시: OpenSSH_10.1p1, OpenSSL 3.5.0 8 Apr 2025

포스트 양자 암호화 지원을 위한 최소 버전은 다음과 같습니다:

• sntrup761x25519-sha512: OpenSSH 9.0 이상
• mlkem768x25519-sha256: OpenSSH 9.9 이상
• PQ 미사용 경고 기능: OpenSSH 10.1 이상

지원되는 키 교환 알고리즘 목록 확인

# 현재 시스템이 지원하는 KEX 알고리즘 목록
ssh -Q kex

# 포스트 양자 알고리즘 포함 여부 확인
ssh -Q kex | grep -E "mlkem|sntrup"

출력에 mlkem768x25519-sha256과 sntrup761x25519-sha512가 모두 나와야 합니다. 안 보이면 OpenSSH 업그레이드가 필요합니다.

현재 연결의 키 교환 알고리즘 확인

# verbose 모드로 접속하여 협상된 알고리즘 확인
ssh -v [email protected] 2>&1 | grep "kex: algorithm"

# 출력 예시: debug1: kex: algorithm: mlkem768x25519-sha256

서버 측 포스트 양자 암호화 설정

기본 sshd_config 설정

서버의 SSH 데몬 설정을 수정해서 포스트 양자 키 교환을 적용합니다. 설정 전에 백업은 꼭 해두세요. (경험상, 백업 안 해두고 후회하는 경우가 생각보다 많습니다.)

# 현재 설정 백업
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup.$(date +%Y%m%d)

# 설정 파일 편집
sudo vim /etc/ssh/sshd_config

다음 설정을 추가하거나 수정합니다:

# 포스트 양자 키 교환 알고리즘 (우선순위 순서)
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,[email protected],curve25519-sha256,[email protected]

# 호스트 키 알고리즘 (Ed25519 우선)
HostKeyAlgorithms [email protected],ssh-ed25519,[email protected],rsa-sha2-512,[email protected],rsa-sha2-256

# 암호화 알고리즘 (AEAD 우선)
Ciphers [email protected],[email protected],[email protected]

# MAC 알고리즘
MACs [email protected],[email protected]

강화된 보안 설정 추가

키 교환 알고리즘만 바꾸는 것보다, 이왕이면 전체적인 SSH 보안 설정도 같이 점검하는 게 좋습니다:

# 비밀번호 인증 비활성화 (키 기반 인증만 허용)
PasswordAuthentication no

# 루트 로그인 비활성화
PermitRootLogin no

# 빈 비밀번호 차단
PermitEmptyPasswords no

# 최대 인증 시도 횟수 제한
MaxAuthTries 3

# 유휴 세션 타임아웃 (5분)
ClientAliveInterval 300
ClientAliveCountMax 2

# X11 포워딩 비활성화
X11Forwarding no

설정 검증 및 적용

# 설정 파일 문법 검증 (반드시 재시작 전에 실행!)
sudo sshd -t

# 오류가 없으면 SSH 데몬 재시작
sudo systemctl restart sshd

# 서비스 상태 확인
sudo systemctl status sshd

주의: 원격 서버에서 작업 중이라면 반드시 별도의 SSH 세션을 하나 더 열어둔 상태에서 설정을 변경하세요. 설정 오류로 SSH가 먹통이 되면... 뭐, 콘솔 접근이 가능하길 바라는 수밖에 없습니다.

클라이언트 측 포스트 양자 암호화 설정

전역 클라이언트 설정

모든 SSH 접속에 포스트 양자 키 교환을 기본 적용하려면 ~/.ssh/config를 수정합니다:

# ~/.ssh/config

# 기본: 포스트 양자 키 교환 강제
Host *
    KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,[email protected]
    HostKeyAlgorithms [email protected],ssh-ed25519,rsa-sha2-512,rsa-sha2-256
    Ciphers [email protected],[email protected],[email protected]
    MACs [email protected],[email protected]

레거시 서버를 위한 예외 설정

현실적으로, 모든 서버가 PQ를 지원하진 않습니다. 구형 서버에 접속해야 할 때는 호스트별 예외를 설정하면 됩니다:

# 포스트 양자를 지원하지 않는 레거시 서버용 예외
Host legacy-server.example.com
    KexAlgorithms curve25519-sha256,[email protected],ecdh-sha2-nistp256
    # 경고 메시지 억제 (OpenSSH 10.1+)
    WarnWeakCrypto no

# 특정 네트워크 대역의 구형 장비
Host 192.168.10.*
    KexAlgorithms curve25519-sha256,diffie-hellman-group16-sha512
    WarnWeakCrypto no

중요: WarnWeakCrypto no는 경고 메시지만 숨길 뿐, 보안 취약점을 고쳐주는 건 아닙니다. 레거시 서버의 OpenSSH 업그레이드를 최우선 과제로 잡으세요.

배포판별 설치 및 업그레이드 가이드

Ubuntu 24.04 LTS / Debian 13

# 최신 패키지 목록 업데이트 및 OpenSSH 업그레이드
sudo apt update && sudo apt upgrade openssh-server openssh-client

# 설치된 버전 확인
ssh -V

# Ubuntu 24.04에 포함된 OpenSSH가 9.9 미만인 경우
# PPA를 통한 최신 버전 설치를 고려
sudo add-apt-repository ppa:openssh/ppa
sudo apt update && sudo apt upgrade openssh-server

RHEL 10 / Rocky Linux 10 / AlmaLinux 10

RHEL 계열은 좀 다릅니다. RHEL 10.0에서는 추가 패키지가 필요하고, 10.1부터는 기본 정책에 포스트 양자 지원이 포함됩니다.

# RHEL 10.0: PQC 암호 정책 패키지 설치
sudo dnf install crypto-policies-pq-preview crypto-policies-scripts

# 시스템 전체 PQC 정책 활성화
sudo update-crypto-policies --set DEFAULT:TEST-PQ

# 정책 변경 확인
update-crypto-policies --show

# RHEL 10.1 이상: 별도 설정 불필요 (기본값으로 PQC 활성화)
ssh -V

Fedora 41+ / Arch Linux

Fedora와 Arch는 비교적 간단합니다. 롤링 릴리즈 특성상 최신 버전을 빨리 받을 수 있으니까요.

# Fedora
sudo dnf upgrade openssh openssh-server openssh-clients

# Arch Linux
sudo pacman -Syu openssh

# 버전 확인
ssh -V

Ed25519 키 생성 및 FIDO2 하드웨어 키 설정

Ed25519 SSH 키 생성

2026년 기준으로 SSH 인증 키는 Ed25519가 사실상 표준입니다. 256비트의 컴팩트한 키 크기에 RSA보다 빠르고, 구현이 단순해서 사이드 채널 공격 노출도 적습니다.

# Ed25519 키 생성 (강력한 패스프레이즈 설정 권장)
ssh-keygen -t ed25519 -C "user@hostname-$(date +%Y%m%d)"

# 키 파일 권한 확인 및 설정
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

# 기존 RSA 키를 Ed25519로 교체 시, 서버에 새 공개키 등록
ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]

FIDO2 하드웨어 보안 키 활용

보안을 한 단계 더 높이고 싶다면 FIDO2 하드웨어 키를 활용할 수 있습니다. OpenSSH 8.2부터 YubiKey, SoloKey 같은 FIDO2/WebAuthn 장치를 SSH 인증에 쓸 수 있는데, 개인키가 하드웨어 밖으로 나가지 않으니 최고 수준의 인증 보안을 확보할 수 있습니다.

# FIDO2 resident 키 생성 (YubiKey 등 필요)
ssh-keygen -t ed25519-sk -O resident -O verify-required -C "hardware-key"

# 서버의 sshd_config에서 FIDO2 키 허용 확인
# PubkeyAcceptedAlgorithms에 [email protected] 포함 필요

포스트 양자 키 교환 검증 및 모니터링

연결별 알고리즘 검증

설정을 마쳤으면 실제로 PQ 키 교환이 잘 되는지 확인해봐야겠죠.

# 특정 서버의 PQ 키 교환 지원 테스트
ssh -o KexAlgorithms=mlkem768x25519-sha256 [email protected] echo "PQ KEX 성공"

# 상세 디버그 로그로 키 교환 과정 확인
ssh -vvv [email protected] 2>&1 | grep -E "kex:|KEX"

# 서버가 제안하는 알고리즘 목록 스캔
ssh -o KexAlgorithms=mlkem768x25519-sha256 -o ConnectTimeout=5 [email protected] 2>&1

대규모 인프라 감사 스크립트

서버가 몇 대 안 되면 수작업으로도 되지만, 수십~수백 대를 관리한다면 감사 스크립트가 필수입니다.

#!/bin/bash
# pq_audit.sh - SSH 포스트 양자 키 교환 감사 스크립트

SERVER_LIST="/etc/ssh/server_inventory.txt"
REPORT_FILE="/var/log/ssh_pq_audit_$(date +%Y%m%d).csv"

echo "호스트,IP,PQ_지원,사용_알고리즘,OpenSSH_버전" > "$REPORT_FILE"

while IFS= read -r server; do
    # SSH 버전 배너 수집
    version=$(ssh-keyscan -t ed25519 "$server" 2>&1 | head -1)

    # PQ KEX 테스트
    pq_result=$(ssh -o BatchMode=yes \
                    -o KexAlgorithms=mlkem768x25519-sha256 \
                    -o ConnectTimeout=5 \
                    -o StrictHostKeyChecking=no \
                    "$server" echo "OK" 2>&1)

    if echo "$pq_result" | grep -q "OK"; then
        echo "$server,$(dig +short "$server"),지원,mlkem768x25519-sha256,$version" >> "$REPORT_FILE"
    else
        # sntrup761 폴백 테스트
        pq_fallback=$(ssh -o BatchMode=yes \
                         -o KexAlgorithms=sntrup761x25519-sha512 \
                         -o ConnectTimeout=5 \
                         -o StrictHostKeyChecking=no \
                         "$server" echo "OK" 2>&1)
        if echo "$pq_fallback" | grep -q "OK"; then
            echo "$server,$(dig +short "$server"),부분지원,sntrup761x25519-sha512,$version" >> "$REPORT_FILE"
        else
            echo "$server,$(dig +short "$server"),미지원,없음,$version" >> "$REPORT_FILE"
        fi
    fi
done < "$SERVER_LIST"

echo "감사 완료. 보고서: $REPORT_FILE"
# 미지원 서버 수 요약
echo "PQ 미지원 서버: $(grep '미지원' "$REPORT_FILE" | wc -l)대"

기업 환경 마이그레이션 전략

3단계 전환 로드맵

대규모 인프라에서 포스트 양자 전환을 한 번에 밀어붙이는 건 위험합니다. 단계적으로 가는 게 맞습니다.

1단계 — 현황 파악 및 인벤토리 (1~2주)

• 모든 SSH 서버의 OpenSSH 버전 조사
• 사용 중인 키 교환 알고리즘, 호스트 키 타입, 사용자 키 타입 점검
• 자동화 스크립트, CI/CD 파이프라인, 모니터링 도구의 SSH 클라이언트 호환성 확인
• DSA 키를 아직 쓰고 있는 시스템 식별 — 이건 즉시 교체해야 합니다

2단계 — 점진적 롤아웃 (2~4주)

• 스테이징 환경에서 포스트 양자 설정을 먼저 테스트
• 비핵심 서버부터 OpenSSH 업그레이드 및 PQ 키 교환 활성화
• 클라이언트 설정에 PQ 알고리즘을 최우선으로 추가하되, 고전 알고리즘도 폴백으로 유지
• 모니터링으로 연결 실패나 성능 이상 감지

3단계 — 강제 적용 및 레거시 제거

• 모든 서버에서 PQ 키 교환을 기본값으로 설정
• 고전 DH 및 ECDH 전용 키 교환 비활성화
• 레거시 서버에 대한 예외 목록 관리 및 주기적 검토
• 정기적인 규제 준수 감사 체계 구축

전 세계 SSH PQ 도입 현황

참고로 현재 상황을 짚어보면, 2025년 기준 전 세계 SSH 서버 중 약 6%(1,100만 대 이상)가 양자내성 암호화를 지원합니다. OpenSSH 서버만 놓고 보면 20% 이상으로 올라가지만, 인터넷에 노출된 OpenSSH 서버의 75%가 여전히 2015~2022년 사이 버전을 돌리고 있습니다. IT 장비는 42%가 PQ를 지원하는 반면, IoT는 20%, 네트워크/OT 장비는 11%, 의료 IoT(IoMT)는 겨우 2%입니다. 갈 길이 멀죠.

트러블슈팅: 자주 발생하는 문제와 해결법

"no matching key exchange method found" 오류

가장 흔하게 만나는 에러입니다. 서버가 클라이언트에서 요청하는 PQ 알고리즘을 지원하지 않을 때 발생합니다.

# 해결: 연결 시 폴백 알고리즘 추가
ssh -o KexAlgorithms=mlkem768x25519-sha256,curve25519-sha256 [email protected]

# 또는 ~/.ssh/config에 호스트별 예외 추가
# Host old-server.example.com
#     KexAlgorithms 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.

# 근본 해결: 서버의 OpenSSH를 9.9 이상으로 업그레이드
# 임시 해결: 해당 호스트에 WarnWeakCrypto no 설정

이 경고가 뜨면 당장 연결이 안 되는 건 아니지만, 무시하고 넘기지 마세요. 업그레이드 계획을 세우는 게 맞습니다.

SSH 접속 속도 저하 문제

포스트 양자 키 교환은 키 크기가 좀 더 크긴 합니다. 다만 실제 SSH 핸드셰이크에서의 지연은 대부분의 환경에서 무시할 만한 수준이에요. 만약 체감될 정도로 느려졌다면:

# 키 교환 시간 측정
time ssh -o KexAlgorithms=mlkem768x25519-sha256 [email protected] exit
time ssh -o KexAlgorithms=curve25519-sha256 [email protected] exit

# 네트워크 MTU 문제 확인 (PQ 키 교환의 큰 패킷이 단편화될 수 있음)
ping -M do -s 1400 server.example.com

자주 묻는 질문 (FAQ)

포스트 양자 SSH 키 교환을 사용하면 접속 속도가 느려지나요?

거의 차이 없습니다. ML-KEM 기반 mlkem768x25519-sha256은 효율성을 고려해 설계되었고, 기존 X25519 대비 핸드셰이크 시간 차이가 수 밀리초 이내입니다. 위성 통신처럼 대역폭이 극도로 제한된 환경에서는 미세한 차이가 있을 수 있지만, 일반적인 서버 관리 작업에서는 체감하기 어렵습니다.

양자 컴퓨터가 아직 실용화되지 않았는데 지금 PQ 전환이 필요한가요?

네, 필요합니다. "Harvest Now, Decrypt Later" 공격은 지금 이 순간에도 진행 중입니다. 국가 수준의 공격자들은 이미 암호화된 트래픽을 대규모로 수집하고 있고, 양자 컴퓨터가 실용화되는 순간 과거 데이터를 통째로 해독할 수 있습니다. 데이터의 민감도와 보존 기간을 따져보면, 지금 시작해도 이른 게 아닙니다.

OpenSSH 버전을 업그레이드할 수 없는 레거시 서버는 어떻게 보호하나요?

업그레이드가 정말 불가능한 서버라면, SSH 프록시(jump host)를 활용하는 게 가장 현실적입니다. PQ 키 교환을 지원하는 배스천 호스트를 경유해서 레거시 서버에 접속하면, 최소한 외부 네트워크 구간에서는 PQ 보호를 유지할 수 있습니다. WireGuard VPN 같은 PQ 지원 터널을 네트워크 레벨에서 활용하는 방법도 있고요.

mlkem768x25519-sha256과 sntrup761x25519-sha512 중 어떤 것을 선택해야 하나요?

둘 다 쓰세요. mlkem768x25519-sha256은 NIST 표준화(FIPS 203)가 끝나서 규제 준수 환경에 딱이고, sntrup761x25519-sha512는 더 오래 검증되어 온 알고리즘입니다. KexAlgorithms에서 mlkem768을 첫 번째, sntrup761을 두 번째로 배치하면 보안과 호환성 모두 잡을 수 있습니다.

RHEL이나 Ubuntu의 기본 저장소 OpenSSH 버전이 낮으면 어떻게 하나요?

RHEL 10.1 이상과 Ubuntu 24.04 LTS 이후 버전에서는 기본 저장소에서 PQ 지원 OpenSSH를 제공합니다. 이전 버전을 쓰고 있다면 배포판의 보안 백포트 채널부터 확인해보세요. 소스 컴파일 설치는 패키지 관리가 복잡해지니 최후의 수단으로만 고려하되, 이 경우 sshd-auth 바이너리가 반드시 포함되도록 빌드해야 합니다.