Lịch sử SSH: từ telnet đến OpenSSH và hậu lượng tử

Lịch sử SSH bắt đầu từ những mật khẩu bị đánh cắp

Lịch sử SSH bắt đầu từ những mật khẩu bị đánh cắp. Trước năm 1995, đăng nhập vào một máy Unix từ xa nghĩa là dùng telnet hoặc rlogin, và cả hai đều gửi mật khẩu qua mạng dưới dạng văn bản có thể đọc được. Bất kỳ ai có khả năng theo dõi lưu lượng mạng đều có thể đọc chúng, và đến đầu những năm 1990, việc này đã diễn ra trên quy mô lớn.

SSH là câu trả lời của một người cho vấn đề đó. Nó được viết vào năm 1995 và phát hành miễn phí. Giao thức này đã được xây dựng lại một lần kể từ đó, còn chương trình mà hầu hết mọi người sử dụng ngày nay là một fork của một fork. Các mốc thời gian dưới đây rất quan trọng, vì mỗi bước đều là phản ứng trước một lỗi cụ thể.

Telnet và rlogin thực sự gửi gì

Telnet được định nghĩa trong RFC 854, do Jon Postel và Joyce Reynolds công bố vào tháng 5 năm 1983. Telnet mô tả một phiên terminal chạy trên TCP và không có bất kỳ cơ chế mã hóa nào. Mọi byte bạn nhập, bao gồm cả password, đều truyền dưới dạng byte thuần mà mọi thiết bị trên đường truyền đều có thể đọc.

rlogin xuất phát từ Berkeley Unix và được mô tả sau đó trong RFC 1282 (BSD Rlogin, B. Kantor, tháng 12 năm 1991). Nó bổ sung một thứ còn nguy hiểm hơn password có thể đọc được: cơ chế tin cậy dựa trên host. Server có thể được cấu hình để chấp nhận login từ một host cụ thể mà không cần password. RFC này có một section tên là "A Cautionary Tale", trong đó viết: "Bypassing password authentication from trusted hosts opens ALL the systems so configured when just one is compromised." RFC cũng lưu ý rằng cơ chế tin cậy này dựa trên hostname, nên một vụ compromise DNS (domain name system) hoặc một địa chỉ giả mạo có thể vô hiệu hóa nó.

Cả hai thiết kế này phù hợp với network nơi chúng ra đời. Ethernet thời kỳ đầu là một shared medium: mọi machine trên một segment đều nhận được mọi frame và được kỳ vọng sẽ bỏ qua những frame không gửi đến mình. Một machine không còn bỏ qua các frame đó — tức đang chạy ở promiscuous mode — sẽ thấy traffic của mọi machine khác. Khi một trường đại học cấp shell account cho hàng nghìn sinh viên, chỉ một account bị compromise cũng có thể trở thành công cụ thu thập password của cả một department.

Tư vấn bảo mật năm 1994 không kèm bản sửa lỗi

Ngày 3 tháng 2 năm 1994, CERT công bố tư vấn bảo mật CA-94:01, “Các cuộc tấn công giám sát mạng đang diễn ra”. Tài liệu này cho biết kẻ xâm nhập đã thu thập thông tin truy cập của hàng chục nghìn hệ thống trên Internet. Công cụ được sử dụng đã chuyển network interface sang promiscuous mode và ghi lại phần đầu của mọi phiên telnet, rlogin và FTP mới. Đây là phần chứa username và password.

CERT khuyến nghị các site đổi password cho mọi account được truy cập qua mạng. Đặt khuyến nghị đó trong bối cảnh các protocol này thì vấn đề rất rõ: password mới vẫn đi qua cùng đường truyền dưới dạng clear text trong lần đầu được sử dụng. Không thể sửa lỗi bên trong telnet hoặc rlogin, vì cả hai protocol đều không có chỗ để triển khai cơ chế đó.

Vì sao một cuộc tấn công nghe lén ở Helsinki tạo ra SSH

Năm 1995, mạng tại Đại học Công nghệ Helsinki bị tấn công nghe lén mật khẩu theo kiểu CERT đã mô tả. Tatu Ylönen, một nhà nghiên cứu tại đó, đã viết một chương trình thay thế và phát hành dưới dạng freeware vào tháng 7 năm 1995. Ông đặt tên cho nó là Secure Shell.

Hai quyết định thiết kế đã giúp Secure Shell thành công. Phiên làm việc được mã hóa, nên một listener trên segment không thể lấy được thông tin hữu ích. Server xác thực danh tính bằng một key, nên client có thể biết mình đã kết nối đúng máy hay chưa. Đây là lỗ hổng mà cơ chế tin cậy hostname của rlogin để lại.

Secure Shell cũng nhanh chóng được sử dụng vì các command của nó giống với những command người dùng đã gõ trước đó. ssh thay cho rsh và rlogin, còn scp thay cho rcp. Việc chuyển đổi chỉ thay đổi thói quen, không thay đổi workflow. Đến cuối năm 1995, số người dùng đã đạt khoảng 20,000 người tại 50 quốc gia. Tháng 12 năm đó, Ylönen thành lập SSH Communications Security để phát triển và bán phần mềm này.

Từ một bản phát hành miễn phí thành sản phẩm thương mại

Khi SSH trở thành một hoạt động kinh doanh, giấy phép của source code cũng thay đổi. Các bản phát hành sau đó có thêm các điều khoản giới hạn những gì người khác có thể làm với code, và bản phát hành cuối cùng mà bất kỳ ai cũng có thể tự do tái sử dụng là ssh 1.2.12. Điều đó hoàn toàn không có gì sai. Nó chỉ có nghĩa là phiên bản SSH mà phần còn lại của thế giới có thể tiếp tục xây dựng đã ngừng phát triển, trong khi việc phát triển vẫn tiếp diễn ở nơi mà thế giới đó không thể theo dõi. Giấy phép quyết định code nào được duy trì, một mô hình đáng để tìm hiểu trong cách việc cấp phép mã nguồn mở định hình hạ tầng hiện đại.

Vì sao OpenBSD fork OpenSSH vào năm 1999

Đầu năm 1999, Björn Grönvall quay lại bản phát hành cuối cùng còn miễn phí đó và bắt đầu sửa lỗi. Phiên bản của ông có tên OSSH và chỉ hỗ trợ protocol SSH 1.3.

Dự án OpenBSD tiếp nhận OSSH và xây dựng lại nó. Theo lời kể của chính dự án, Theo de Raadt, Niels Provos, Markus Friedl, Bob Beck, Aaron Campbell và Dug Song đã làm công việc làm sạch, audit và mở rộng code. Kết quả là OpenSSH 1.2.2, được phát hành cùng OpenBSD 2.6 vào ngày 1 tháng 12 năm 1999.

Vì sao một fork do một dự án operating system nhỏ thực hiện lại xuất hiện trên gần như mọi máy? Vì những gì OpenBSD cần ở nó. OpenBSD phát hành một base system đã được audit và được thiết kế để an toàn với cấu hình mặc định. Vì vậy, remote login được mã hóa phải nằm trong base system đó và sử dụng một license không kèm hạn chế. Code đã được audit dưới một license không hạn chế chính xác là thứ mà mọi vendor operating system khác cũng cần. Damien Miller, Philip Hands và những người khác gần như ngay lập tức bắt đầu một nhánh portable. Đây là nguồn gốc của p trong một version như 10.5p1. OpenBSD phát triển phiên bản sạch, còn nhánh portable bổ sung phần glue cho mọi môi trường khác. Cách Unix tách thành các system mà chúng ta đang chạy hiện nay là lý do phần glue đó cần thiết.

Hỗ trợ protocol phiên bản thứ hai được bổ sung sau đó. OpenSSH 2.0 được phát hành cùng OpenBSD 2.7 vào ngày 15 tháng 6 năm 2000.

Vì sao SSH-2 là một protocol mới thay vì chỉ tăng số phiên bản

SSH-1 bảo vệ tính toàn vẹn của encrypted stream bằng CRC-32, một checksum được thiết kế để phát hiện lỗi truyền dữ liệu thay vì chống lại attacker. Năm 1998, Ariel Futoransky và Emiliano Kargieman của CORE SDI đã chỉ ra hậu quả của thiết kế này. Với các cipher mode CBC hoặc CFB và kiểm tra CRC-32, attacker chỉ cần biết 16 byte plaintext là có thể chèn ciphertext do mình chọn, rồi khiến phía nhận chấp nhận nó là dữ liệu hợp lệ. Điều đó cho phép chạy command trên server.

Lỗ hổng nằm trong protocol nên không thể sửa mà vẫn giữ compatibility. Thay vào đó, các implementation phát hành một detector: đoạn code trong file có tên deattack.c, dùng để nhận diện cuộc tấn công khi nó đang xảy ra. Tháng 2 năm 2001, detector này được phát hiện có một integer overflow riêng, CVE-2001-0144. Lỗi này cho phép thực thi code từ xa trên các server và client đã cài patch. Một thiết kế không thể sửa triệt để sẽ tiếp tục tích lũy patch, còn patch lại tạo ra các bug riêng.

SSH-2 được xây dựng trong một IETF working group có tên secsh và được công bố dưới dạng RFC vào tháng 1 năm 2006: kiến trúc trong RFC 4251, transport layer trong RFC 4253, user authentication trong RFC 4252 và connection layer trong RFC 4254. Việc chia thành các layer là phần quan trọng, vì mỗi layer sau đó có thể được thay thế độc lập. Phần lớn lịch sử còn lại là quá trình thay thế đó.

Có 2 thay đổi nổi bật. Cơ chế bảo vệ integrity chuyển từ CRC-32 sang HMAC (hash-based message authentication code), sử dụng shared secret làm key. Vì vậy, attacker không thể tính MAC sẽ không thể giả mạo packet. Cơ chế key agreement cũng chuyển sang Diffie-Hellman. Trong SSH-1, client chọn session key rồi gửi key đó sau khi mã hóa bằng RSA key của server. Vì vậy, bất kỳ ai lấy được private key đó sau này đều có thể giải mã session đã ghi lại. Diffie-Hellman tạo ra một secret mới cho mỗi session và secret này không bao giờ được truyền đi. Do đó, việc ghi lại traffic rồi đánh cắp host key sau này không mang lại thông tin gì. Tính chất này được gọi là forward secrecy.

SSH-2 không có wire compatibility với SSH-1. Vì vậy, số protocol đã thay đổi thay vì chỉ tăng số thập phân.

Vì sao SSH-1 bị loại bỏ thay vì sửa chữa

Quá trình loại bỏ kéo dài qua ba bản phát hành OpenSSH. Phiên bản 7.0, phát hành ngày 11 August 2015, tắt protocol 1 theo mặc định ngay từ lúc compile. Phiên bản 7.4, phát hành ngày 19 December 2016, loại bỏ hỗ trợ protocol này ở phía server. Phiên bản 7.6, phát hành ngày 3 October 2017, cũng xóa phần client, cùng các tùy chọn cấu hình và tài liệu liên quan.

Giữ protocol này dưới dạng tùy chọn cho thiết bị cũ sẽ thân thiện hơn, nhưng detector CRC-32 cho thấy vì sao lựa chọn đó bị từ chối. Lỗi overflow chỉ có thể bị khai thác vì code của protocol 1 vẫn được compile, và code đó nằm trong một luồng xử lý mà hầu hết quản trị viên tin là không được dùng trên hệ thống của họ. Code đã được release thì vẫn có thể bị truy cập. Code đã bị xóa thì không thể.

Vì sao kết nối SSH đầu tiên cảnh báo về host key

Mã hóa cho biết lưu lượng được giữ riêng tư. Nó không cho biết ai đang ở đầu bên kia. Nếu kẻ tấn công nằm trên đường truyền và trả lời thay cho server của bạn, bạn sẽ có một phiên được mã hóa hoàn toàn với kẻ tấn công. Đây là cuộc tấn công machine-in-the-middle. SSH xử lý việc này bằng host key: server chứng minh rằng nó đang giữ phần private của một cặp key, còn client kiểm tra key đó với giá trị đã ghi nhận lần trước. Nếu muốn biết cơ chế của chính kết nối này, xem điều gì xảy ra khi bạn mở một kết nối SSH.

Ở lần kết nối đầu tiên không có lần trước, nên client không có gì để so sánh và phải hỏi bạn:

The authenticity of host 'vps.example.com (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:BQ0Qs2jVXhH2lPZ2rM0aQ0mQ8f9pQ0m3nH0oQ1bYqkE.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Trả lời yes sẽ lưu key đó vào ~/.ssh/known_hosts. Ở mọi lần kết nối sau, client sẽ so sánh với giá trị đã lưu. Nếu không khớp, chương trình sẽ hiển thị cảnh báo nghiêm trọng nhất:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Hiểu đúng prompt đầu tiên là: protocol đang thừa nhận một thời điểm yếu duy nhất của nó. Trust on first use có nghĩa là kết nối đầu tiên chỉ an toàn ngang với mạng mà bạn dùng để tạo kết nối đó. Bạn có thể thu hẹp khoảng trống này. Hãy đọc fingerprint từ console của nhà cung cấp hoặc build log của server trước khi kết nối. Bạn cũng có thể công bố fingerprint trong DNS dưới dạng bản ghi SSHFP (RFC 4255), nhưng chỉ nên làm vậy khi bạn có DNSSEC. Hoặc ký host key bằng certificate authority (CA) của riêng bạn, để client tin CA thay vì tin từng key riêng lẻ. Trên thực tế, hầu hết mọi người chấp nhận prompt mà không kiểm tra. Cần thừa nhận rõ điều đó.

Vì sao public key đã thay thế password

Xác thực bằng public key đã có từ những bản phát hành SSH đầu tiên, nhưng phải mất nhiều năm mới trở thành cách dùng mặc định. Cơ chế này là bất đối xứng: client chứng minh mình giữ private key bằng cách ký một challenge, còn private key không bao giờ rời khỏi client. Password hoạt động theo cách ngược lại. Dù SSH truyền password bên trong encrypted channel, server vẫn nhận được secret thực tế. Vì vậy, nếu server bị breach hoặc bị kẻ xấu kiểm soát, secret đó có thể bị dùng lại để tấn công bạn ở nơi khác.

Lý do thứ hai là bài toán xác suất. Bất kỳ server nào mở cổng 22 trên địa chỉ public đều nhận các lần thử đăng nhập tự động suốt ngày đêm, còn password chỉ là một chuỗi có thể đoán. Key không thể bị đoán theo bất kỳ cách thực tế nào. Thiết lập PasswordAuthentication no sẽ loại bỏ hoàn toàn nhóm tấn công này, vì vậy nó xuất hiện trong mọi checklist hardening. Thiết lập này cũng loại bỏ phương án dự phòng từng giúp bạn khôi phục quyền truy cập khi key gặp lỗi. Vì vậy, hãy học cách phân biệt các lỗi khác nhau đều trả về Permission denied (publickey) trước khi chính bạn bị khóa ngoài. Không dùng password cũng có nghĩa là phải tích lũy nhiều key. Một agent đang giữ hàng chục key sẽ lần lượt thử từng key cho đến khi server chạm giới hạn số lần thử và đóng kết nối. Đây là lý do đăng nhập có thể thất bại với Too many authentication failures dù key đúng đã được nạp. Cách tạo và thay phiên key được trình bày trong Kiến thức cơ bản về quản lý SSH key, còn các thiết lập phía server nằm trong Hardening SSH trên VPS.

Vì sao danh sách thuật toán SSH liên tục thay đổi

Một giao thức phân lớp cho phép loại bỏ thuật toán mà không cần tạo giao thức mới. OpenSSH đã liên tục tận dụng khả năng này, và ngày phát hành cho thấy tốc độ thay đổi.

Ed25519 xuất hiện trong OpenSSH 6.5 vào ngày 30 January 2014, cùng với cipher chacha20-poly1305 và định dạng private key được bảo vệ bằng bcrypt. Chữ ký Ed25519 tạo nonce cho từng chữ ký theo cách xác định, nên trình tạo số ngẫu nhiên yếu tại thời điểm ký không thể làm lộ private key. Đây chính xác là cách private key DSA và ECDSA đã bị khôi phục trong các sự cố thực tế.

DSA đi theo hướng ngược lại. OpenSSH 7.0 vô hiệu hóa ssh-dss host key và user key khi chạy vào năm 2015, vì thuật toán này bị giới hạn ở private key 160-bit và SHA-1. Version 9.8, vào ngày 1 July 2024, vô hiệu hóa DSA tại thời điểm compile. Version 10.0, vào ngày 9 April 2025, xóa DSA, theo cách nói của dự án là "hoàn tất quy trình loại bỏ đã bắt đầu từ năm 2015". Mười năm từ lúc vô hiệu hóa đến lúc bị xóa.

RSA không biến mất, nhưng định dạng chữ ký cũ của nó thì có. OpenSSH 8.8, vào ngày 26 September 2021, mặc định ngừng chấp nhận chữ ký RSA tạo bằng SHA-1. Ghi chú phát hành nêu rõ lý do: SHA-1 đã bị phá vỡ về mặt mật mã, và có thể tạo collision với chosen-prefix với chi phí dưới USD 50,000. Nếu bạn từng gặp sign_and_send_pubkey: no mutual signature supported khi kết nối đến một server cũ, đó chính là thay đổi này. Key của bạn vẫn bình thường. Thuật toán chữ ký mà đầu bên kia yêu cầu thì không.

Quy trình tương tự hiện đang được áp dụng cho key exchange, lần này là để đón đầu mối đe dọa. Lưu lượng được capture hôm nay có thể được lưu lại và giải mã nhiều năm sau bởi bên đầu tiên sở hữu một máy tính lượng tử đủ năng lực, nên cơ chế thỏa thuận key phải thay đổi trước khi máy như vậy tồn tại. OpenSSH 9.0, vào ngày 8 April 2022, đặt hybrid key exchange làm mặc định: sntrup761x25519-sha512@openssh.com ghép một thuật toán hậu lượng tử với exchange X25519, nên kết quả không yếu hơn phần cổ điển nếu thuật toán mới không đạt yêu cầu. OpenSSH 9.9, vào ngày 19 September 2024, thêm mlkem768x25519-sha256, được xây dựng trên ML-KEM (module lattice key encapsulation mechanism), do NIST chuẩn hóa vào năm 2024. OpenSSH 10.0 đặt thuật toán này làm mặc định cho key agreement, và trang hậu lượng tử của dự án giải thích lý do. OpenSSH 10.1, vào ngày 6 October 2025, bắt đầu cảnh báo khi đầu bên kia không hỗ trợ thuật toán này:

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

Cảnh báo này được bật mặc định và được điều khiển bằng tùy chọn WarnWeakCrypto trong ssh_config. Trên thực tế, cảnh báo này có ý nghĩa gì và cần làm gì với server kích hoạt cảnh báo được trình bày trong các mặc định key exchange SSH hậu lượng tử.

Ý nghĩa của lịch sử này đối với server trước mặt bạn

Lệnh bạn nhập gần như không thay đổi kể từ năm 1995. Gần như mọi thành phần bên dưới nó đã được thay thế: cơ chế kiểm tra integrity, quá trình trao đổi key, các thuật toán chữ ký và chính code base. Điều này chỉ thực hiện được vì mỗi lần thay thế đều kết thúc bằng việc chủ động loại bỏ thành phần cũ, và mỗi lần loại bỏ đều làm hỏng một thứ nào đó đối với một số người dùng.

Vì vậy, bảo mật SSH của bạn chủ yếu được quyết định bởi version. Các giá trị mặc định chứa những quyết định về thuật toán nào được cung cấp, thuật toán nào bị từ chối và những cảnh báo nào bạn nhìn thấy. Một server cũ vẫn tiếp tục cung cấp mọi thứ mà bản release của nó còn cho phép, đồng thời vẫn hạ mức thương lượng để tương thích với client cũ. Tính đến tháng 8 năm 2026, bản release hiện tại là OpenSSH 10.5, được phát hành vào ngày 11 tháng 8 năm 2026. Khoảng cách giữa bản này và version trên một máy chưa được ai đụng đến trong 3 năm cho thấy quy mô của vấn đề. Việc kiểm tra version đó nên nằm trong 10 phút đầu tiên trên một VPS mới.

Câu hỏi thường gặp (FAQ)

Ai đã tạo ra SSH và vì sao?

Tatu Ylönen, một nhà nghiên cứu tại Helsinki University of Technology, đã viết SSH vào năm 1995 sau một cuộc tấn công sniffing mật khẩu trên mạng của trường đại học. Các công cụ đăng nhập từ xa thời đó như telnet và rlogin gửi mật khẩu qua mạng dưới dạng văn bản đọc được, nên bất kỳ ai monitor một segment dùng chung cũng có thể thu thập credential khi chúng đi qua. Ông phát hành chương trình dưới dạng freeware vào tháng 7 năm 1995. Đến cuối năm đó, chương trình có khoảng 20,000 người dùng tại năm mươi quốc gia. Tháng 12 năm 1995, ông thành lập SSH Communications Security.

SSH-1 và SSH-2 khác nhau như thế nào?

Đây là hai protocol khác nhau và không tương thích trên wire. SSH-1 là một protocol nguyên khối, dùng CRC-32 để kiểm tra tính toàn vẹn và để client gửi session key được mã hóa bằng RSA key của server. SSH-2 chia công việc thành transport layer, authentication layer và connection layer (RFC 4251 đến RFC 4254, tháng 1 năm 2006), dùng HMAC để kiểm tra tính toàn vẹn và tạo session key bằng Diffie-Hellman. Vì vậy, traffic đã ghi lại vẫn được giữ riêng tư ngay cả khi host key bị đánh cắp về sau. SSH-1 bị loại khỏi OpenSSH theo từng giai đoạn, kết thúc ở version 7.6 vào tháng 10 năm 2017.

Vì sao OpenSSH thay thế implementation SSH ban đầu?

Việc phát triển implementation ban đầu chuyển sang một sản phẩm thương mại có license hạn chế, còn release cuối cùng có thể tự do tái sử dụng là ssh 1.2.12. Đầu năm 1999, Björn Grönvall khôi phục release đó thành OSSH. Sau đó, team OpenBSD fork OSSH thành OpenSSH và đưa nó vào OpenBSD 2.6 ngày 1 tháng 12 năm 1999. OpenBSD cần code đã được audit với license không hạn chế cho base system. Hai đặc điểm này cho phép mọi operating system khác ship cùng implementation thông qua portable branch.

Vì sao SSH hỏi về host key trong lần đầu tôi kết nối?

Vì client chưa từng thấy server đó và không có giá trị nào để đối chiếu key của server. Chỉ mã hóa không đủ để phân biệt server hợp lệ với một máy đang đứng giữa đường truyền. Vì vậy, SSH nhận diện server bằng key và ghi lại giá trị đã thấy trong ~/.ssh/known_hosts. Lần kết nối đầu tiên là thời điểm duy nhất không có giá trị đã lưu để kiểm tra, nên client phải hỏi bạn. Hãy đối chiếu fingerprint với fingerprint lấy từ provider console hoặc trực tiếp trên server. Hãy xem mọi thông báo REMOTE HOST IDENTIFICATION HAS CHANGED về sau là một sự kiện thực sự cho đến khi bạn giải thích được nguyên nhân.

Vì sao các SSH key cũ ngừng hoạt động sau khi upgrade?

Vì OpenSSH loại bỏ algorithm theo một lịch trình đã công bố. Key DSA (ssh-dss) bị tắt mặc định trong OpenSSH 7.0 vào năm 2015 và bị loại bỏ hoàn toàn trong OpenSSH 10.0 ngày 9 tháng 4 năm 2025. RSA key vẫn hoạt động, nhưng chữ ký tạo bằng SHA-1 bị tắt mặc định trong OpenSSH 8.8 vào tháng 9 năm 2021. Khi kết nối đến server cũ, lỗi này hiển thị dưới dạng sign_and_send_pubkey: no mutual signature supported. Ed25519 key, được hỗ trợ từ OpenSSH 6.5 vào tháng 1 năm 2014, tránh được cả hai vấn đề.