Dùng SSH key thế nào để giảm rủi ro mất quyền truy cập VPS?

Khi quản trị VPS, chuyển từ mật khẩu sang SSH key là bước nâng cấp bảo mật quan trọng đầu tiên. Thay vì phải nhớ một chuỗi ký tự phức tạp hoặc đối mặt với hàng nghìn đợt dò quét mật khẩu (brute-force) mỗi ngày từ Internet, bạn chỉ cần gõ một lệnh đơn giản là có thể đăng nhập vào máy chủ an toàn.

Tuy nhiên, có một tình huống trớ trêu mà rất nhiều người từng gặp phải: vừa tạo xong key và hí hửng chỉnh file cấu hình tắt luôn tính năng đăng nhập bằng mật khẩu (PasswordAuthentication no), khởi động lại dịch vụ SSH xong thì phát hiện... mình không thể đăng nhập lại được nữa. Cửa mật khẩu đã đóng, còn khóa SSH mới thì đặt sai quyền hạn thư mục hoặc cài nhầm user, biến máy chủ thành một "pháo đài bất khả xâm phạm" với chính người quản trị.

Sử dụng SSH key an toàn không chỉ nằm ở việc gõ đúng câu lệnh sinh khóa. Điều quan trọng hơn là bạn hiểu đúng cơ chế hoạt động, cài đặt theo trình tự cẩn trọng và luôn giữ cho mình một đường lui dự phòng.

Cơ chế cặp khóa: Private Key ở lại máy cá nhân, Public Key gửi lên máy chủ

Cơ chế xác thực SSH dựa trên mật mã khóa công khai gồm hai nửa không thể tách rời:

• Private Key (Khóa bí mật): Luôn nằm yên trên máy tính cá nhân của bạn và tuyệt đối không bao giờ được gửi đi bất cứ đâu. Nó đóng vai trò như chìa khóa riêng chỉ một mình bạn nắm giữ.
• Public Key (Khóa công khai): Được lưu trên máy chủ VPS, cụ thể là ghi vào file ~/.ssh/authorized_keys của tài khoản bạn muốn đăng nhập. Nó đóng vai trò như ổ khóa tương ứng mở cửa vào hệ thống.

Khi bạn kết nối, máy chủ sẽ dùng Public Key để gửi một bài toán mã hóa thách thức. Máy tính của bạn dùng Private Key để giải bài toán đó và chứng minh danh tính. Hai bên xác thực thành công mà không cần truyền bất kỳ mật khẩu nào qua đường truyền mạng.

Điểm giá trị nhất của mô hình này đối với doanh nghiệp là tách bạch quyền hạn theo từng cá nhân: Mỗi lập trình viên hoặc kỹ sư vận hành tự tạo một cặp khóa trên máy tính của riêng họ. Người quản trị chỉ nhận Public Key (file đuôi .pub) và thêm vào tài khoản tương ứng trên máy chủ. Khi một nhân sự chuyển dự án hoặc nghỉ việc, bạn chỉ cần xóa đúng dòng Public Key của người đó trong file authorized_keys. Những người còn lại vẫn làm việc bình thường mà bạn không cần phải đổi mật khẩu chung cho toàn bộ đội ngũ.

Nguyên tắc an toàn trước khi thay đổi: Luôn giữ đường cứu hộ

Trước khi bắt tay vào cấu hình SSH key hoặc chỉnh sửa file dịch vụ OpenSSH, hãy luôn đảm bảo 2 điều kiện an toàn:

1. Giữ nguyên cửa sổ SSH đang kết nối: Trong suốt quá trình cài đặt, tuyệt đối không đóng cửa sổ terminal bạn đang dùng để thao tác. Mọi bước kiểm tra chìa khóa mới đều phải được thực hiện trên một tab terminal hoàn toàn mới.
2. Kiểm tra tính năng Web Console: Đăng nhập vào trang quản trị của nhà cung cấp VPS và xác nhận bạn có thể mở Web Console (VNC/Serial Console). Nếu bạn lỡ tay cấu hình sai SSH, Web Console sẽ là cứu cánh duy nhất giúp bạn đăng nhập trực tiếp từ trình duyệt để sửa lại file cấu hình.

Nếu vừa nhận máy chủ mới, bạn nên hoàn tất các bước chuẩn bị cơ bản trong bài 12 việc cần làm ngay sau khi nhận VPS mới trước khi tiến hành siết chặt bảo mật.

Bước 1: Tạo cặp khóa trên máy tính cá nhân (Khuyên dùng Ed25519)

Hãy mở terminal trên máy tính của bạn (Linux, macOS, hoặc PowerShell trên Windows) và chạy lệnh:

ssh-keygen -t ed25519 -C "ten-cua-ban@ten-thiet-bi"

• Vì sao nên chọn Ed25519? So với thuật toán RSA cũ, Ed25519 an toàn hơn, độ dài khóa ngắn hơn và tốc độ xác thực nhanh hơn rất nhiều. Chỉ khi phải làm việc với các hệ điều hành rất cũ không hỗ trợ Ed25519 thì bạn mới cần dùng RSA 4096-bit (ssh-keygen -t rsa -b 4096).
• Phần chú thích (-C): Giúp bạn nhận diện khóa này thuộc về ai và máy tính nào khi mở file authorized_keys trên máy chủ.
• Đặt Passphrase cho khóa: Khi được hỏi nhập Passphrase, hãy đặt một mật khẩu bảo vệ cho file Private Key. Nếu chẳng may laptop của bạn bị thất lạc hoặc rơi vào tay người khác, kẻ gian vẫn không thể sử dụng file Private Key đó nếu không biết Passphrase.

Sau khi tạo xong, trong thư mục ~/.ssh/ của máy tính sẽ xuất hiện 2 file:

• id_ed25519: Đây là Private Key (tuyệt đối giữ kín, không gửi cho ai).
• id_ed25519.pub: Đây là Public Key (file này dùng để đưa lên máy chủ).

Bước 2: Đưa Public Key lên máy chủ đúng cách

Cách nhanh nhất và ít lỗi nhất là dùng lệnh ssh-copy-id từ máy tính cá nhân của bạn:

ssh-copy-id -i ~/.ssh/id_ed25519.pub ten-user@dia-chi-ip-vps

Lệnh này sẽ tự động tạo thư mục .ssh, gán quyền hạn chính xác và ghi nội dung Public Key vào cuối file ~/.ssh/authorized_keys của tài khoản tương ứng trên VPS.

Nếu công cụ này không có sẵn trên máy tính của bạn, bạn có thể copy thủ công nội dung file id_ed25519.pub rồi SSH vào VPS để paste vào file ~/.ssh/authorized_keys. Tuy nhiên, khi làm thủ công, bạn bắt buộc phải kiểm tra phân quyền thư mục trên máy chủ:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R ten-user:ten-user ~/.ssh

OpenSSH có cơ chế bảo mật rất nghiêm ngặt (StrictModes). Nếu thư mục .ssh hoặc file authorized_keys để quyền quá rộng (cho phép user khác có quyền ghi hoặc đọc), dịch vụ SSH trên máy chủ sẽ từ chối nhận diện khóa và tiếp tục bắt bạn nhập mật khẩu.

Bước 3: Mở một cửa sổ mới để thử đăng nhập

Đừng vội vàng tắt cửa sổ SSH hiện tại! Hãy mở một tab terminal mới trên máy tính và gõ:

ssh ten-user@dia-chi-ip-vps

Nếu hệ thống hỏi Passphrase của khóa (hoặc đăng nhập thẳng mà không đòi mật khẩu user Linux), chúc mừng bạn: khóa SSH đã hoạt động hoàn hảo. Hãy gõ thử một lệnh sudo bất kỳ để đảm bảo tài khoản của bạn có đủ quyền quản trị (tham khảo thêm bài Bảo mật tài khoản quản trị và quyền sudo trên VPS).

Bước 4: Tắt đăng nhập bằng mật khẩu sau khi đã kiểm tra an toàn

Chỉ khi bạn đã đăng nhập thành công bằng SSH key ở một cửa sổ độc lập, bạn mới tiến hành khóa cửa mật khẩu để chặn hoàn toàn các đợt tấn công brute-force.

Mở file cấu hình SSH trên máy chủ:

sudo nano /etc/ssh/sshd_config

Tìm và chỉnh sửa các dòng sau (đảm bảo không có dấu # ở đầu dòng):

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

• PasswordAuthentication no: Tắt hoàn toàn việc đăng nhập bằng mật khẩu thường.
• PermitRootLogin no: Không cho phép tài khoản root đăng nhập trực tiếp từ xa. Mọi người quản trị phải vào bằng tài khoản cá nhân có SSH key rồi mới dùng sudo khi cần.

Trước khi khởi động lại dịch vụ, hãy luôn chạy lệnh kiểm tra cú pháp:

sudo sshd -t

Nếu lệnh này không trả về lỗi nào, bạn mới yên tâm tải lại dịch vụ SSH:

sudo systemctl reload ssh

Lúc này, hãy tiếp tục mở thêm một tab terminal thứ ba trên máy tính để thử đăng nhập lại một lần nữa. Khi tab thứ ba vào được bình thường, bạn mới an tâm đóng các cửa sổ terminal cũ.

Quản lý khóa khi làm việc nhóm và thu hồi quyền

Trong môi trường doanh nghiệp có nhiều người cùng tham gia vận hành:

1. Tuyệt đối không dùng chung một cặp key: Không bao giờ có chuyện một người tạo cặp key rồi gửi file Private Key qua Zalo, Slack hay email cho đồng nghiệp cùng dùng. Làm như vậy sẽ triệt tiêu hoàn toàn khả năng truy vết và kiểm soát trách nhiệm.
2. Một người dùng nhiều thiết bị: Nếu bạn vừa dùng máy bàn ở công ty vừa dùng laptop cá nhân, hãy tạo 2 cặp key riêng biệt với comment rõ ràng (ví dụ nam-laptop và nam-desktop).
3. Thu hồi quyền khi nhân sự nghỉ việc: Mở file ~/.ssh/authorized_keys trên máy chủ, tìm dòng chứa chú thích của nhân sự đó và xóa đi. Sau khi xóa, người đó sẽ lập tức mất quyền truy cập vào hệ thống mà không hề ảnh hưởng đến các nhân sự khác.

Quy trình bàn giao và rà soát quyền hạn máy chủ định kỳ được hướng dẫn chi tiết tại bài viết Quy trình bàn giao VPS an toàn cho đơn vị quản trị từ xa. Việc kiểm kê các SSH key được cấp phép cũng là một phần không thể thiếu trong lịch quản trị VPS hằng tháng.

Checklist thiết lập và bảo vệ SSH Key

• ☐ Đã xác nhận tính năng Web Console trên portal nhà cung cấp hoạt động bình thường trước khi cấu hình.
• ☐ Luôn giữ nguyên cửa sổ terminal đang thao tác trong suốt quá trình đổi cấu hình.
• ☐ Cặp khóa được tạo trên máy tính cá nhân bằng thuật toán Ed25519 và có đặt Passphrase bảo vệ.
• ☐ File Private Key được giữ an toàn trên máy tính cá nhân, tuyệt đối không gửi lên máy chủ hay gửi qua ứng dụng chat.
• ☐ File Public Key được đưa lên đúng tài khoản user trên VPS và được phân quyền chuẩn (700 cho .ssh và 600 cho authorized_keys).
• ☐ Đã thử nghiệm đăng nhập thành công trên một cửa sổ terminal độc lập trước khi sửa file cấu hình.
• ☐ Chạy lệnh kiểm tra cú pháp sudo sshd -t trước khi reload dịch vụ SSH.
• ☐ Đã tắt tính năng đăng nhập bằng mật khẩu (PasswordAuthentication no) và chặn root từ xa (PermitRootLogin no).
• ☐ Mỗi nhân sự có cặp khóa riêng biệt, không chia sẻ dùng chung.