Khi nhắc đến quản trị server, SSH là chuẩn mực không thể thay thế. Tuy nhiên, phiên bản SSH2 bạn dùng hàng ngày (với port là 22/TCP) đã có tuổi đời hơn 20 năm. Trong bối cảnh hạ tầng mạng hiện đại chuyển dịch sang Cloud và mô hình Zero Trust, những hạn chế về độ trễ TCP handshake và kiến trúc cũ bắt đầu lộ diện.
Đó là lúc dự án SSH3 xuất hiện. Đây không chỉ là một bản nâng cấp, mà là một sự thay đổi hoàn toàn về giao thức vận chuyển: SSH3 chạy trên HTTP/3 và QUIC (UDP) thay vì TCP thuần túy.

Bài viết này mình sẽ cùng bạn mổ xẻ kiến trúc và thực hiện một bài lab chi tiết để thấy sự khác biệt của nó.
SSH3 khác gì SSH2?
Để hiểu sâu, bạn cần nhìn vào tầng Transport.
SSH2 (OpenSSH hiện tại):
- Chạy trên TCP.
- Khi kết nối, nó phải thực hiện TCP Handshake (3 bước), sau đó mới đến SSH Protocol Handshake.
- Nếu mạng bị mất gói tin, TCP sẽ gây ra hiện tượng head-of-line blocking, làm nghẽn toàn bộ kết nối. Đây là lý do khi mạng lag, bạn gõ phím thấy terminal bị đơ một lúc rồi chữ mới hiện ra hàng loạt.
SSH3:
- Chạy trên QUIC (UDP) và HTTP/3.
- QUIC giải quyết vấn đề độ trễ bằng cách gộp quá trình handshake của kết nối và mã hóa (TLS 1.3) lại làm một.
- Giải quyết vấn đề “Head-of-line blocking”: Mất gói tin nào chỉ ảnh hưởng stream đó, các thao tác khác vẫn mượt.
- Hỗ trợ Roaming (Connection Migration): Bạn đang dùng Wifi công ty, chuyển sang 4G, kết nối SSH không bị đứt (do QUIC dùng Connection ID thay vì IP:Port để định danh).
Chuẩn bị môi trường Lab
Để bài lab này có giá trị, mình khuyên bạn nên chuẩn bị 2 máy ảo Linux (Ubuntu/Debian/CentOS đều được) để thấy rõ quá trình giao tiếp qua mạng:
- Server (SSH3 Server): IP ví dụ
192.168.1.100(đóng vai trò máy chủ cần remote). - Client (SSH3 Client): IP ví dụ
192.168.1.200(máy laptop của bạn).
Yêu cầu tiên quyết:
- Cả 2 máy đều đã cài Golang phiên bản mới nhất (tối thiểu 1.21 trở lên là tốt nhất để hỗ trợ thư viện QUIC).
- Firewall trên Server phải mở port UDP (lưu ý là UDP nhé, không phải TCP).
Bước 1: Build Core SSH3 từ Source
Bạn sẽ không dùng binary có sẵn mà build trực tiếp để đảm bảo mã nguồn mới nhất. Thực hiện thao tác này trên cả Server và Client.
Bạn gõ lệnh:
git clone https://github.com/francoismichel/ssh3
cd ssh3
go build -o ssh3 cmd/ssh3/main.go
Sau khi build xong, copy file thực thi ssh3 vào /usr/local/bin/ để gọi lệnh cho tiện:
sudo cp ssh3 /usr/local/bin/
Bước 2: Thiết lập Server
Đây là điểm khác biệt lớn nhất so với SSH2. Vì SSH3 sử dụng giao thức QUIC/HTTP3, nên nó hoạt động gần giống một Web Server bảo mật. Bắt buộc phải có TLS Certificate.
Trong môi trường thực tế, bạn sẽ dùng Let’s Encrypt hoặc chứng chỉ mua. Nhưng trong lab này, bạn sẽ tạo Self-signed Certificate.
Tại máy Server (192.168.1.100):
Tạo thư mục chứa cert và key:
mkdir -p /etc/ssh3/ keys
Tạo Self-signed Certificate bằng OpenSSL (lệnh này tạo ra cert có thời hạn 1 năm):
openssl req -x509 -newkey rsa:4096 -sha256 -days 365 \
-nodes -keyout /etc/ssh3/server_key.pem \
-out /etc/ssh3/server_cert.pem \
-subj "/CN=192.168.1.100"
Note: Phần CN=192.168.1.100 bạn thay bằng IP hoặc Domain thật của server nhé.
Bây giờ, bạn sẽ dựng SSH3 Server chạy trên port 4433 (port UDP):
# Cấu trúc lệnh: ssh3 server --bind [IP:PORT] --cert [Path Cert] --key [Path Key]
sudo ssh3 server --bind 0.0.0.0:4433 \
--cert /etc/ssh3/server_cert.pem \
--key /etc/ssh3/server_key.pem \
--enable-password-login
Giải thích: Tôi dùng flag --enable-password-login để test nhanh. Trong thực tế, bạn sẽ ưu tiên dùng Public Key Auth (tương tự id_rsa.pub của SSH2) để bảo mật hơn.
Bước 3: Kết nối từ Client và xử lý Trust
Bây giờ chuyển sang máy Client (192.168.1.200).
Nếu bạn chạy lệnh kết nối thông thường, chắc chắn sẽ lỗi. Tại sao? Vì Client không tin tưởng cái Self-signed Certificate mà bạn vừa tạo ở Server. Đây là cơ chế bảo mật mặc định của TLS.
Để kết nối được trong môi trường Lab, bạn có 2 cách: import CA hoặc bỏ qua xác thực. Để nhanh gọn cho việc test, tôi sẽ dùng flag bỏ qua xác thực cert.
bạn chạy lệnh:
# Cấu trúc: ssh3 connect [user]@[IP]:[PORT] --insecure
./ssh3 connect root@192.168.1.100:4433 --insecure
Nếu server hỏi password user root (hoặc user bạn login), nhập đúng password hệ thống linux là sẽ vào được shell.
Bạn vừa thực hiện một phiên SSH session qua giao thức HTTP/3.
Bước 4: Cái gì thực sự diễn ra bên dưới?
Để chứng minh đây là công nghệ mới chứ không phải “bình mới rượu cũ”, tôi khuyến khích bạn dùng tcpdump hoặc wireshark để bắt gói tin trên Server trong lúc kết nối.
Trên Server, bạn mở terminal khác và chạy:
sudo tcpdump -i eth0 port 4433 -n
Bạn sẽ thấy gì?
- Giao thức là UDP: bạn sẽ không thấy cờ
SYN,ACKcủa TCP đâu cả. Toàn bộ là gói tin UDP. - Handshake cực nhanh: Nếu SSH2 mất khoảng 5-7 round-trip để xong việc trao đổi khóa và thuật toán, thì SSH3 với QUIC 1-RTT (thậm chí 0-RTT trong lần kết nối lại) sẽ đẩy tốc độ setup session lên cực nhanh.
- Roaming: Đây là cái hay nhất. bạn thử kết nối SSH3, sau đó rút dây mạng Client ra, cắm sang mạng Wifi khác (đổi IP Client).
- Với SSH2: Kết nối đứt ngay lập tức (Broken pipe).
- Với SSH3/QUIC: Connection ID vẫn giữ nguyên, session vẫn sống. bạn gõ lệnh tiếp vẫn chạy bình thường. Đây là tính năng “Connection Migration” cực mạnh của QUIC, rất lợi hại cho bạn nào hay phải di chuyển hoặc dùng mạng 4G chập chờn.
Thiết lập xác thực bằng Public Key
Dùng password là hạ sách. Giờ ta cấu hình SSH Key giống như cách làm truyền thống nhưng trên nền SSH3.
Tại client:
Tạo cặp key SSH3 (thực chất nó dùng thuật toán Ed25519 hoặc RSA chuẩn): SSH3 hiện tại có thể tái sử dụng key của SSH2, nhưng để đúng bài bản của repo, bạn sẽ generate key mới.
# Tại client, tạo key
ssh-keygen -t ed25519 -f ~/.ssh/id_ssh3
Tại server:
Bạn cần copy nội dung file public key (~/.ssh/id_ssh3.pub) từ máy Client và dán vào file ~/.ssh3/authorized_identities trên Server (Lưu ý: SSH3 dùng file config riêng, không dùng chung authorized_keys của SSH2 để tránh xung đột).
# Tại Server (với user bạn muốn login)
mkdir -p ~/.ssh3
nano ~/.ssh3/authorized_identities
# Dán public key của client vào đây và lưu lại
Kết nối lại từ Client:
ssh3 connect user@192.168.1.100:4433 --privkey ~/.ssh/id_ssh3 --insecure
Lúc này, bạn sẽ login thẳng vào server mà không cần password, với tốc độ handshake của tên lửa.
Lời kết
SSH3 không chỉ là một tool mới, nó là minh chứng cho việc giao thức mạng đang dịch chuyển mạnh mẽ từ TCP sang UDP/QUIC.
Sau khi dựng xong bài lab này tuy không quá khó, tôi rút ra vài điểm cốt lõi để bạn cân nhắc:
- Vấn đề Firewall: Nếu công ty bạn chặn UDP (điều này khá phổ biến ở các firewall doanh nghiệp cũ), SSH3 sẽ “chết đứng”. Đây là rào cản lớn nhất khi triển khai thực tế.
- Quản lý Certificate: Với SSH2, ta chỉ lo quản lý Key. Với SSH3, ta phải lo thêm việc quản lý hạn sử dụng của SSL Certificate. Nếu cert hết hạn, SSH tịt. Đây là thêm một lớp phức tạp cho SysAdmin.
- Hiệu năng: Trên đường truyền ổn định, bạn sẽ không thấy khác biệt nhiều. Nhưng hãy thử dùng
tc(traffic control) để giả lập packet loss 20% và latency cao, SSH3 sẽ “ăn đứt” SSH2 nhờ cơ chế phục hồi gói tin của QUIC.






