SSH hậu lượng tử trên Ubuntu đã thay đổi gì?

SSH hậu lượng tử đã thay đổi gì

SSH hậu lượng tử đã được bật sẵn cho hầu hết người dùng và không ai phải tự cấu hình. Client OpenSSH hiện tại khi kết nối đến server OpenSSH hiện tại sẽ mặc định chọn cơ chế trao đổi key hậu lượng tử lai. Vì vậy, session key vẫn chống được kiểu tấn công trong đó kẻ tấn công ghi lại network traffic hôm nay rồi giải mã sau nhiều năm. Cơ chế bảo vệ này là có thật, nhưng phạm vi hẹp hơn so với ý nghĩa mà cụm từ "SSH an toàn trước máy tính lượng tử" gợi ra.

Trước hết cần hiểu 2 thuật ngữ. SSH (secure shell) là protocol dùng để đăng nhập vào server. Key exchange, thường được viết là "kex", là bước đầu tiên của mọi kết nối SSH: hai đầu kết nối thỏa thuận một shared secret, rồi secret đó mã hóa toàn bộ dữ liệu tiếp theo. Phần thay đổi là key exchange. Không có phần nào khác thay đổi.

Không nên tin nội dung trang này, hãy tự chạy các lệnh

Mỗi tên algorithm bên dưới đều được lấy từ một command mà bạn có thể tự chạy. Đây là chủ ý. Giá trị mặc định thay đổi theo từng bản release của OpenSSH. Vì vậy, một hướng dẫn được viết từ 2 năm trước có thể nêu một algorithm mà máy của bạn không còn ưu tiên, nhưng không có cách nào báo cho bạn biết điều đó. Hãy học các command này để không còn phải phụ thuộc vào các bài viết về chủ đề này, kể cả bài viết này.

Bắt đầu bằng cách kiểm tra những gì bản build của bạn hỗ trợ.

ssh -V
ssh -Q kex

ssh -V in ra một dòng version bắt đầu bằng OpenSSH_, tiếp theo là hậu tố package của Ubuntu và version của OpenSSL. ssh -Q kex in ra mỗi algorithm trao đổi key trên một dòng. Với bản build có hỗ trợ hậu lượng tử, bạn sẽ thấy các tên như mlkem768x25519-sha256 và sntrup761x25519-sha512@openssh.com trong danh sách đó, nằm cạnh các tên algorithm cổ điển như curve25519-sha256.

Build của bạn hỗ trợ gì không đồng nghĩa với việc nó đề xuất gì

Đây là điểm khác biệt mà hầu hết bài viết đều bỏ qua. ssh -Q kex trả lời một câu hỏi: binary này có thể làm gì. Nó không trả lời câu hỏi bạn thực sự cần biết: connection này sẽ thực sự đề xuất gì. Hai danh sách này khác nhau, và khoảng cách giữa chúng là nơi các hướng dẫn cũ gây ra thiệt hại thực tế.

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

ssh -G <host> in cấu hình thực tế của client cho host đó, sau khi đã áp dụng ~/.ssh/config và /etc/ssh/ssh_config. sshd -T làm điều tương tự cho server. Mỗi lệnh in một dòng kexalgorithms duy nhất theo thứ tự ưu tiên, và tên đầu tiên trên dòng đó là lựa chọn đầu tiên của phía tương ứng. Chính dòng đó được gửi qua network.

Khoảng cách này không chỉ mang tính lý thuyết. OpenSSH 8.5, được phát hành vào 2021-03-03, đã thêm sntrup761x25519-sha512@openssh.com nhưng cố ý không đưa nó vào danh sách mặc định. Trên bản phát hành đó, ssh -Q kex hiển thị algorithm này còn ssh -G thì không, nghĩa là binary có thể thực hiện post-quantum key exchange nhưng không có connection nào thực sự yêu cầu nó.

Đọc thuật toán mà kết nối của bạn đã thương lượng

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

Giữa một client hiện tại và một server hiện tại, lệnh này in ra:

debug1: kex: algorithm: mlkem768x25519-sha256

mlkem768x25519-sha256 là một thuật toán lai. Nó chạy ML-KEM (cơ chế đóng gói khóa dựa trên mạng module, được chuẩn hóa thành FIPS 203) ở bộ tham số 768, cùng với Diffie-Hellman trên đường cong elliptic X25519, rồi trộn cả hai đầu ra vào session key.

Khi kết nối đến một server cũ hơn, bạn có thể thấy:

debug1: kex: algorithm: curve25519-sha256

Tên này không có thành phần hậu lượng tử. curve25519-sha256 chỉ là Diffie-Hellman trên đường cong elliptic, và một máy tính lượng tử đủ lớn có thể phá vỡ nó. Đó là toàn bộ lý do default đã được thay đổi.

Một quy tắc thương lượng giải thích vì sao chỉ một máy cũ cũng có thể làm session bị giới hạn. Client gửi danh sách theo thứ tự ưu tiên, server cũng gửi danh sách của mình, rồi thuật toán được chọn là tên đầu tiên trong danh sách của client đồng thời xuất hiện trong danh sách của server. Ưu tiên của client được giữ nguyên, nên đầu cuối cũ hơn trong hai bên quyết định bạn đi được đến đâu trong danh sách. Nâng cấp laptop không thể nâng cấp session đến một server chưa từng biết đến ML-KEM.

ssh -v đáng để biết không chỉ vì một dòng này, vì chính output đó cũng là nơi bạn tìm lỗi Permission denied (publickey) khi login bị từ chối hoàn toàn.

Bỏ grep và ssh -v để xem phần còn lại của quá trình thương lượng, bao gồm dòng mà section tiếp theo đề cập:

debug1: kex: host key algorithm: ssh-ed25519

Bản OpenSSH nào đưa cơ chế trao đổi hybrid thành mặc định

Release notes của upstream cho thấy trình tự rõ ràng. Các mốc thời gian quan trọng hơn số phiên bản, vì chúng cho thấy tính năng này đã âm thầm hoạt động trong bao lâu.

• 8.5, phát hành ngày 2021-03-03, thêm sntrup761x25519-sha512@openssh.com nhưng tắt theo mặc định.
• 9.0, phát hành ngày 2022-04-08, bật tính năng này. Release notes ghi rằng OpenSSH sẽ “mặc định sử dụng phương thức trao đổi key hybrid Streamlined NTRU Prime + x25519”. Đây là bản phát hành đưa trao đổi key hậu lượng tử trở thành trường hợp thông thường.
• 9.9, phát hành ngày 2024-09-19, thêm mlkem768x25519-sha256 làm tùy chọn thứ hai. Bản phát hành này cũng cấp cho phương thức cũ tên đã đăng ký với IANA là sntrup761x25519-sha512, nên các bản build mới liệt kê phương thức này dưới cả hai cách viết.
• 10.0, phát hành ngày 2025-04-09, đặt mlkem768x25519-sha256 làm mặc định cho việc thỏa thuận key.
• 10.1, phát hành ngày 2025-10-06, thêm cảnh báo phía client khi một kết nối thương lượng phương thức trao đổi key không có thành phần hậu lượng tử. Tùy chọn này được điều khiển bằng WarnWeakCrypto trong ssh_config và được bật theo mặc định.

Tháng 4 năm 2022 là mốc đáng nhớ. Mọi cặp máy chạy OpenSSH 9.0 trở lên đều đã thực hiện trao đổi key hậu lượng tử kể từ thời điểm đó, không cần cấu hình và cũng không có thông báo nào cho người đang nhập ssh.

Ubuntu release nào có thuật toán này

Ubuntu cố định phiên bản OpenSSH khi phát hành, sau đó backport các bản sửa lỗi bảo mật vào phiên bản đó mà không thay đổi số phiên bản. Vì vậy, Ubuntu release bạn đang chạy sẽ quyết định thuật toán mặc định. Hãy kiểm tra trực tiếp máy đang dùng bằng ssh -V thay vì chỉ tin vào một danh sách. Tính đến tháng 8 năm 2026, archive có các phiên bản sau:

• 22.04 LTS có 1:8.9p1, ra trước khi mặc định thay đổi ở 9.0, nên bản cài đặt mặc định sẽ negotiate curve25519-sha256.
• 24.04 LTS có 1:9.6p1, sau 9.0 và trước 9.9, nên mặc định là sntrup761x25519-sha512@openssh.com và không có ML-KEM.
• 25.10 có 1:10.0p1, với mặc định là mlkem768x25519-sha256.
• 26.04 LTS có 1:10.2p1, mặc định là mlkem768x25519-sha256 và cảnh báo về các connection không có post-quantum.

Hãy kiểm tra trên một cặp máy thực tế. Một laptop chạy 26.04 kết nối đến server chạy 24.04. Lựa chọn đầu tiên của client, mlkem768x25519-sha256, không có trong danh sách của server 9.6. Lựa chọn post-quantum tiếp theo của client mà server có hỗ trợ là sntrup761x25519-sha512@openssh.com, và đó là tên mà ssh -v báo cáo. Key exchange của session là post-quantum, dù server được build vào năm 2024 và không ai cấu hình gì thêm.

Trường hợp 22.04 diễn ra theo hướng ngược lại và cho thấy chính xác vì sao chỉ dùng ssh -Q kex sẽ gây hiểu nhầm. OpenSSH 8.9 biết tên sntrup761x25519-sha512@openssh.com, nên ssh -Q kex trên máy đó sẽ liệt kê tên này. Tuy nhiên, proposal mặc định không đưa nó vào, nên negotiation chọn curve25519-sha256. Từ client chạy OpenSSH 10.1 hoặc mới hơn, connection sẽ báo điều này:

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.

Cảnh báo đó phản ánh server bạn đang kết nối đến, không phản ánh client của bạn. Cách xử lý là upgrade server. Đặt WarnWeakCrypto no sẽ xóa thông báo nhưng không thay đổi connection.

Vì sao dùng hybrid, và “thu thập ngay, giải mã sau” nghĩa là gì

Mối đe dọa này rất rõ ràng. Kẻ tấn công có thể theo dõi network traffic sẽ ghi lại các byte đã mã hóa hôm nay và lưu trữ chúng. Hiện tại, chúng chưa thể đọc dữ liệu đó. Chúng giữ dữ liệu cho đến khi xuất hiện một quantum computer đủ lớn để phá X25519, rồi giải mã chúng. Cách này được gọi là “thu thập ngay, giải mã sau”, hoặc “lưu trữ ngay, giải mã sau”. Hiện tại, kẻ tấn công không cần làm gì phức tạp. Chúng chỉ cần dung lượng đĩa và sự kiên nhẫn.

Mã hóa gặp vấn đề này, còn chữ ký thì không. Sự bất đối xứng đó quyết định mọi phần còn lại. Một ciphertext đã ghi lại vẫn có giá trị chừng nào dữ liệu bên trong còn nhạy cảm. Chữ ký chỉ cần không thể giả mạo tại thời điểm được kiểm tra. Nếu phá được một thuật toán chữ ký vào năm 2035, ai đó có thể giả mạo server vào năm 2035. Điều đó không cho phép họ quay lại giả mạo một lần đăng nhập từ năm 2026. Vì vậy, cần xử lý phần trao đổi key trước, còn phần chữ ký có thể chờ.

Hybrid nghĩa là cả hai thuật toán cùng chạy và cả hai kết quả đều được đưa vào session key. Để khôi phục secret đứng sau mlkem768x25519-sha256, kẻ tấn công phải phá được cả ML-KEM 768 và X25519. Việc kết hợp này là có chủ đích: ML-KEM mới hơn nhiều so với X25519 và có ít thời gian hơn đáng kể để các nhà phân tích mật mã kiểm thử, nên một lỗ hổng được phát hiện trong thuật toán mới sẽ không làm mất lớp bảo vệ mà bạn đã có.

Điều gì được bảo vệ và điều gì không

Trao đổi key được bảo vệ. Shared secret dùng để mã hóa session của bạn được tạo ra từ một cơ chế trao đổi hybrid. Vì vậy, bản ghi session được lưu hôm nay sẽ không trở nên có thể đọc được khi máy tính lượng tử xuất hiện.

Host key không được bảo vệ. Dòng debug1: kex: host key algorithm: ssh-ed25519 chỉ định một chữ ký cổ điển. rsa-sha2-512 và các loại ECDSA (elliptic curve digital signature algorithm) cũng vậy. Kẻ tấn công có máy tính lượng tử hoạt động có thể giả mạo chữ ký đó và mạo danh server của bạn, nhưng chỉ trong một kết nối trực tiếp tại thời điểm tương lai đó. Chúng không thể dùng cách này để tấn công lưu lượng đã ghi lại hôm nay.

Login key của bạn cũng không được bảo vệ. Key trong ~/.ssh/id_ed25519 thuộc cùng loại chữ ký cổ điển, nên lập luận tương tự cũng áp dụng. Điều bảo vệ key đó trong năm nay là nơi nó được lưu và ai có thể đọc nó. Vì vậy, quản lý SSH key hợp lý giúp giảm rủi ro thực tế của bạn nhiều hơn bất kỳ tên thuật toán nào trên trang này.

Bạn không cần làm gì với cả hai loại key đó, vì hiện chưa có loại key nào để chuyển sang. OpenSSH cho biết hỗ trợ chữ ký hậu lượng tử sẽ có trong một bản release tương lai. Cho đến khi tính năng đó được release, OpenSSH chưa có host key type hậu lượng tử và cũng chưa có user key type hậu lượng tử. ssh-keygen cũng không có loại nào để cung cấp cho bạn. Hướng dẫn yêu cầu bạn generate một loại key như vậy đang mô tả phần mềm chưa tồn tại.

TLS trên cùng server là một vấn đề riêng và có câu trả lời riêng. TLS (transport layer security) là giao thức mà web server của bạn sử dụng trên port 443. Nó thuộc một codebase khác và có lịch trình phát triển khác. Nâng cấp OpenSSH không thay đổi gì ở đó. Nếu bạn đang chạy certificate tự ký cho một service private trên cùng VPS, chữ ký và cơ chế trao đổi key của certificate đó do OpenSSL và web server của bạn quyết định. Vì vậy, hãy đánh giá stack đó theo các điều kiện riêng của nó.

Việc một operator thận trọng nên làm lúc này

Giữ OpenSSH luôn cập nhật, và dừng ở đó. Đó thực sự là toàn bộ chiến lược cho vấn đề này. sudo apt update && sudo apt upgrade giữ bạn ở phiên bản mà bản Ubuntu hiện tại phát hành, còn chuyển sang bản Ubuntu mới hơn là cách đưa bạn lên OpenSSH mới hơn. Bật cập nhật bảo mật tự động để các bản vá được áp dụng mà bạn không cần nhớ tự chạy. Tự build OpenSSH từ source chỉ để chạy theo tên algorithm là một đánh đổi không đáng, vì bạn sẽ mất các bản cập nhật bảo mật của distribution cho service bị exposed nhiều nhất trên máy. Nếu vẫn tải source, hãy đối chiếu file tải xuống với checksum đã được công bố trước khi build.

Không tự viết một dòng KexAlgorithms. Đây là hành động duy nhất chắc chắn làm tình hình tệ hơn. Một hướng dẫn hardening từ năm 2018 đưa cho bạn danh sách từng đúng vào năm 2018, rồi khi dán danh sách đó vào sshd_config, bạn sẽ thay thế danh sách mặc định thay vì bổ sung vào đó. Mọi algorithm được tạo ra từ sau thời điểm đó đều bị loại, nên một server vốn tự đàm phán được mlkem768x25519-sha256 sẽ âm thầm hạ xuống algorithm nào còn lại trong danh sách bị pin. Hãy chạy sudo sshd -T | grep -i '^kexalgorithms' trên mọi server bạn được bàn giao. Nếu dòng đó ngắn hơn dòng trên một bản cài mới cùng release, nghĩa là đã có người pin nó.

Nếu có lý do thực sự để thay đổi danh sách, hãy bổ sung thay vì thay thế. OpenSSH hiểu + ở đầu là thêm vào cuối, - ở đầu là xóa, và ^ ở đầu là đưa lên đầu danh sách.

KexAlgorithms ^mlkem768x25519-sha256

Kiểm tra file trước khi dựa vào cấu hình đó. sudo sshd -t parse cấu hình và không in gì nếu cấu hình hợp lệ. Một dòng KexAlgorithms chỉ rõ một algorithm mà bản build không hỗ trợ sẽ khiến sshd không khởi động được. Trên máy remote, điều đó có nghĩa là bạn không thể đăng nhập lại, vì vậy hãy giữ một session thứ hai mở trong khi làm việc. Khi danh sách của hai phía không còn phần tử chung, client sẽ báo rõ:

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

Hãy hiểu các thông điệp marketing về “quantum-safe” là tuyên bố chỉ áp dụng cho một layer. Khi vendor gọi một sản phẩm là quantum-safe, họ đang mô tả layer mà họ nêu tên, và layer đó thường là một key exchange ở đâu đó trong giao thức. Hãy yêu cầu tên algorithm và protocol mà nó áp dụng. Với OpenSSH vào tháng 8 năm 2026, cách diễn đạt chính xác là key exchange dùng hybrid post-quantum, còn chữ ký vẫn là classical. Bất kỳ tuyên bố nào rộng hơn đều phải đi kèm tên mà bạn có thể tìm thấy trong output của ssh -Q kex.

Tiếp tục làm những phần nhàm chán nhưng cần thiết. Post-quantum key exchange không giải quyết được password dễ đoán hoặc private key bị copy lên laptop rồi laptop đó bị đánh cắp. Chính những vấn đề này mới thực sự khiến server bị chiếm quyền, và hardening SSH tiêu chuẩn trên VPS vẫn đóng góp phần lớn hiệu quả bảo mật. Nếu các bước negotiation ở đây còn xa lạ, SSH làm gì khi bạn kết nối giải thích các giai đoạn mà trang này giả định bạn đã biết.

FAQ

Kết nối SSH của tôi đã có tính hậu lượng tử chưa?

Chạy ssh -v yourserver 2>&1 | grep 'kex: algorithm' và đọc tên mà lệnh in ra. mlkem768x25519-sha256 và sntrup761x25519-sha512@openssh.com là các cơ chế trao đổi khóa hậu lượng tử lai. curve25519-sha256, ecdh-sha2-nistp256 và mọi tên diffie-hellman-group đều là cơ chế cổ điển. Cả hai đầu phải dùng phiên bản cung cấp một tên hậu lượng tử, vì quá trình thương lượng chọn lựa chọn đầu tiên của client mà server cũng hỗ trợ. Do đó, máy cũ hơn sẽ giới hạn mức hỗ trợ tối đa.

Bản phát hành OpenSSH nào đặt trao đổi khóa hậu lượng tử làm mặc định?

OpenSSH 9.0, phát hành vào 2022-04-08, đặt sntrup761x25519-sha512@openssh.com làm cơ chế trao đổi khóa mặc định. OpenSSH 9.9, phát hành vào 2024-09-19, bổ sung mlkem768x25519-sha256, còn OpenSSH 10.0, phát hành vào 2025-04-09, đặt cơ chế này làm mặc định thay thế. OpenSSH 10.1, phát hành vào 2025-10-06, bắt đầu cảnh báo khi kết nối không thương lượng được cơ chế nào trong hai cơ chế đó. Kiểm tra build của bạn bằng ssh -Q kex và ssh -G <host>, vì bản phát hành Ubuntu quyết định bạn có những cơ chế nào.

Tôi có nên tạo SSH key hậu lượng tử không?

Không, vì OpenSSH không có loại key này. Công việc hậu lượng tử hiện tại chỉ áp dụng cho trao đổi khóa, không cần bạn cung cấp key file hoặc cấu hình nào. Host key và key đăng nhập vẫn dùng chữ ký cổ điển như Ed25519 và RSA. Dự án upstream cho biết chữ ký hậu lượng tử sẽ được bổ sung trong bản phát hành tương lai. Tiếp tục dùng key Ed25519 và bảo vệ nơi lưu trữ key.

Tại sao ssh cảnh báo rằng kết nối của tôi không có tính hậu lượng tử?

OpenSSH 10.1 trở lên in ** WARNING: connection is not using a post-quantum key exchange algorithm. khi cơ chế trao đổi khóa đã thương lượng không có thành phần hậu lượng tử. Cảnh báo này liên quan đến server, không phải client, vì client của bạn đã cung cấp tên hậu lượng tử nhưng server không chấp nhận tên nào trong số đó. Nâng cấp OpenSSH trên server, hoặc kiểm tra xem có ai cố định dòng KexAlgorithms trong sshd_config khiến các tên hiện đại bị loại trừ hay không. Đặt WarnWeakCrypto no chỉ ẩn thông báo và không thay đổi mức độ yếu của kết nối.