SSH là giao thức mạng cho phép truy cập và điều khiển server từ xa qua kênh truyền được mã hóa. Nếu bạn vừa thuê VPS lần đầu hoặc đang cần quản lý server Linux, thì SSH chính là công cụ bạn sẽ dùng mỗi ngày.
SSH sinh ra để giải quyết một vấn đề rất cụ thể – và nếu bạn hiểu vấn đề đó trước, cơ chế kỹ thuật phía sau sẽ tự nhiên có nghĩa hơn nhiều.
Contents
SSH (Secure Shell) là giao thức mạng cho phép bạn kết nối và điều khiển máy tính từ xa qua kênh truyền được mã hóa. SSH hoạt động theo mô hình client-server: SSH client trên máy bạn kết nối tới SSH server chạy trên máy đích, và mọi dữ liệu trao đổi giữa hai bên đều được mã hóa trước khi gửi đi.
Cổng mặc định của SSH là port 22. Giao thức này hoạt động ở tầng Application của mô hình TCP/IP và chạy được trên hầu hết hệ điều hành phổ biến: Linux, macOS, Windows (từ phiên bản 10 trở đi đã tích hợp sẵn OpenSSH client).
Trên thực tế, bốn trường hợp sử dụng phổ biến nhất của SSH là:
Năm 1995, Tatu Ylönen – kỹ sư tại Đại học Công nghệ Helsinki (Phần Lan) – phát hiện mạng nội bộ của trường bị tấn công bởi password sniffer (công cụ nghe lén mật khẩu). Công cụ này nghe lén toàn bộ traffic (luồng dữ liệu) trên mạng và chặn thông tin đăng nhập của hàng nghìn tài khoản, bởi vì giao thức đang dùng lúc đó là Telnet – truyền mọi dữ liệu dạng plaintext (văn bản thô, không mã hoá), kể cả mật khẩu (password).
Ylönen mất vài tháng để thiết kế và viết SSH, rồi phát hành miễn phí vào tháng 7/1995. Đây không phải dự án nghiên cứu lý thuyết, mà là giải pháp trực tiếp cho một vấn đề thực tế rất cụ thể: làm thế nào để bạn quản trị server từ xa mà kẻ nghe lén vẫn không đọc được thông tin?

Điểm mấu chốt cần nhớ là: SSH không phải “Telnet tốt hơn”. SSH là Telnet với toàn bộ dữ liệu được mã hóa, kể cả lúc bạn đang gõ password. Dù có ai nghe lén traffic trên mạng, họ cũng chỉ thấy chuỗi ký tự vô nghĩa – không có gì để khai thác.
Khi bạn gõ lệnh ssh user@server, có ba việc xảy ra theo thứ tự trước khi bạn thấy dấu nhắc lệnh của server. Thiếu bất kỳ lớp nào trong số đó, hai lớp còn lại cũng không đủ để bảo vệ bạn.

Rủi ro cần giải quyết: làm thế nào để client và server thống nhất được khóa mã hóa chung mà không phải truyền khóa đó qua mạng?
SSH giải quyết bằng Diffie-Hellman key exchange. Cả hai bên tự tính toán ra một “session key” chung từ các thông số công khai, mà hoàn toàn không cần gửi session key đó qua mạng. Kẻ nghe lén dù thấy các thông số trao đổi cũng không thể tính ngược lại session key, vì bài toán toán học phía sau đòi hỏi tài nguyên tính toán cực kỳ lớn.
Quan trọng hơn, session key (khoá phiên) chỉ tồn tại trong phiên làm việc hiện tại. Sang phiên sau, cả hai bên lại tạo session key hoàn toàn mới.
Rủi ro cần giải quyết: làm thế nào để server biết bạn thực sự là người được phép đăng nhập?
SSH hỗ trợ hai cách xác thực chính:
So sánh hai phương thức, bạn sẽ thấy sự khác biệt khá rõ:
|
Tiêu chí |
Password |
SSH key |
|
Rủi ro brute force (tấn công thử mật khẩu hàng loạt) |
Cao nếu mật khẩu yếu |
Gần như không thể |
|
Truyền secret (bí mật) qua mạng |
Có (dù đã mã hóa) |
Không (private key không bao giờ rời máy) |
|
Tiện lợi khi tự động hóa |
Cần nhập tay hoặc lưu plaintext |
Tự động hoàn toàn, an toàn |
|
Thu hồi khi bị lộ |
Đổi password toàn hệ thống |
Xóa public key cụ thể khỏi server |
Rủi ro cần giải quyết: làm thế nào để đảm bảo mọi lệnh và dữ liệu bạn trao đổi trong phiên làm việc không bị đọc trộm hoặc chỉnh sửa?
Sau khi xác thực xong, toàn bộ dữ liệu được mã hóa bằng symmetric encryption (mã hoá đối xứng) dùng session key từ bước 1. Symmetric nhanh hơn asymmetric nhiều lần, nên nó phù hợp để mã hóa liên tục trong suốt phiên làm việc mà không làm chậm kết nối.
Ngoài ra, SSH còn dùng HMAC (Hash-based Message Authentication Code) để ký từng gói tin. Nếu có ai đó chỉnh sửa packet giữa đường, mã xác thực sẽ sai và bên nhận phát hiện ngay lập tức.
Ba lớp này hoạt động cộng hưởng với nhau: lớp 1 tạo kênh bí mật, lớp 2 xác thực đúng người, lớp 3 bảo vệ nội dung. Thiếu một lớp, hai lớp còn lại không đủ để giữ an toàn cho bạn.

Trên macOS và Linux, Terminal đã tích hợp sẵn SSH client, nên bạn không cần cài thêm gì. Chỉ cần mở Terminal và gõ lệnh:
ssh username@địa_chỉ_ip_hoặc_domain
Ví dụ cụ thể:
ssh root@203.0.113.10
SSH sẽ hỏi password, nhập xong là bạn vào được server. Nếu server đang dùng port khác 22, thêm tham số -p như sau:
ssh -p 2222 username@host
Trên Windows 10 trở lên, PowerShell và Command Prompt cũng đã tích hợp sẵn OpenSSH client, bạn dùng cú pháp giống hệt trên. Còn nếu bạn thích giao diện đồ họa hơn, PuTTY là lựa chọn phổ biến: chỉ cần điền địa chỉ server, port, chọn SSH rồi nhấn Open là xong.
Kết nối bằng password có ba vấn đề: dễ bị brute force, phải nhập tay mỗi lần, và không dùng được trong script tự động. SSH key giải quyết cả ba cùng lúc.
Tạo cặp khóa bằng lệnh:
ssh-keygen -t ed25519 -C "email@example.com"
Ed25519 là thuật toán được OpenSSH khuyến nghị hiện tại – nhanh hơn và an toàn hơn RSA-2048. Chạy lệnh xong, bạn sẽ có hai file:
~/.ssh/id_ed25519 (private key – giữ trên máy bạn, không bao giờ chia sẻ cho ai)~/.ssh/id_ed25519.pub (public key – cái này bạn sẽ copy lên server)Cách nhớ nhanh: private key là chìa khóa nhà của bạn, còn public key là ổ khóa. Bạn có thể lắp ổ khóa lên bất kỳ cánh cửa nào bạn muốn vào, nhưng chỉ người cầm đúng chìa mới mở được.
Copy public key lên server bằng lệnh:
ssh-copy-id username@host
Hoặc bạn cũng có thể thêm thủ công nội dung file .pub vào ~/.ssh/authorized_keys trên server.
Sau khi copy xong, thử đăng nhập lại. Lần này SSH sẽ tự dùng key thay vì hỏi password của bạn.
Các file SSH quan trọng là:
|
File |
Vị trí |
Nội dung |
Ai giữ |
|
id_ed25519 |
~/.ssh/ trên máy bạn |
Private key |
Chỉ bạn |
|
id_ed25519.pub |
~/.ssh/ trên máy bạn |
Public key |
Có thể chia sẻ |
|
authorized_keys |
~/.ssh/ trên server |
Danh sách public key được phép đăng nhập |
Server admin |
|
known_hosts |
~/.ssh/ trên máy bạn |
Dấu vân tay của server đã từng kết nối |
SSH client tự quản lý |
Cloud VPS của Tenten.vn cho phép upload SSH public key ngay khi tạo VPS – ngay từ lần đăng nhập đầu tiên, bạn dùng key thay vì password, không có giai đoạn “kết nối password tạm thời” dễ bị tấn công.
|
Lệnh |
Mô tả |
Ví dụ |
|
ssh user@host |
Đăng nhập server |
ssh root@203.0.113.10 |
|
ssh -p PORT user@host |
Đăng nhập qua port tùy chỉnh |
ssh -p 2222 admin@host |
|
scp file user@host:/path |
Copy file từ máy lên server |
scp backup.tar.gz root@host:/backups/ |
|
scp user@host:/path file |
Copy file từ server về máy |
scp root@host:/var/log/app.log ./ |
|
ssh-keygen -t ed25519 |
Tạo cặp SSH key mới |
Chạy không cần tham số bổ sung |
|
ssh-copy-id user@host |
Copy public key lên server |
ssh-copy-id root@203.0.113.10 |
|
ssh -L 8080:localhost:3306 user@host |
Tạo SSH tunnel |
Truy cập MySQL server nội bộ qua port 8080 |
Kết nối được SSH không có nghĩa là server của bạn đã an toàn. Theo mặc định, SSH server chạy trên port 22, chấp nhận đăng nhập bằng password, và cho phép root login trực tiếp – đúng ba cấu hình đó là lý do các bot quét toàn bộ internet 24/7 liên tục thử đăng nhập vào server của bạn.
Dưới đây là năm việc bạn cần làm ngay sau khi đã có SSH:

/etc/ssh/sshd_config, tìm dòng Port 22 và đổi sang port khác (ví dụ 2222 hoặc bất kỳ số nào từ 1024 đến 65535). Hầu hết bot quét tự động chỉ nhắm vào port 22, nên chỉ cần đổi port là bạn đã loại được phần lớn lượng noise trong log. Lưu ý: việc này không ngăn được attacker có chủ đích, nhưng đủ để giảm tải đáng kể.chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/id_ed25519
Các tham số cần thay đổi trong /etc/ssh/sshd_config là:
|
Tham số |
Giá trị mặc định |
Nên đặt |
Mục đích |
|
Port |
22 |
2222 hoặc khác |
Giảm bot scan |
|
PasswordAuthentication |
yes |
no |
Bắt buộc dùng key |
|
PermitRootLogin |
yes |
no |
Không đăng nhập root trực tiếp |
|
MaxAuthTries |
6 |
3 |
Giới hạn số lần thử |
Sau mỗi lần sửa sshd_config, bạn cần chạy systemctl restart sshd để áp dụng thay đổi. Quan trọng: luôn giữ một session SSH đang mở trong lúc thử kết nối lại bằng session mới, phòng trường hợp bạn cấu hình sai và mất luôn quyền truy cập vào server.
SSH thực ra là nền tảng của nhiều công cụ khác mà bạn có thể đã dùng hàng ngày, không chỉ để đăng nhập server từ xa.
SCP và SFTP dùng SSH để chuyển file an toàn giữa máy local và server, thay thế FTP vốn truyền file dạng plaintext. Nếu bạn đã quen với lệnh cp, thì scp có cú pháp tương tự, chỉ khác là bạn làm việc qua mạng. Còn SFTP cung cấp giao diện tương tác giống FTP nhưng toàn bộ dữ liệu đi qua kênh mã hóa.
SSH tunnel cho phép bạn forward port qua kênh SSH để truy cập dịch vụ nội bộ vốn không mở ra internet. Ví dụ thực tế: giả sử server database của bạn chỉ lắng nghe localhost:3306 vì lý do bảo mật, nhưng bạn vẫn muốn kết nối từ máy tính cá nhân. Lúc đó, bạn tạo tunnel như sau:
ssh -L 8080:localhost:3306 user@server
Sau đó bạn kết nối tới localhost:8080 trên máy mình, và traffic sẽ tự động được tunnel qua SSH tới localhost:3306 trên server – an toàn, không cần mở firewall thêm gì.
Git over SSH là thứ nhiều người trong chúng ta đang dùng mà không để ý: khi bạn clone một repo bằng địa chỉ dạng git@github.com:user/repo.git, GitHub đang dùng SSH key để xác thực bạn. Đó chính là lý do bước “thêm SSH key vào GitHub” là bắt buộc khi bạn muốn push code mà không phải nhập password mỗi lần.

SSH chỉ an toàn khi cả cấu hình lẫn hạ tầng phía dưới đều đáng tin. Cấu hình sai một bước – từ permissions của ~/.ssh đến PermitRootLogin – là đủ để mở cửa cho brute force. Hạ tầng không ổn định thì SSH key chuẩn đến đâu cũng không giúp được gì khi server downtime lúc cần nhất.
Ba việc cần kiểm tra ngay trên bất kỳ server nào đang chạy:
Cloud VPS của Tenten.vn hỗ trợ upload SSH public key ngay tại bước khởi tạo – không có giai đoạn dùng password tạm thời, không có cửa sổ dễ bị tấn công. Phù hợp cho team cần deploy nhanh với chuẩn bảo mật production từ ngày đầu.
HTTPS mã hóa traffic giữa browser và website để bảo vệ người dùng cuối khi họ lướt web. Còn SSH mã hóa kết nối quản trị giữa bạn (với tư cách admin) và server. Hai giao thức phục vụ mục đích khác nhau và hoạt động ở các ngữ cảnh khác nhau, dù cả hai đều dùng mã hóa.
Cả hai đều dùng cryptography public/private key, nhưng mục đích và hệ sinh thái hoàn toàn khác nhau. SSH key dùng để xác thực bạn khi kết nối vào server. SSL certificate thì để xác thực danh tính website với trình duyệt, và phải được Certificate Authority (CA) ký. Hai thứ này không thể dùng thay thế cho nhau.
Nếu bạn gặp lỗi này, có ba nguyên nhân phổ biến nhất: (1) ~/.ssh/authorized_keys trên server không có public key của bạn, hoặc file bị sai permissions (cần chmod 600); (2) thư mục ~/.ssh trên server sai permissions (cần chmod 700); (3) bạn đang dùng sai private key, hoặc private key không tồn tại trên máy bạn đang dùng lúc này.
Hoàn toàn được. Windows 10 và 11 đã tích hợp sẵn OpenSSH client – bạn chỉ cần mở PowerShell hoặc Command Prompt và gõ ssh là dùng được ngay, không cần cài thêm gì. Còn nếu bạn thích giao diện đồ họa hơn, PuTTY là lựa chọn phổ biến và hoàn toàn miễn phí.
Bạn có hai hướng xử lý: (1) đổi SSH server sang port khác như 443 hoặc 80, vì nhiều firewall mở sẵn hai port này cho traffic web; (2) dùng SSH over HTTPS nếu môi trường của bạn chỉ cho phép traffic web. Riêng với người dùng GitHub, GitHub hỗ trợ SSH qua port 443 chính thức cho đúng trường hợp port 22 bị block.
Không, nếu bạn đã tắt PasswordAuthentication. Đây chính là lý do bạn cần backup private key (lưu vào password manager hoặc ổ cứng ngoài được mã hóa) và không nên vội tắt PasswordAuthentication cho đến khi đã xác nhận backup an toàn.
SSH tunnel là kỹ thuật forward port qua kênh SSH để bạn có thể truy cập dịch vụ nội bộ vốn không mở ra internet. Bạn sẽ cần đến nó khi muốn truy cập database, admin panel, hay Jupyter notebook từ máy tính cá nhân mà không phải mở thêm firewall. Ngrok và nhiều công cụ tương tự về bản chất đều là wrapper quanh kỹ thuật này.