Cách Bảo Mật SSH Cho Linux VPS Toàn Diện

SSH là phương thức quản trị từ xa gần như mặc định trên Linux VPS. Đây cũng là dịch vụ bị nhắm tới nhiều nhất ngay khi máy chủ có IP public và mở cổng truy cập. Chỉ cần để SSH hoạt động trên port 22 với xác thực bằng mật khẩu, hệ thống có thể bắt đầu nhận hàng loạt yêu cầu đăng nhập thất bại từ bot quét Internet trong thời gian rất ngắn. Vì vậy, bảo vệ SSH không phải là bước tối ưu tùy chọn, mà là yêu cầu nền tảng khi vận hành VPS.

Bài viết này trình bày quy trình bảo mật SSH theo hướng thực tế và an toàn: chuyển sang SSH key, vô hiệu hóa đăng nhập bằng mật khẩu, kiểm tra log xác thực và tránh các lỗi tự khóa chính mình khỏi máy chủ. Các bước được áp dụng cho môi trường Linux VPS phổ biến như Ubuntu, Debian, AlmaLinux và các hệ RHEL-based.

Bao Mat SSH Cho Linux VPS

Vì sao SSH luôn là mục tiêu tấn công hàng đầu

SSH là “cửa chính” để quản trị VPS, nên attacker và bot tự động luôn ưu tiên dò dịch vụ này trước. Khi cổng 22 mở ra Internet, bot scanner có thể phát hiện nhanh và thử đăng nhập liên tục bằng các cặp tên người dùng và mật khẩu phổ biến như root:123456, admin:password hoặc ubuntu:ubuntu.

Hai hình thức tấn công thường gặp nhất là:

Dò mật khẩu brute force: thử rất nhiều mật khẩu cho đến khi trúng. Nếu mật khẩu yếu, nguy cơ bị chiếm quyền chỉ còn là vấn đề thời gian.
Credential stuffing: sử dụng thông tin đăng nhập bị rò rỉ từ các vụ lộ dữ liệu khác để thử trên SSH. Nếu tái sử dụng mật khẩu giữa nhiều dịch vụ, rủi ro tăng rất cao.

Có thể kiểm tra ngay máy chủ có đang bị quét hay không bằng cách xem log xác thực.

Kiểm tra log đăng nhập thất bại

Trên Ubuntu và Debian:

grep "Failed password" /var/log/auth.log | tail -20

Trên AlmaLinux, RHEL và các bản phân phối tương tự:

grep "Failed password" /var/log/secure | tail -20

Nếu xuất hiện nhiều dòng đăng nhập thất bại từ các IP lạ, đó là dấu hiệu bot đang quét SSH của VPS. Việc này rất phổ biến và không có nghĩa hệ thống đã bị xâm nhập, nhưng nó cho thấy SSH đang bị phơi ra Internet và cần được siết lại ngay.

Nguyên tắc bảo mật SSH hiệu quả

Mục tiêu của việc hardening SSH không chỉ là giảm số lần bị dò quét, mà quan trọng hơn là loại bỏ các phương thức xác thực yếu. Cách tiếp cận hiệu quả nhất là:

Ưu tiên SSH key thay cho mật khẩu
Tắt hoàn toàn PasswordAuthentication sau khi xác nhận key hoạt động
Cân nhắc đổi port để giảm lưu lượng quét tự động trên port 22
Mở đúng firewall và xử lý thêm SELinux nếu dùng AlmaLinux hoặc RHEL-based
Kiểm tra kỹ trước khi khởi động lại dịch vụ SSH để tránh mất quyền truy cập từ xa

Tạo SSH key Ed25519 trên máy local

Bước quan trọng nhất là chuyển từ xác thực bằng mật khẩu sang xác thực bằng khóa. Với SSH key, máy chủ chỉ cho phép đăng nhập nếu phía client sở hữu private key tương ứng. Điều này gần như loại bỏ hoàn toàn rủi ro từ brute force vào mật khẩu SSH.

Loại khóa được khuyến nghị là Ed25519. Đây là thuật toán hiện đại dựa trên elliptic curve, có độ dài khóa ngắn hơn nhưng vẫn đạt mức an toàn rất cao, đồng thời cho tốc độ ký và xác thực tốt. Trong thực tế, Ed25519 thường là lựa chọn phù hợp hơn RSA cho truy cập SSH thông thường.

Hãy tạo khóa trên máy cá nhân, không phải trên VPS:

ssh-keygen -t ed25519 -C "your-email@example.com"

Sau khi chạy lệnh, hệ thống sẽ hỏi nơi lưu khóa và passphrase. Nên đặt passphrase để bảo vệ private key nếu máy local bị truy cập trái phép. Khi hoàn tất, bạn sẽ có hai tệp:

~/.ssh/id_ed25519: private key, phải giữ bí mật tuyệt đối
~/.ssh/id_ed25519.pub: public key, dùng để đưa lên VPS

Ý nghĩa của passphrase cho SSH key

Nhiều quản trị viên bỏ qua passphrase vì muốn đăng nhập nhanh hơn, nhưng đây là một lớp bảo vệ rất đáng giá. Nếu laptop hoặc máy trạm bị rò rỉ dữ liệu, private key không có passphrase có thể bị dùng ngay để truy cập máy chủ. Khi có passphrase, attacker vẫn phải vượt qua thêm một lớp xác thực nữa.

Đưa public key lên VPS

Cách nhanh nhất là dùng ssh-copy-id nếu hệ điều hành local có sẵn công cụ này:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server-ip

Nếu không có ssh-copy-id, ví dụ trong một số môi trường Windows hoặc shell tối giản, có thể sao chép thủ công.

Xem nội dung public key trên máy local:

cat ~/.ssh/id_ed25519.pub

Sau đó SSH vào server bằng cách hiện tại, rồi thêm nội dung public key vào tài khoản cần đăng nhập:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "nội-dung-public-key" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Hai quyền truy cập 700 cho thư mục ~/.ssh và 600 cho tệp authorized_keys rất quan trọng. Nếu quyền quá rộng, SSH có thể từ chối sử dụng key vì lý do an toàn.

Kiểm tra đăng nhập bằng key

Thử đăng nhập bằng khóa vừa tạo:

ssh -i ~/.ssh/id_ed25519 user@your-server-ip

Nếu đăng nhập thành công mà không bị hỏi mật khẩu tài khoản trên VPS, cấu hình key đã hoạt động đúng. Trong trường hợp có đặt passphrase, bạn có thể vẫn được hỏi passphrase của private key, đây là hành vi bình thường.

Không tắt xác thực bằng mật khẩu trước khi xác nhận chắc chắn SSH key hoạt động. Nếu làm sai thứ tự, bạn có thể tự khóa mình ra khỏi VPS.

Tắt đăng nhập SSH bằng mật khẩu

Sau khi kiểm tra thành công SSH key, bước tiếp theo là vô hiệu hóa hoàn toàn đăng nhập bằng password. Đây là biện pháp có tác động mạnh nhất để chặn brute force và credential stuffing, vì khi không còn mật khẩu để thử, bot quét sẽ mất mục tiêu chính.

Mở file cấu hình SSH:

sudo nano /etc/ssh/sshd_config

Tìm và chỉnh các dòng sau:

PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

Khởi động lại dịch vụ SSH để áp dụng:

sudo systemctl restart sshd

Sau đó, giữ nguyên phiên SSH hiện tại và mở thêm một terminal mới để kiểm tra đăng nhập lại bằng key. Nếu phiên mới vào được bình thường, cấu hình đã an toàn. Nếu không đăng nhập được, phiên cũ vẫn còn để bạn sửa lại.

Khi nào không nên đặt UsePAM no

Nếu dự định triển khai xác thực hai lớp qua PAM ở bước nâng cao, không nên tắt PAM. Trong trường hợp đó, cần giữ:

UsePAM yes
ChallengeResponseAuthentication yes

Điều này cho phép SSH phối hợp với cơ chế xác thực bổ sung. Nếu tắt PAM quá sớm, các giải pháp 2FA dựa trên PAM sẽ không hoạt động.

Đổi port SSH để giảm nhiễu từ bot quét

Đổi port SSH không phải là biện pháp thay thế xác thực mạnh. Về bản chất, đây là cách giảm mức độ lộ diện với các bot chỉ quét port 22. Một attacker chủ động vẫn có thể quét toàn bộ dải cổng để tìm dịch vụ SSH. Tuy nhiên, trong vận hành thực tế, đổi port vẫn rất hữu ích vì giúp giảm đáng kể số lượng yêu cầu dò quét tự động, làm log sạch hơn và dễ phát hiện hành vi bất thường thực sự.

Để đổi port, sửa file /etc/ssh/sshd_config:

Port 2222

Hãy chọn cổng trong khoảng 1024-65535 và tránh trùng với dịch vụ khác như 3306 cho MySQL hoặc 8080 cho ứng dụng web.

Mở port mới trên firewall trước khi restart SSH

Đây là bước bắt buộc. Nếu đổi port nhưng quên mở trên firewall, bạn có thể mất truy cập từ xa ngay sau khi restart dịch vụ.

Trên Ubuntu và Debian dùng UFW:

sudo ufw allow 2222/tcp
sudo ufw reload

Trên AlmaLinux, RHEL và hệ dùng firewalld:

sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload

Sau khi mở firewall, mới tiến hành khởi động lại SSH và thử kết nối bằng port mới.

Kết nối SSH bằng port tùy chỉnh

Sau khi đổi port, cú pháp kết nối sẽ cần chỉ rõ cổng:

ssh -p 2222 -i ~/.ssh/id_ed25519 user@your-server-ip

Nếu dùng công cụ quản trị hoặc automation, cũng cần cập nhật lại port tương ứng để tránh lỗi kết nối.

Lưu ý đặc biệt với SELinux trên AlmaLinux và RHEL-based

Trên AlmaLinux và nhiều bản phân phối họ RHEL, SELinux thường mặc định chỉ cho phép SSH hoạt động trên port 22. Nếu đổi sang cổng khác mà không cập nhật policy, dịch vụ SSH có thể không khởi động được dù cấu hình trong sshd_config là đúng.

Nếu chưa có công cụ cần thiết, cài policycoreutils-python-utils:

sudo dnf install -y policycoreutils-python-utils

Sau đó thêm port mới cho loại dịch vụ SSH trong SELinux:

sudo semanage port -a -t ssh_port_t -p tcp 2222

Nếu port đã tồn tại trong policy và bạn chỉ đang thay đổi ánh xạ, có thể cần thao tác điều chỉnh thay vì thêm mới. Sau khi cập nhật, hãy khởi động lại SSH và kiểm tra lại khả năng kết nối.

Nếu đổi port trên AlmaLinux hoặc RHEL-based mà SSH không lên lại sau khi restart, hãy kiểm tra ngay SELinux trước khi giả định lỗi nằm ở firewall hoặc cấu hình sshd.

Quy trình an toàn khi áp dụng thay đổi SSH

Hardening SSH dễ gây gián đoạn nếu thực hiện thiếu trình tự. Một quy trình an toàn nên bao gồm:

Tạo SSH key trên máy local
Đưa public key lên VPS
Kiểm tra đăng nhập bằng key thành công
Nếu đổi port, mở port mới trên firewall trước
Nếu dùng AlmaLinux hoặc RHEL-based, cập nhật SELinux cho port mới
Chỉnh /etc/ssh/sshd_config
Restart SSH
Mở terminal mới để test lại, không đóng phiên cũ cho đến khi xác nhận mọi thứ hoạt động

Thứ tự này giúp giảm tối đa khả năng bị mất quyền truy cập vào VPS.

Những lỗi cấu hình thường gặp và cách xử lý

Đăng nhập bằng key không hoạt động

Các nguyên nhân phổ biến gồm:

Public key chưa được thêm đúng vào ~/.ssh/authorized_keys
Quyền thư mục hoặc tệp không đúng: 700 cho ~/.ssh, 600 cho authorized_keys
Đang dùng sai user khi đăng nhập
Chưa chỉ định đúng private key bằng tham số -i

Hãy kiểm tra lại từng điểm trước khi tắt password authentication.

Đổi port xong không kết nối được

Những nguyên nhân thường gặp nhất là:

Quên mở port mới trên firewall
Client vẫn đang cố kết nối vào port 22
SELinux chưa cho phép port mới trên AlmaLinux hoặc RHEL-based
Dịch vụ SSH chưa restart thành công

Với lỗi kiểu này, việc giữ lại phiên SSH cũ đang mở là cực kỳ quan trọng vì bạn vẫn còn đường để sửa cấu hình.

Tắt PAM quá sớm

Nếu đặt UsePAM no trong khi còn cần cơ chế xác thực bổ sung hoặc chính sách đăng nhập dựa trên PAM, SSH có thể hoạt động không như mong đợi. Trước khi tắt PAM, cần chắc chắn bạn không phụ thuộc vào 2FA hoặc các module xác thực liên quan.

Thực hành kiểm tra sau khi hardening SSH

Sau khi hoàn tất cấu hình, nên xác minh lại toàn bộ đường truy cập quản trị:

Đăng nhập bằng SSH key từ máy local
Nếu đã đổi port, kết nối bằng đúng port mới
Xác nhận không còn đăng nhập bằng mật khẩu
Xem lại log xác thực để theo dõi số lần đăng nhập thất bại

Trên hệ thống đã tắt password authentication, bạn vẫn có thể thấy một số bot tiếp tục thử đăng nhập. Điều khác biệt là các nỗ lực này không còn hiệu quả nếu không có private key tương ứng.

Tác động thực tế của từng biện pháp

Biện pháp	Mục tiêu chính	Tác động thực tế
SSH key Ed25519	Thay thế mật khẩu	Loại bỏ phần lớn rủi ro brute force vào password
Tắt PasswordAuthentication	Chặn đăng nhập bằng mật khẩu	Credential stuffing và dò mật khẩu gần như mất tác dụng
Đổi port SSH	Giảm lộ diện trên port 22	Giảm mạnh lưu lượng bot quét phổ thông, log sạch hơn
Mở firewall đúng cách	Đảm bảo truy cập hợp lệ	Tránh tự khóa khỏi VPS sau khi đổi port
Cập nhật SELinux	Cho phép SSH dùng port mới	Tránh lỗi SSH không khởi động trên AlmaLinux/RHEL-based

Khuyến nghị vận hành lâu dài

Bảo mật SSH không phải thao tác làm một lần rồi bỏ đó. Khi quản trị VPS trong thời gian dài, nên duy trì các thói quen sau:

Chỉ dùng SSH key cho tài khoản quản trị
Bảo vệ tốt máy local vì đây là nơi lưu private key
Đặt passphrase cho private key
Kiểm tra log xác thực định kỳ để phát hiện bất thường
Ghi nhớ port SSH tùy chỉnh và cập nhật trong tài liệu vận hành nội bộ
Thử đăng nhập bằng phiên mới sau mọi thay đổi trước khi đóng phiên cũ

Nếu quản trị nhiều VPS, việc chuẩn hóa quy trình SSH ngay từ đầu sẽ giúp giảm đáng kể rủi ro sai sót cấu hình và tiết kiệm thời gian xử lý sự cố.

Kết luận

Muốn bảo mật SSH trên Linux VPS một cách toàn diện, điều cốt lõi không nằm ở một mẹo đơn lẻ mà ở chuỗi biện pháp đúng thứ tự. Hãy bắt đầu bằng SSH key, xác minh truy cập thành công, sau đó tắt hoàn toàn đăng nhập bằng mật khẩu. Tiếp theo, có thể đổi port SSH, đồng thời bảo đảm firewall và SELinux được cấu hình chính xác nếu môi trường yêu cầu.

Khi thực hiện đúng, bạn sẽ chặn được gần như toàn bộ kiểu tấn công phổ thông nhắm vào SSH, giảm đáng kể log rác và tăng độ an toàn cho kênh quản trị quan trọng nhất của VPS. Với một dịch vụ nhạy cảm như SSH, vài thay đổi cấu hình đúng cách có thể tạo ra khác biệt rất lớn trong mức độ bảo vệ hệ thống.