Kết nối SSH lần đầu là bước rất quan trọng khi bạn vừa nhận một VPS mới. Nếu làm đúng ngay từ đầu, bạn sẽ có một đường quản trị an toàn, ổn định và ít rủi ro hơn rất nhiều về sau. Nếu làm vội, đặc biệt là tắt password login hoặc chặn root quá sớm, bạn có thể tự khóa chính mình khỏi server.
Mục tiêu của bài này không chỉ là đăng nhập được bằng SSH, mà còn là hiểu rõ ba khái niệm nền tảng thường bị nhầm với nhau: key-based login, known_hosts và anti-lockout. Khi nắm được ba phần này, bạn sẽ biết cách chuyển từ đăng nhập bằng mật khẩu sang SSH key một cách an toàn, biết vì sao SSH cảnh báo host key ở lần kết nối đầu, và biết cách sửa cấu hình SSH mà không biến VPS thành “máy không vào được”.
1. SSH key-based login là gì và vì sao nên dùng ngay từ lần đầu?
Đăng nhập SSH bằng key là cách xác thực dựa trên một cặp khóa: private key nằm ở máy của bạn, còn public key được chép lên server. Khi kết nối, server kiểm tra public key đã được cấp quyền hay chưa, còn client chứng minh rằng nó đang giữ private key tương ứng.
So với việc dùng mật khẩu, key-based login có một số lợi ích rất rõ ràng. Thứ nhất, nó giảm mạnh rủi ro bị brute force do không còn phụ thuộc vào password. Thứ hai, bạn có thể đặt passphrase cho private key để tăng thêm một lớp bảo vệ. Thứ ba, quản trị nhiều VPS hoặc nhiều user sẽ sạch và dễ audit hơn so với cách chia sẻ mật khẩu.
Với một VPS Ubuntu 24.04 LTS mới nhận, cách làm hợp lý là thiết lập SSH key càng sớm càng tốt, nhưng không được tắt password login trước khi kiểm tra chắc chắn rằng key login đã hoạt động.
2. authorized_keys và known_hosts không phải là một!
Đây là chỗ rất nhiều người mới học SSH bị nhầm.
2.1. authorized_keys dùng để server chấp nhận bạn.
Trên server, mỗi user có thể có file ~/.ssh/authorized_keys. File này chứa public key nào được phép đăng nhập vào tài khoản đó. Nói ngắn gọn, đây là nơi server quyết định “key nào được vào”.
2.2. known_hosts dùng để máy bạn nhận diện server.
Trên máy local của bạn, SSH lưu thông tin host key của những server từng kết nối trong file ~/.ssh/known_hosts. Đây là nơi client quyết định “mình có đang kết nối đúng server quen thuộc không”.
Vì vậy, authorized_keys bảo vệ phía server, còn known_hosts bảo vệ phía client. Một bên để xác thực người dùng, một bên để xác thực máy chủ. Hai file này phục vụ hai mục đích hoàn toàn khác nhau.
3. Tạo SSH key trên máy local.
Với môi trường hiện đại, Ed25519 là lựa chọn rất phù hợp cho SSH key vì gọn, nhanh và an toàn cho phần lớn tình huống quản trị VPS thông thường.
Tạo key bằng lệnh:
ssh-keygen -t ed25519 -C "vps-admin"Sau khi chạy, bạn sẽ có hai file:
~/.ssh/id_ed25519
~/.ssh/id_ed25519.pubid_ed25519 là private key, phải giữ kín tuyệt đối. id_ed25519.pub là public key, dùng để chép lên server.
Nếu đây là máy làm việc cá nhân, bạn nên đặt passphrase cho private key. Điều này giúp giảm rủi ro nếu laptop bị mất hoặc private key bị lộ.
4. Chép public key lên VPS.
Nếu VPS mới vẫn cho đăng nhập bằng mật khẩu, cách đơn giản nhất là dùng:
ssh-copy-id -i ~/.ssh/id_ed25519.pub USERNAME@SERVER_IPLệnh này sẽ chép public key vào đúng vị trí cần thiết trên server. Sau đó, bạn có thể thử đăng nhập bằng:
ssh USERNAME@SERVER_IPNếu muốn làm thủ công, bạn cũng có thể đăng nhập vào server rồi tạo thư mục .ssh, sau đó thêm nội dung public key vào file authorized_keys.
Ví dụ:
mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keysSau đó dán nội dung của file id_ed25519.pub trên máy local vào authorized_keys.
5. Vì sao quyền file .ssh và authorized_keys rất quan trọng?
Một lỗi phổ biến là chép key đúng nhưng vẫn không đăng nhập được. Nguyên nhân không nằm ở key mà nằm ở quyền file quá rộng.
Thông thường, bạn nên dùng:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keysLý do là SSH rất nhạy với quyền file. Nếu thư mục .ssh hoặc file authorized_keys cho phép người khác ghi vào, SSH có thể xem đó là cấu hình không an toàn và từ chối dùng key.
Đây là lỗi rất thường gặp khi người dùng copy file giữa nhiều máy hoặc thao tác bằng root rồi quên chỉnh lại ownership.
6. Cách test key-based login mà không tự khóa máy.
Nguyên tắc anti-lockout đầu tiên là: không bao giờ đóng phiên SSH cũ trước khi test xong phiên mới.
Trình tự an toàn là:
Bước 1: giữ nguyên phiên SSH đang đăng nhập được
Nếu bạn đang đăng nhập bằng password hoặc bằng root, hãy giữ nguyên cửa sổ terminal đó.
Bước 2: mở một cửa sổ terminal mới để test
Dùng lệnh:
ssh -o PreferredAuthentications=publickey USERNAME@SERVER_IPNếu vào được bằng key, đó là tín hiệu tốt. Nhưng chưa phải lúc để tắt password login ngay lập tức.
Bước 3: kiểm tra user, quyền sudo và shell
Sau khi đăng nhập bằng key, hãy xác nhận:
whoami
id
sudo -lBạn cần chắc chắn rằng tài khoản này thực sự là user quản trị mà bạn sẽ dùng lâu dài, chứ không chỉ là đăng nhập được nhưng không có quyền làm gì tiếp theo.
7. known_hosts là gì trong lần kết nối đầu tiên?
Khi SSH tới một server lần đầu, bạn thường thấy thông báo hỏi có tin cậy host này không. Nhiều người chỉ gõ yes theo phản xạ, nhưng đây là bước rất quan trọng.
Thông báo đó xuất hiện vì máy bạn chưa từng biết host key của server này. Nếu bạn chấp nhận, SSH sẽ ghi host key vào ~/.ssh/known_hosts. Từ lần sau, SSH sẽ dùng thông tin đó để phát hiện xem server có còn là máy cũ hay không.
Điều này giúp giảm rủi ro bị man-in-the-middle. Nói dễ hiểu, known_hosts giúp máy bạn nhớ “danh tính SSH” của server.
8. Cách xác minh host key ở lần kết nối đầu tiên.
Lý tưởng nhất, bạn không nên chỉ nhìn prompt rồi gõ yes. Thay vào đó, hãy xác minh fingerprint của host key bằng một kênh khác ngoài SSH, chẳng hạn qua console của nhà cung cấp VPS.
Trên server, bạn có thể kiểm tra:
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pubSo sánh fingerprint này với fingerprint mà SSH hiển thị ở máy local. Nếu trùng nhau, bạn mới nên chấp nhận host key.
Cách làm này đặc biệt quan trọng với VPS mới, server production, hoặc khi bạn quản trị hạ tầng có dữ liệu thật.
9. Khi nào SSH báo lỗi host key changed?
Một ngày nào đó bạn có thể gặp cảnh báo kiểu “REMOTE HOST IDENTIFICATION HAS CHANGED”. Đây không phải lúc để xóa đại file known_hosts cho xong.
Cảnh báo này có thể do ba nguyên nhân phổ biến:
9.1. Server đã reinstall.
Khi bạn reinstall VPS, SSH host key mới thường được tạo lại. Máy bạn thấy key khác với key cũ nên sẽ cảnh báo.
9.2. Bạn đang trỏ tới một máy khác nhưng cùng IP hoặc hostname.
Điều này có thể xảy ra trong môi trường lab, migration hoặc thay VPS mới.
9.3. Có rủi ro bị giả mạo hoặc MITM
Dù xác suất không phải lúc nào cũng cao, bạn không được bỏ qua khả năng này.
Vì vậy, cách xử lý đúng là xác minh lại fingerprint trước. Chỉ sau khi xác nhận máy mới là hợp lệ, bạn mới xóa entry cũ khỏi known_hosts.
Có thể dùng:
ssh-keygen -R SERVER_IPhoặc:
ssh-keygen -R example.com10. Anti-lockout: tư duy quan trọng nhất khi sửa SSH.
Anti-lockout nghĩa là mọi thay đổi liên quan đến SSH đều phải được làm theo cách còn đường lui.
Đây là những nguyên tắc tối thiểu:
10.1. Luôn giữ ít nhất một phiên SSH cũ đang hoạt động.
Đừng sửa cấu hình rồi logout ngay. Phiên cũ là dây cứu sinh của bạn nếu cấu hình mới có lỗi.
10.2. Luôn có console dự phòng từ nhà cung cấp VPS.
Nếu nhà cung cấp có VNC, Web Console, Rescue System hoặc Serial Console, hãy biết nó nằm ở đâu trước khi đụng vào SSH.
10.3. Không tắt password login trước khi xác nhận public key login thật sự hoạt động.
Đây là lỗi phổ biến nhất. Rất nhiều người chép key xong, chưa test gì cả đã tắt password login rồi tự khóa máy.
10.4. Luôn kiểm tra cú pháp SSH trước khi restart.
Trước khi restart dịch vụ SSH, luôn chạy:
sudo sshd -tNếu lệnh này báo lỗi, dừng lại và sửa ngay. Đừng restart trong trạng thái chưa qua kiểm tra cú pháp.
11. Chỉnh cấu hình SSH theo cách sạch và dễ rollback hơn.
Thay vì sửa trực tiếp toàn bộ file chính, bạn nên thêm cấu hình riêng trong thư mục:
/etc/ssh/sshd_config.d/Ví dụ:
sudo nano /etc/ssh/sshd_config.d/hardening.confMột cấu hình chuyển tiếp an toàn có thể là:
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-passwordCấu hình này có ý nghĩa như sau:
PubkeyAuthentication yes đảm bảo xác thực bằng key được bật.
PasswordAuthentication no tắt đăng nhập bằng mật khẩu.
KbdInteractiveAuthentication no tắt thêm kiểu xác thực tương tác thường bị bỏ sót.
PermitRootLogin prohibit-password không cho root đăng nhập bằng mật khẩu, nhưng vẫn cho phép bằng SSH key nếu bạn vẫn đang ở giai đoạn chuyển tiếp.
Nếu bạn đã tạo user admin riêng, đã test đăng nhập ổn định bằng key và không còn cần root SSH nữa, lúc đó mới nên chuyển sang:
PermitRootLogin no12. Quy trình an toàn khi áp dụng hardening SSH.
Sau khi sửa file cấu hình, đừng restart ngay. Hãy làm đúng thứ tự:
sudo sshd -t
sudo systemctl restart sshTiếp theo, mở một terminal mới nữa để test lại:
ssh -v USERNAME@SERVER_IPChỉ khi đăng nhập thành công bằng phiên mới, bạn mới nên đóng phiên cũ. Nếu phiên mới lỗi, quay lại phiên cũ và rollback cấu hình ngay.
13. Cách xem log khi SSH login thất bại.
Khi key login không hoạt động hoặc sau khi restart SSH mà không đăng nhập được như mong đợi, log là nơi bạn phải nhìn đầu tiên.
Trên Ubuntu, bạn có thể dùng:
sudo journalctl -u ssh --since "1 hour ago"hoặc xem trực tiếp theo thời gian thực:
sudo journalctl -fu sshNhững log này thường cho bạn biết nguyên nhân khá rõ: sai quyền file, key không khớp, user không tồn tại, cấu hình bị sai directive, hoặc dịch vụ SSH không khởi động được sau khi đổi config.
14. Lỗi thường gặp khi kết nối SSH lần đầu.
14.1. Tắt PasswordAuthentication quá sớm.
Đây là lỗi kinh điển nhất. Public key chưa test xong mà đã tắt password thì chỉ cần sai một chi tiết nhỏ là mất quyền truy cập.
14.2. Đặt PermitRootLogin no khi vẫn chưa có user admin riêng.
Nếu bạn chưa có user sudo bằng key hoạt động tốt, việc chặn root hoàn toàn là một nước đi quá sớm.
14.3. Sửa config xong restart ngay, không chạy sshd -t.
Đây là kiểu lỗi tưởng nhỏ nhưng cực nguy hiểm, nhất là khi bạn thao tác qua SSH từ xa.
14.4. Thoát hết phiên SSH cũ trước khi thử phiên mới.
Nhiều người thấy mình “đã sửa xong” nên logout phiên cũ rồi mới thử login lại. Đây là cách nhanh nhất để tự khóa chính mình khỏi máy.
14.5. Không hiểu known_hosts, gặp cảnh báo là xóa đại.
Nếu server vừa reinstall hoặc đổi host key thật, bạn vẫn cần xác minh fingerprint trước khi chấp nhận key mới.
15. Kết luận.
Kết nối SSH lần đầu là một bước nền tảng nhưng ảnh hưởng lâu dài đến toàn bộ quá trình vận hành VPS. Nếu bạn làm đúng từ đầu, bạn sẽ có một đường quản trị an toàn hơn, sạch hơn và ít gặp sự cố hơn trong các bài tiếp theo. Quan trọng nhất, hãy nhớ rằng mục tiêu không chỉ là “vào được server”, mà là vào được server theo cách an toàn, có thể kiểm chứng và không tự khóa chính mình khi hardening SSH.
