Cách harden SSH trên VPS an toàn, không tự khóa

Vì sao SSH là thứ cần harden đầu tiên

SSH là cách bạn điều khiển server, nên đây là điểm mọi attacker thử đầu tiên. Ngay khi một VPS online, các scanner bắt đầu đoán username và password trên port 22. Bạn có thể thấy việc này trong log chỉ sau vài phút. Hardening SSH là loại bỏ những thứ attacker có thể đoán: tắt hoàn toàn đăng nhập bằng password, tắt đăng nhập bằng root và chỉ cho phép cryptographic key. Khi làm vậy, việc đoán liên tục không thể thành công vì không có password để tìm.

Phần này giả định SSH đã hoạt động. Nếu bạn có thể đăng nhập, bạn có thể harden SSH. Thực hiện các bước theo đúng thứ tự và giữ phiên hiện tại mở cho đến khi phiên mới hoạt động, để một lỗi không khiến bạn bị khóa khỏi server.

Bước 1: Trước tiên, hãy bảo đảm xác thực bằng key hoạt động

Xác thực bằng key thay password bằng một cặp key: private key nằm trên máy tính của bạn và public key được đặt trên server. Server xác minh bạn đang giữ private key mà private key không bao giờ rời khỏi máy. Trước khi tắt password, hãy xác nhận key hoạt động. Nếu không, bạn sẽ tự khóa quyền truy cập.

Trên máy tính của bạn, hãy tạo key nếu chưa có:

ssh-keygen -t ed25519

Chép phần public key lên server:

ssh-copy-id user@your-server

Sau đó mở một phiên SSH mới. Nếu bạn đăng nhập được mà không bị hỏi password, key đã hoạt động và bạn có thể an toàn tắt password. Nếu bị dừng với Permission denied (publickey), lỗi đó có thể che giấu 5 nguyên nhân khác nhau, còn output của ssh -v sẽ cho biết bạn đang gặp nguyên nhân nào trước khi bạn thay đổi bất kỳ thứ gì khác. Nếu bạn chưa quen với key hoặc sử dụng nhiều máy tính, kiến thức cơ bản về quản lý SSH key giải thích đầy đủ mô hình này: mỗi thiết bị dùng một key, các permission mà sshd yêu cầu và cách thu hồi key khi laptop bị thất lạc.

Bước 2: Tăng cường bảo mật sshd bằng file drop-in

Không chỉnh sửa trực tiếp /etc/ssh/sshd_config. Ubuntu 24.04 đọc các file drop-in từ /etc/ssh/sshd_config.d/. Một file nhỏ ở đó gọn hơn, vẫn được giữ nguyên sau khi nâng cấp package và dễ xóa nếu có sự cố. Tên file rất quan trọng: sshd giữ lại giá trị đầu tiên mà nó đọc cho từng thiết lập. Các cloud image của Ubuntu cung cấp 50-cloud-init.conf với PasswordAuthentication yes trong thư mục này. Đặt tên file là 00- để nó được sắp xếp trước file đó và được áp dụng. File 99- sẽ âm thầm bị bỏ qua. Tạo file:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

Đặt nội dung sau vào file:

# Key-only login: no passwords to guess.
PasswordAuthentication no
KbdInteractiveAuthentication no

# No direct root login. Log in as your user, then use sudo.
PermitRootLogin no

Mỗi dòng đóng một đường truy cập. PasswordAuthentication no là thiết lập quan trọng nhất: khi tắt đăng nhập bằng password, brute-force attack không còn gì để thử. KbdInteractiveAuthentication no đóng thêm một đường đăng nhập khác sử dụng password. PermitRootLogin no có nghĩa là attacker phải biết username của bạn và có key của bạn. Họ không thể chỉ nhắm vào tài khoản root, tài khoản tồn tại trên mọi máy.

Bước 3: Kiểm tra cấu hình, sau đó reload

Kiểm tra cấu hình để phát hiện lỗi trước khi áp dụng. Nhờ đó, một lỗi gõ sai không thể làm service bị lỗi:

sudo sshd -t

Nếu lệnh không in ra gì, cấu hình hợp lệ. Reload SSH:

sudo systemctl reload ssh

Sau đó kiểm tra các thiết lập mà sshd thực sự sử dụng. Việc này giúp phát hiện trường hợp một drop-in bị file khác ghi đè:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

Cả hai lệnh phải trả về no. Bây giờ, không đóng session hiện tại, hãy mở một session hoàn toàn mới từ terminal khác. Nếu bạn đăng nhập được bằng key, bạn đã hoàn tất. Nếu có lỗi, session đầu tiên vẫn đang mở để bạn sửa. Hai session chồng lấp là lớp bảo vệ an toàn, vì vậy không được bỏ qua bước này.

Bước 4: Cổng không tiêu chuẩn tùy chọn

Chuyển SSH từ cổng 22 sang một cổng như 2222 không thực sự làm hệ thống an toàn hơn, vì kẻ tấn công có chủ đích sẽ quét tất cả các cổng. Việc này chỉ giảm nhiễu trong log, vì hầu hết scanner tự động chỉ thử cổng 22. Nếu muốn dùng, hãy thêm Port 2222 vào file drop-in, trước tiên cho phép cổng mới trên firewall, sau đó chạy sudo systemctl daemon-reload && sudo systemctl restart ssh.socket và kết nối bằng ssh -p 2222. Trên Ubuntu 24.04, ssh.socket quản lý cổng đang lắng nghe, nên chạy reload ssh đơn thuần vẫn để sshd trên cổng 22; phải restart socket thì cổng mới mới được áp dụng. Hãy xem đây là việc dọn dẹp cấu hình, không phải biện pháp bảo vệ.

Bước 5: Thêm các lớp bảo vệ khác

SSH key được harden là nền tảng. Hai lớp bảo vệ khác sẽ được thêm lên trên nền tảng đó.

Fail2ban theo dõi log và ban các địa chỉ liên tục xác thực thất bại. Việc này giảm nhiễu từ các scanner và loại chúng sớm. Fail2ban kết hợp tự nhiên với cơ chế chỉ cho phép xác thực bằng key: xem Cài Fail2ban trên Ubuntu để chặn các cuộc tấn công SSH.

Mức bảo vệ cao hơn là loại SSH hoàn toàn khỏi Internet công cộng. Nếu bạn đặt SSH phía sau VPN WireGuard và dùng firewall chỉ cho phép cổng 22 qua tunnel, không ai ở ngoài VPN có thể tiếp cận SSH. Khi đó, việc đoán brute-force không còn khả thi, thay vì chỉ trở nên khó hơn. Cách này giả định firewall bên dưới đã được cấu hình theo chính sách mặc định từ chối mọi kết nối. Xem cấu hình UFW trên VPS.

SSH chỉ là một mục trong checklist lớn hơn: 10 phút đầu tiên trên VPS mới sắp xếp các bước theo đúng thứ tự, còn cập nhật bảo mật tự động trên Ubuntu giúp máy chủ luôn được vá sau đó. Khóa SSH cũng không bảo vệ các service phía sau nó. Vì vậy, nếu VPS này chạy password vault, harden Vaultwarden sẽ xử lý hai phần mà xác thực bằng key không bao phủ: admin token và file backup.

FAQ

Làm cách nào để tắt đăng nhập bằng password cho SSH trên Ubuntu 24.04?

Tạo file drop-in tại /etc/ssh/sshd_config.d/00-hardening.conf (tiền tố 00 khiến file này được sắp xếp trước 50-cloud-init.conf; nếu không, PasswordAuthentication yes trong file đó sẽ được áp dụng trước vì sshd giữ lại giá trị đầu tiên mà nó đọc) với nội dung PasswordAuthentication no và KbdInteractiveAuthentication no, chạy sudo sshd -t để kiểm tra, rồi chạy sudo systemctl reload ssh. Xác nhận đăng nhập bằng key hoạt động trong một session mới trước khi sử dụng cấu hình này. Chỉnh sửa file drop-in thay vì sshd_config giúp cấu hình không bị mất khi package upgrade và dễ hoàn tác.

Có nên tắt đăng nhập root qua SSH không?

Có. Đặt PermitRootLogin no để không ai có thể đăng nhập trực tiếp bằng root. Đăng nhập bằng user thông thường rồi dùng sudo cho các tác vụ quản trị. Root tồn tại trên mọi máy Linux, nên để tài khoản này có thể truy cập sẽ cung cấp cho attacker một username cố định để nhắm tới. Khi tắt đăng nhập root, attacker phải biết tên account của bạn và có key của bạn.

Đổi port SSH có giúp server an toàn hơn không?

Không đáng kể. Chuyển khỏi port 22 giúp tránh các scanner đơn giản chỉ kiểm tra port 22, nhờ đó giảm log noise, nhưng attacker thực sự sẽ scan mọi port và vẫn tìm thấy port mới. Authentication chỉ dùng key mới là yếu tố thực sự ngăn chặn việc bị breach. Nếu đổi port, hãy mở port mới trong firewall trước, rồi chạy sudo systemctl daemon-reload && sudo systemctl restart ssh.socket; trên Ubuntu 24.04, socket sở hữu listener, nên reload thông thường vẫn để sshd listen trên port 22.

Nếu dùng SSH key thì có cần Fail2ban không?

Fail2ban là tùy chọn nhưng vẫn hữu ích. Khi chỉ dùng authentication bằng key, việc đoán password không thể thành công, nên Fail2ban không phải cơ chế ngăn attacker truy cập. Nó giới hạn rate các lần thất bại lặp lại từ một địa chỉ, giúp giảm scanner noise trong log và loại bỏ sớm các nguồn liên tục vi phạm; một cuộc tấn công chậm, phân tán vẫn nằm dưới ngưỡng ban của nó. Hãy chạy Fail2ban cùng với key authentication và tốt nhất là đặt SSH phía sau một VPN.

Làm cách nào để khôi phục nếu tự khóa mình khỏi SSH?

Dùng web console của nhà cung cấp. Console này truy cập server qua kết nối serial hoặc VNC, không đi qua SSH. Từ đó, bạn có thể đăng nhập, sửa file drop-in sshd và reload service. Đây chính là lý do bạn phải kiểm tra cấu hình SSH mới trong terminal thứ hai trước khi đóng session đầu tiên, đồng thời phải bảo đảm key authentication đã hoạt động trước khi tắt password.