11/03/2026
Chia sẻ
5913 lượt xem

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.

SSH là gì và tại sao nó trở thành tiêu chuẩn quản lý server

SSH là gì

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à:

  • Đăng nhập và chạy lệnh trên server từ xa
  • Chuyển file an toàn qua SCP hoặc SFTP
  • Tạo SSH tunnel để truy cập dịch vụ nội bộ
  • Xác thực Git khi push/pull code lên GitHub, GitLab

Vấn đề SSH sinh ra để giải quyết

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?

So sánh Telnet và SSH: Telnet truyền dữ liệu plaintext dễ bị sniff, SSH mã hóa toàn bộ traffic kể cả password

Đ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.

SSH hoạt động như thế nào: 3 lớp bảo mật theo đúng thứ tự

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.

Sơ đồ 3 lớp bảo mật SSH theo thứ tự: Key Exchange thiết lập kênh bảo mật, Authentication xác thực người dùng, Encryption mã hóa toàn bộ phiên làm việc

Bước 1: Thiết lập kênh bảo mật (Key Exchange)

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.

Bước 2: Xác thực danh tính (Authentication)

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:

  • Password: bạn gõ mật khẩu, server kiểm tra. Cách này đơn giản nhưng dễ bị brute force nếu mật khẩu của bạn yếu.
  • SSH key: bạn dùng cặp khóa public/private. Server chỉ lưu public key; còn private key thì nằm trên máy bạn và không bao giờ rời khỏi đó. Khi bạn đăng nhập, server gửi thử thách (challenge) được mã hóa bằng public key của bạn; máy bạn tự động giải mã bằng private key rồi gửi lại kết quả. Nếu khớp, server mới xác nhận danh tí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

Bước 3: Mã hóa dữ liệu trong phiên làm việc

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.

Cách kết nối SSH vào server, từ lệnh đầu tiên đến SSH key

3 bước thiết lập SSH key: tạo cặp key bằng ssh-keygen, copy public key lên server bằng ssh-copy-id, đăng nhập bằng key và tắt PasswordAuthentication

Kết nối cơ bản bằng password

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.

Tạo và dùng SSH key

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.

banner CTA vps

Các lệnh SSH hay dù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

 

Bảo mật SSH đúng cách: 5 việc cần làm sau khi kết nối được

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:

5 bước bảo mật SSH sau khi kết nối: đổi port, tắt PasswordAuthentication, tắt PermitRootLogin, cài Fail2Ban, kiểm tra permissions thư mục ~/.ssh

  1. Đổi port SSH mặc định. Mở file /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ể.
  2. Tắt đăng nhập bằng password. Sau khi bạn đã cấu hình SSH key và xác nhận đăng nhập được, hãy set PasswordAuthentication no trong sshd_config. Kể cả khi attacker biết đúng password của bạn, họ cũng không vào được nữa. Đây là bước bảo mật có tác động lớn nhất – nhưng chỉ nên làm sau khi bạn đã chắc chắn SSH key hoạt động tốt.
  3. Tắt login root trực tiếp. Set PermitRootLogin no, sau đó tạo một user thường và cấp quyền sudo khi cần. Bằng cách này, dù attacker có đoán được username thì họ vẫn phải đoán đúng username bạn đặt, thay vì cứ thử root là xong.
  4. Cài Fail2Ban. Fail2Ban theo dõi log SSH và tự động ban IP sau một số lần đăng nhập sai (mặc định là 5 lần). Đây là lớp bảo vệ hiệu quả nhất trước brute force tự động, và việc cài đặt chỉ mất vài phút.
  5. Kiểm tra permissions thư mục SSH. Sai permissions là nguyên nhân phổ biến nhất khiến SSH key của bạn không hoạt động dù đã cấu hình đúng:

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 dùng để làm gì ngoài đăng nhập 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.

3 use case SSH ngoài đăng nhập server: SCP/SFTP chuyển file an toàn, SSH Tunnel truy cập dịch vụ nội bộ, Git over SSH xác thực với GitHub và GitLab

Kết luận: SSH an toàn bắt đầu từ hạ tầng đúng

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:

  1. Xác nhận SSH key đã thay thế hoàn toàn password: kiểm tra PasswordAuthentication no trong sshd_config. Nếu vẫn còn bật password, server đang mở cửa cho brute force 24/7.
  2. Kiểm tra PermitRootLogin: nên là no hoặc prohibit-password. Root login trực tiếp là vector tấn công phổ biến nhất.
  3. Review authorized_keys định kỳ: loại bỏ key của nhân viên đã nghỉ, key từ máy cũ, hoặc key không rõ nguồn gốc. Key thừa là rủi ro thường bị bỏ qua nhất trong môi trường team.

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.

FAQ 

SSH khác HTTPS ở điểm nào?

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.

SSH key và SSL certificate có giống nhau không?

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.

Tại sao SSH bị từ chối với lỗi “Permission denied (publickey)”?

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.

Có thể dùng SSH trên Windows không?

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í.

SSH port 22 bị block bởi firewall thì làm gì?

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.

Mất private key thì có vào được server không?

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à gì và khi nào cần dùng?

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.