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

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

SSH hậu lượng tử đã được bật sẵn cho hầu hết người dùng, và bạn không cần cấu hình gì. 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 khóa hậu lượng tử hybrid. Vì vậy, session key vẫn chống được kẻ tấn công ghi lại 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 ý 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 làm rõ 2 thuật ngữ. SSH (secure shell) là protocol dùng để đăng nhập vào server. Trao đổi khóa, 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ống nhất một shared secret, rồi secret đó mã hóa toàn bộ dữ liệu tiếp theo. Phần đã thay đổi là trao đổi khóa. Các phần khác không thay đổi.

Không được tin trang này, hãy tự chạy các lệnh

Mọi tên thuật toán dưới đây đều lấy từ một lệnh mà bạn có thể tự chạy. Đây là chủ ý. Giá trị mặc định thay đổi theo từng bản phát hành OpenSSH, vì vậy một hướng dẫn được viết cách đây 2 năm có thể nêu một thuật toán mà máy của bạn không còn ưu tiên, và hướng dẫn đó không có cách nào biết được. Hãy học các lệnh này để không còn cần đọc 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 bản build của bạn hỗ trợ những gì.

ssh -V
ssh -Q kex

ssh -V in một dòng phiên bản bắt đầu bằng OpenSSH_, tiếp theo là hậu tố package của Ubuntu và phiên bản OpenSSL. ssh -Q kex in mỗi thuật toán trao đổi khóa trên một dòng. Trên 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 thuật toán cổ điển như curve25519-sha256.

Bản build hỗ trợ gì không đồng nghĩa với việc nó đề xuất gì

Đây là điểm mà phần lớn bài viết 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 cần biết: kết nối này thực tế 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 sự.

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 này sẽ được gửi qua kết nối.

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, đã bổ sung 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ị thuật toán này còn ssh -G thì không, nghĩa là binary có thể thực hiện trao đổi khóa hậu lượng tử nhưng không có kết nối nào 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à thuật toán lai. Nó chạy ML-KEM (cơ chế đóng gói khóa dựa trên module-lattice, được chuẩn hóa thành FIPS 203) với bộ tham số 768, kết hợp 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á được nó. Đó là toàn bộ lý do giá trị mặc định đã 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ể kéo lùi cả session. 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. Thứ tự ưu tiên của client được giữ, nên đầu nào cũ hơn trong hai đầu sẽ quyết định kết nối đi được đến đâu trong danh sách. Nâng cấp laptop không thể nâng cấp session khi server chưa từng hỗ trợ ML-KEM.

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à phần tiếp theo sẽ nói đến:

debug1: kex: host key algorithm: ssh-ed25519

Bản OpenSSH nào đặt cơ chế trao đổi hybrid làm mặc định

Ghi chú phát hành 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 cơ chế này đã âm thầm hoạt động trong bao lâu.

• 8.5, phát hành ngày 2021-03-03, bổ sung 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 cơ chế này. Ghi chú nêu rằng OpenSSH sẽ “mặc định sử dụng phương thức trao đổi khóa hybrid Streamlined NTRU Prime + x25519”. Đây là bản phát hành trong đó trao đổi khóa 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, bổ sung mlkem768x25519-sha256 dưới dạng tùy chọn thứ hai. Bản phát hành này cũng đặt tên đã đăng ký với IANA cho phương thức cũ là sntrup761x25519-sha512, vì vậy các bản build mới liệt kê phương thức này bằng cả hai cách gọi.
• 10.0, phát hành ngày 2025-04-09, đặt mlkem768x25519-sha256 làm mặc định cho thỏa thuận khóa.
• 10.1, phát hành ngày 2025-10-06, bổ sung cảnh báo phía client khi kết nối thương lượng một phương thức trao đổi khóa không có thành phần hậu lượng tử. Tùy chọn này được điều khiển bởi WarnWeakCrypto trong ssh_config và được bật theo mặc định.

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

Phiên bản Ubuntu nào cung cấp nó

Ubuntu cố định phiên bản OpenSSH tại thời điểm 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, phiên bản Ubuntu bạn đang chạy quyết định thuật toán mặc định. Hãy kiểm tra chính máy đang dùng bằng ssh -V thay vì 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 cung cấp 1:8.9p1, cũ hơn mặc định của 9.0, nên bản cài đặt mặc định sẽ thương lượng curve25519-sha256.
• 24.04 LTS cung cấp 1:9.6p1, mới hơn 9.0 nhưng cũ hơn 9.9, nên mặc định là sntrup761x25519-sha512@openssh.com và không có ML-KEM.
• 25.10 cung cấp 1:10.0p1, với mặc định là mlkem768x25519-sha256.
• 26.04 LTS cung cấp 1:10.2p1, mặc định là mlkem768x25519-sha256 và cảnh báo về các kết nối không có tính hậu lượng tử.

Hãy xem 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 hậu lượng tử tiếp theo của client mà server cũng có là sntrup761x25519-sha512@openssh.com, và đó là tên mà ssh -v báo cáo. Phiên làm việc sử dụng trao đổi khóa hậu lượng tử, dù server được xây dựng vào năm 2024 và không ai cấu hình gì.

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, nhưng proposal mặc định lại loại nó ra, vì vậy quá trình thương lượng chọn curve25519-sha256. Khi dùng client OpenSSH 10.1 hoặc mới hơn, kết nối sẽ báo rõ đ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, không phải client của bạn. Cách xử lý là nâng cấp server. Đặt WarnWeakCrypto no sẽ xóa thông báo nhưng không thay đổi kết nối.

Vì sao dùng hybrid, và “thu thập bây giờ, 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ể xem lưu lượng 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 không thể đọc được dữ liệu đó. Chúng giữ dữ liệu cho đến khi có máy tính lượng tử đủ lớn để phá X25519, rồi giải mã chúng. Cách này được gọi là “thu thập bây giờ, giải mã sau”, hoặc “lưu trữ bây giờ, giải mã sau”. Hiện tại, kẻ tấn công không cần làm gì tinh vi. Chúng chỉ cần dung lượng đĩa và sự kiên nhẫn.

Mã hóa có vấn đề này, còn chữ ký thì không, và sự bất đối xứng đó quyết định mọi phần còn lại. 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, kẻ tấn công có thể mạo danh một server vào năm 2035. Việc đó không cho phép chúng quay lại giả mạo một lần đăng nhập từ năm 2026. Vì vậy, key exchange phải được xử lý trước; phần chữ ký có thể chờ.

Hybrid nghĩa là cả hai thuật toán đều chạy và cả hai kết quả đều được dùng để tạo session key. Để khôi phục secret phía sau mlkem768x25519-sha256, kẻ tấn công phải phá được ML-KEM 768 và X25519. Việc ghép cặp này là có chủ ý: ML-KEM mới hơn X25519 rất nhiều và có ít thời gian hơn để các nhà mật mã học phân tích, 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ó.

Cái gì được bảo vệ và cái gì không

Trao đổi khóa được bảo vệ. Shared secret dùng để mã hóa phiên của bạn được tạo ra từ một trao đổi lai, vì vậy bản ghi của phiên đó được lưu hôm nay sẽ không trở nên đọ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, tương tự rsa-sha2-512 và các loại ECDSA (elliptic curve digital signature algorithm). 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 đó, và không thể dùng cách này để tấn công lưu lượng đã ghi lại từ hôm nay.

Login key của bạn cũng không được bảo vệ. Key trong ~/.ssh/id_ed25519 là cùng loại chữ ký cổ điển, nên cũng áp dụng lập luận tương tự. Điều bảo vệ key đó trong năm nay là vị trí lưu trữ và những 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 hai loại key đó, vì hiện chưa có loại 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 phát hành tương lai. Cho đến khi tính năng đó được phát hành, OpenSSH không có host key type hậu lượng tử và cũng không có user key type hậu lượng tử; ssh-keygen cũng không cung cấp loại nào. Hướng dẫn yêu cầu bạn tạo 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, và nó thuộc một codebase khác với lịch 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à key exchange của certificate đó do OpenSSL và web server quyết định, nên hãy xem xét stack đó theo các điều kiện riêng của nó.

Việc quản trị viên thận trọng nên làm lúc này

Luôn cập nhật OpenSSH, rồi 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 do bản phát hành Ubuntu hiện tại cung cấp, còn nâng cấp lên bản phát hành 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 không cần giám sát sẽ tự áp dụng các bản vá mà bạn không cần nhớ để thực hiện. Tự build OpenSSH từ source chỉ để chạy theo tên thuật toán 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 dễ bị exposed nhất trên máy. Nếu vẫn tải source, hãy đối chiếu bản tải xuống với checksum đã 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 thường xuyê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 đúng vào năm 2018, nhưng dán danh sách đó vào sshd_config sẽ thay thế danh sách mặc định thay vì bổ sung vào đó. Mọi thuật toán được phát hành từ đó đến nay đều bị loại trừ, vì vậy server vốn có thể tự thương lượng mlkem768x25519-sha256 sẽ âm thầm hạ xuống bất kỳ thuật toán nào còn lại trong danh sách bị ghim. Hãy chạy sudo sshd -T | grep -i '^kexalgorithms' trên mọi server bạn kế thừa. Nếu dòng đó ngắn hơn dòng tương ứng trên một bản cài mới cùng bản phát hành, đã có người ghim danh sách.

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à loại bỏ, và ^ ở đầu là đưa lên đầu.

KexAlgorithms ^mlkem768x25519-sha256

Kiểm tra file trước khi dựa vào cấu hình đó. sudo sshd -t phân tích cấu hình và không in gì nếu cấu hình hợp lệ. Một dòng KexAlgorithms chứa thuật toán 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ử giao nhau, client sẽ thông 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 nội dung marketing về “an toàn trước máy tính lượng tử” là tuyên bố chỉ áp dụng cho một layer. Khi vendor gọi một sản phẩm là an toàn trước máy tính lượng tử, họ đang mô tả layer mà họ nêu tên, và layer đó thường là một cơ chế trao đổi key ở đâu đó. Hãy yêu cầu tên thuật toán 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à cơ chế trao đổi key đang dùng phương án hậu lượng tử hybrid, còn chữ ký vẫn là classical. Mọi tuyên bố rộng hơn phải đi kèm một 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. Cơ chế trao đổi key hậu lượng tử không giải quyết được password dễ đoán hoặc private key bị copy vào laptop rồi laptop đó bị đánh cắp. Đó mới là những nguyên nhân thực sự khiến server bị chiếm quyền, và hardening SSH tiêu chuẩn trên VPS vẫn đảm nhiệm gần như toàn bộ phần bảo vệ quan trọng. Nếu các bước negotiation ở đây còn xa lạ, SSH thực hiện 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 kháng lượng tử chưa?

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

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

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

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

Không, vì OpenSSH không có loại key như vậy. Hiện tại, các thay đổi kháng lượng tử chỉ áp dụng cho quá trình trao đổi khóa. Quá trình này không cần file key từ bạn và cũng không cần 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ý kháng lượng tử sẽ được bổ sung trong một 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 kháng lượng tử?

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