Hướng Dẫn Dùng SSH Key Cho VPS Ubuntu Và Tắt Đăng Nhập Mật Khẩu

Khi mới thuê VPS Ubuntu, nhiều người đăng nhập SSH bằng username + password. Cách này đơn giản nhưng nếu VPS có IP public, cổng SSH thường xuyên bị bot Internet quét và thử đăng nhập tự động. Một mật khẩu mạnh vẫn quan trọng, nhưng mô hình bảo mật tốt hơn là dùng SSH public key authentication, sau đó tắt password login khi đã xác nhận key hoạt động ổn định.

SSH key không phải “mật khẩu dài hơn”. Nó dùng một cặp khóa:

• private key nằm trên máy tính của bạn và không được chia sẻ;
• public key được đặt trên VPS;
• khi kết nối, OpenSSH xác minh bạn sở hữu private key tương ứng mà không cần gửi private key lên server.

Nếu bạn cần thêm lớp phản ứng với brute-force, có thể xem bài Cài Fail2Ban trên VPS Ubuntu. Bài hiện tại tập trung riêng vào xác thực SSH bằng key và tắt password an toàn.

1. Vì sao SSH key an toàn hơn password trong nhiều tình huống?

Password authentication cho phép client gửi thông tin xác thực dựa trên mật khẩu. Nếu mật khẩu yếu, bị tái sử dụng hoặc bị lộ, kẻ tấn công có thể đăng nhập.

Public key authentication dùng cặp khóa bất đối xứng. Server lưu public key, trong khi private key vẫn ở thiết bị của bạn.

Lợi ích thực tế:

• tránh brute-force password theo cách truyền thống;
• không cần nhập password VPS mỗi lần đăng nhập;
• có thể dùng passphrase để bảo vệ private key;
• dễ cấp nhiều key cho nhiều thiết bị hoặc nhân sự;
• thu hồi từng key mà không cần đổi toàn bộ password account.

2. SSH key không thay thế toàn bộ bảo mật VPS

Dùng key không có nghĩa VPS đã “an toàn tuyệt đối”. Bạn vẫn cần:

• cập nhật Ubuntu;
• firewall;
• giới hạn user có quyền sudo;
• Fail2Ban nếu phù hợp;
• bảo vệ private key;
• backup;
• theo dõi log SSH.

Nếu private key bị đánh cắp và không có passphrase, kẻ có key có thể dùng nó như credential.

3. Kiểm tra OpenSSH trên VPS

Đăng nhập VPS bằng phương thức hiện tại rồi chạy:

sudo systemctl status ssh

Kiểm tra port:

sudo ss -tulnp | grep ssh

Nếu SSH hoạt động ở port khác 22, hãy ghi lại port đó để dùng khi test key.

4. Tạo SSH key trên Windows, macOS hoặc Linux

OpenSSH client hiện có sẵn trên nhiều hệ điều hành hiện đại.

Tạo Ed25519 key:

ssh-keygen -t ed25519 -C "admin-vps"

Bạn sẽ được hỏi nơi lưu key, ví dụ:

~/.ssh/id_ed25519

Sau đó nhập passphrase nếu muốn bảo vệ private key.

Có nên đặt passphrase?

Có, đặc biệt trên laptop hoặc thiết bị có nguy cơ thất lạc. Passphrase giúp bảo vệ private key nếu file bị copy trái phép.

Nếu cần automation không tương tác, bạn có thể dùng agent hoặc cơ chế secret phù hợp thay vì để private key không bảo vệ một cách tùy tiện.

5. Hai file nào được tạo?

Thông thường:

~/.ssh/id_ed25519
~/.ssh/id_ed25519.pub

Trong đó:

• id_ed25519: private key — không chia sẻ;
• id_ed25519.pub: public key — có thể copy lên VPS.

6. Xem public key

Linux/macOS:

cat ~/.ssh/id_ed25519.pub

Windows PowerShell:

Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub

Public key thường bắt đầu bằng:

ssh-ed25519 AAAA...

7. Copy public key bằng ssh-copy-id

Trên Linux/macOS, nếu có ssh-copy-id:

ssh-copy-id ubuntu@IP_VPS

Nếu SSH dùng port custom:

ssh-copy-id -p 2222 ubuntu@IP_VPS

Lệnh sẽ thêm public key vào file ~/.ssh/authorized_keys của user từ xa.

8. Thêm public key thủ công

Nếu máy local không có ssh-copy-id, trên VPS:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys

Dán toàn bộ public key vào một dòng riêng.

Sau đó:

chmod 600 ~/.ssh/authorized_keys

Kiểm tra owner:

ls -ld ~/.ssh
ls -l ~/.ssh/authorized_keys

File và thư mục phải thuộc user đang đăng nhập.

9. Vì sao quyền .ssh và authorized_keys quan trọng?

OpenSSH có thể từ chối key nếu quyền file quá rộng hoặc ownership không phù hợp.

Thiết lập phổ biến:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Nếu owner sai:

sudo chown -R $USER:$USER ~/.ssh

Không đặt authorized_keys thành 777.

10. Test SSH key trước khi tắt password

Giữ nguyên phiên SSH hiện tại đang mở.

Mở terminal mới trên máy tính và chạy:

ssh ubuntu@IP_VPS

Nếu dùng key không mặc định:

ssh -i ~/.ssh/my-vps-key ubuntu@IP_VPS

Port custom:

ssh -p 2222 -i ~/.ssh/my-vps-key ubuntu@IP_VPS

Chỉ tiếp tục sang bước tắt password nếu phiên mới đăng nhập thành công bằng key.

11. Kiểm tra client đang dùng key nào

Dùng verbose mode:

ssh -v ubuntu@IP_VPS

Bạn sẽ thấy các bước client thử key và phương thức authentication.

Không cần dùng -vvv trừ khi cần debug sâu.

12. Tạo file cấu hình SSH client để đăng nhập nhanh

Trên máy local, sửa:

~/.ssh/config

Ví dụ:

Host huong-vps
    HostName 203.0.113.10
    User ubuntu
    Port 22
    IdentityFile ~/.ssh/id_ed25519

Sau đó chỉ cần:

ssh huong-vps

Đây là cấu hình phía client, không ảnh hưởng server.

13. Backup cấu hình SSH server trước khi sửa

Trên VPS:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Ubuntu hiện có thể dùng thêm drop-in file trong:

/etc/ssh/sshd_config.d/

Tùy phiên bản, dùng drop-in giúp tách tùy chỉnh khỏi file mặc định.

14. Kiểm tra cấu hình thực tế trước khi thay đổi

sudo sshd -T | grep -E 'pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|permitrootlogin'

sshd -T cho biết cấu hình hiệu lực sau khi OpenSSH đọc các file cấu hình.

15. Tạo drop-in để tắt password authentication

Ví dụ:

sudo nano /etc/ssh/sshd_config.d/99-key-only.conf

Thêm:

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no

Vì sao tắt cả KbdInteractiveAuthentication?

Trong nhiều cấu hình PAM, keyboard-interactive có thể cung cấp luồng xác thực tương tự password. Nếu mục tiêu là key-only, cần kiểm tra cả hai phương thức thay vì chỉ PasswordAuthentication.

16. Có nên tắt root login?

Nếu bạn đang dùng user thường có quyền sudo, có thể cấu hình:

PermitRootLogin no

Nhưng đừng thay đổi nhiều thứ cùng một lúc nếu chưa test.

Quy trình an toàn là:

1. xác nhận user thường dùng key được;
2. xác nhận sudo hoạt động;
3. sau đó mới tắt root login.

17. Test syntax trước khi reload SSH

sudo sshd -t

Nếu không có output, syntax thường hợp lệ.

Nếu có lỗi, không reload cho tới khi sửa xong.

18. Reload SSH

sudo systemctl reload ssh

Kiểm tra:

sudo systemctl status ssh

Giữ phiên SSH cũ mở.

19. Test một phiên mới sau khi tắt password

Mở terminal mới:

ssh ubuntu@IP_VPS

Xác nhận login thành công bằng key.

Sau đó thử ép password để kiểm tra server đã từ chối:

ssh -o PubkeyAuthentication=no ubuntu@IP_VPS

Nếu password login đã tắt đúng, kết nối này sẽ không được xác thực bằng password.

20. Nếu tự khóa mình khỏi VPS thì làm gì?

Nếu phiên SSH cũ vẫn mở, sửa file cấu hình ngay rồi reload lại.

Nếu mất toàn bộ SSH, bạn cần:

• console web/KVM của nhà cung cấp;
• rescue mode;
• snapshot rollback;
• support provider.

Đây là lý do không nên đóng phiên SSH cũ trước khi test session mới.

21. Quản lý nhiều SSH key cho cùng một user

Mỗi public key nằm trên một dòng trong:

~/.ssh/authorized_keys

Ví dụ:

ssh-ed25519 AAAA... laptop-admin
ssh-ed25519 AAAA... desktop-admin

Khi một thiết bị không còn dùng, chỉ xóa đúng dòng key tương ứng.

Không cần thay key của thiết bị khác.

22. Mỗi nhân viên có nên dùng một key riêng?

Có. Không nên chia sẻ cùng private key giữa nhiều người.

Key riêng giúp:

• thu hồi từng người;
• audit dễ hơn;
• tránh phát tán private key chung;
• giảm nhu cầu đổi credential cho cả đội.

Tốt hơn nữa là mỗi người có user riêng nếu môi trường cần audit rõ ràng.

23. Dùng authorized_keys options để hạn chế key

OpenSSH hỗ trợ thêm options trước key, chẳng hạn giới hạn nguồn IP hoặc forwarding trong một số use case.

Ví dụ cấu trúc:

from="203.0.113.50" ssh-ed25519 AAAA...

Hãy kiểm tra manpage authorized_keys của phiên bản OpenSSH đang dùng trước khi áp dụng trên production.

24. Private key nên lưu ở đâu?

Nên lưu trong thư mục .ssh của user local với quyền phù hợp.

Linux/macOS:

chmod 600 ~/.ssh/id_ed25519

Không gửi private key qua chat, email hoặc lưu trong repository Git.

25. Backup private key thế nào?

Nếu private key chỉ tồn tại trên một laptop, mất thiết bị có thể khiến bạn mất đường truy cập.

Có thể lưu bản backup được mã hóa ở password manager hoặc kho bí mật đáng tin cậy.

Không upload private key dạng plain text lên cloud storage công khai.

26. SSH agent giúp gì?

SSH agent giữ key đã giải mã trong phiên làm việc để bạn không phải nhập passphrase liên tục.

Linux/macOS thường dùng:

ssh-add ~/.ssh/id_ed25519

Windows OpenSSH cũng có ssh-agent service trong các phiên bản phù hợp.

27. Fail2Ban còn cần sau khi tắt password không?

Vẫn có thể hữu ích để giảm noise và chặn một số pattern xác thực thất bại. Tuy nhiên, key-only đã loại bỏ một lớp brute-force password rất lớn.

Không cần đặt Fail2Ban cực kỳ nghiêm nếu hệ thống đã key-only; hãy cấu hình dựa trên log thực tế.

28. UFW có cần thay đổi không?

Không vì key authentication không đổi port SSH.

Nếu SSH port 22:

sudo ufw allow 22/tcp

Nếu dùng port custom, allow đúng port.

Đừng xóa rule SSH hiện tại khi đang thao tác từ xa cho tới khi chắc chắn rule mới hoạt động.

29. Kiểm tra log SSH

sudo journalctl -u ssh

Theo dõi realtime:

sudo journalctl -u ssh -f

Bạn có thể dùng log để xác nhận public key authentication thành công và phát hiện các lần login thất bại.

30. Những lỗi phổ biến khi dùng SSH key

Permission denied (publickey)

Kiểm tra:

• public key có đúng user không;
• .ssh và authorized_keys permission;
• owner;
• PubkeyAuthentication;
• client có đang dùng đúng private key không.

Key đúng nhưng client không thử

Dùng:

ssh -v -i ~/.ssh/id_ed25519 ubuntu@IP_VPS

Tắt password nhưng vẫn đăng nhập kiểu password được

Kiểm tra:

sudo sshd -T | grep -E 'passwordauthentication|kbdinteractiveauthentication'

Có thể một drop-in khác đang override cấu hình.

31. Checklist chuyển VPS Ubuntu sang SSH key-only

• Tạo Ed25519 key.
• Private key có passphrase nếu phù hợp.
• Copy public key vào authorized_keys.
• Permission .ssh = 700.
• Permission authorized_keys = 600.
• Test login key ở terminal mới.
• Backup SSH config.
• Tạo drop-in key-only.
• Chạy sshd -t.
• Reload SSH.
• Test lại session mới.
• Giữ console/rescue path dự phòng.

32. FAQ về SSH key trên VPS Ubuntu

SSH key có an toàn hơn password không?

Trong nhiều mô hình quản trị VPS, public key authentication giảm rủi ro brute-force password và cho phép quản lý credential theo từng key. Private key vẫn phải được bảo vệ.

Nên dùng RSA hay Ed25519?

Ed25519 là lựa chọn hiện đại và tiện dụng trên OpenSSH hiện nay. Một số môi trường legacy có yêu cầu khác, nên kiểm tra client/server trước khi áp dụng.

Có thể dùng một SSH key cho nhiều VPS không?

Có thể, nhưng key riêng theo môi trường hoặc vai trò giúp thu hồi và phân tách rủi ro tốt hơn.

Có nên tắt password ngay sau khi tạo key?

Chỉ sau khi đã mở một phiên mới và xác nhận key hoạt động.

Có cần tắt root login không?

Nên cân nhắc nếu đã có user thường + sudo hoạt động ổn định. Không nên thay đổi trước khi có đường quản trị thay thế.

SSH key có hết hạn không?

Key OpenSSH thông thường không tự hết hạn. Bạn cần quy trình rotate/thu hồi key theo chính sách của mình.

Kết luận

Dùng SSH key trên VPS Ubuntu là bước nâng cấp bảo mật nên thực hiện sớm sau khi nhận VPS. Quy trình an toàn là tạo key → thêm public key → test đăng nhập ở phiên mới → kiểm tra sshd -t → mới tắt password authentication.

Đừng bỏ qua phương án recovery. Một cấu hình SSH sai có thể khiến bạn mất đường truy cập từ xa, vì vậy luôn giữ phiên quản trị cũ mở và biết cách dùng console của nhà cung cấp.

Nếu bạn đang triển khai website, Docker hoặc ứng dụng trên VPS Ubuntu tại HUONG CLOUD, việc chuyển sang key-based authentication là nền tảng tốt trước khi đưa hệ thống lên production.

Nguồn tham khảo

• Ubuntu Server OpenSSH documentation: https://documentation.ubuntu.com/server/how-to/security/openssh-server/
• Ubuntu manpage – sshd_config: https://manpages.ubuntu.com/manpages/stonking/man5/sshd_config.5.html
• OpenSSH manual – sshd_config: https://man.openbsd.org/sshd_config
• OpenSSH manual – ssh-keygen: https://man.openbsd.org/ssh-keygen