Cách hardening SSH trên VPS để bảo mật

Tại sao SSH là thứ đầu tiên cần hardening

SSH là cách bạn điều khiển server, điều này biến nó thành ổ khóa mà mọi attacker đều thử đầu tiên. Ngay khi một VPS online, các scanner sẽ bắt đầu đoán username và password trên port 22. Bạn có thể thấy điều này xảy ra trong logs chỉ sau vài phút. Hardening SSH là loại bỏ những thứ mà chúng có thể đoán được: tắt hoàn toàn password login, tắt root login, và chỉ cho phép cryptographic keys đi vào. Khi bạn làm vậy, việc đoán liên tục sẽ không thể thành công, vì không còn password nào để tìm.

Điều này giả định rằng bạn đã có SSH hoạt động. Nếu bạn có thể log in, bạn có thể hardening nó. Hãy thực hiện các bước theo đúng thứ tự và giữ session hiện tại luôn mở cho đến khi một session mới hoạt động, để tránh sai sót khiến bạn bị khóa khỏi hệ thống.

Bước 1: Đảm bảo key authentication hoạt động trước

Key authentication thay thế password bằng một key pair: một private key nằm trên máy tính của bạn và một public key bạn đưa lên server. Server sẽ xác thực bạn đang giữ private key mà không cần nó phải rời khỏi máy của bạn. Trước khi bạn disable passwords, hãy xác nhận keys hoạt động, nếu không bạn sẽ tự khóa chính mình.

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

ssh-keygen -t ed25519

Copy phần public sang server:

ssh-copy-id user@your-server

Sau đó mở một SSH session mới. Nếu nó cho phép bạn vào mà không hỏi password, key của bạn đã hoạt động và bạn có thể an tâm tắt passwords. Nếu bạn mới làm quen với keys, hoặc sử dụng nhiều hơn một máy tính, kiến thức cơ bản về SSH key management sẽ giải thích mô hình đầy đủ: mỗi thiết bị một key, các permission mà sshd yêu cầu, và cách thu hồi một key khi laptop bị mất.

Bước 2: Harden sshd bằng một drop-in file

Đừng edit trực tiếp /etc/ssh/sshd_config. Ubuntu 24.04 đọc các drop-in files từ /etc/ssh/sshd_config.d/, và một file nhỏ tại đó sẽ sạch sẽ hơn, tồn tại sau khi nâng cấp package, và dễ dàng xóa bỏ nếu có lỗi xảy ra. Tên file rất quan trọng: sshd giữ giá trị đầu tiên mà nó đọc cho mỗi setting, và các Ubuntu cloud images đi kèm 50-cloud-init.conf với PasswordAuthentication yes trong directory này. Hãy đặt tên file của bạn là 00- để nó được sắp xếp trước file đó và được ưu tiên; một file 99- sẽ bị mất tác dụng một cách âm thầm. Tạo một file như sau:

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

Điền nội dung này vào:

# 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 là một cánh cửa được đóng lại. PasswordAuthentication no là quan trọng nhất: khi đã tắt passwords, một cuộc brute-force attack sẽ không còn gì để brute-force. KbdInteractiveAuthentication no đóng thêm một đường dẫn kiểu password thứ hai. PermitRootLogin no có nghĩa là attacker phải biết username của bạn và giữ key của bạn, chứ không chỉ nhắm vào tài khoản root luôn tồn tại trên mọi máy.

Bước 3: Test config, sau đó reload

Kiểm tra config để tìm lỗi trước khi áp dụng, để một lỗi typo không làm hỏng service:

sudo sshd -t

Nếu nó không in ra gì, config hợp lệ. Reload SSH:

sudo systemctl reload ssh

Sau đó kiểm tra các settings mà sshd thực sự đang dùng, để bạn bắt được trường hợp một drop-in bị ghi đè bởi một file khác:

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

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

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

Việc chuyển SSH khỏi port 22 sang một port như 2222 không làm nó bảo mật hơn về mặt thực tế, vì một attacker quyết tâm sẽ scan mọi port. Những gì nó làm là giảm nhiễu trong logs, vì hầu hết các automated scanners chỉ thử port 22. Nếu bạn muốn, hãy thêm Port 2222 vào drop-in file, mở port mới trong firewall trước, 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ý listening port, nên một lệnh reload ssh thông thường sẽ để sshd chạy trên 22; việc restart socket mới là cách để nhận port mới. Hãy coi đây là việc dọn dẹp, không phải là bảo vệ.

Bước 5: Thêm các lớp phòng thủ bổ sung

SSH keys đã được harden là nền tảng, và có thêm hai lớp nữa nằm trên chúng.

Fail2ban theo dõi logs của bạn và ban các địa chỉ liên tục thất bại, giúp giảm nhiễu scanner và loại bỏ chúng sớm. Nó kết hợp tự nhiên với key-only auth: xem Fail2ban trên Ubuntu để chặn các cuộc tấn công SSH.

Mạnh mẽ hơn nữa là việc đưa SSH ra khỏi internet công cộng hoàn toàn. Nếu bạn đặt SSH sau một WireGuard VPN và firewall port 22 chỉ cho phép tunnel, không ai bên ngoài VPN có thể tiếp cận nó, và brute-force guessing sẽ không còn là khả năng thực hiện được thay vì chỉ là khó khăn. Tất cả những điều này giả định bạn có một firewall mặc định là deny, tương tự như cài đặt UFW trên VPS.

SSH chỉ là một dòng trong một checklist lớn hơn: 10 phút đầu tiên trên một VPS mới sắp xếp các bước theo thứ tự, và automatic security updates trên Ubuntu giúp máy luôn được patch sau đó.

FAQ

Làm thế nào để disable password login cho SSH trên Ubuntu 24.04?

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

Tôi có nên disable root login qua SSH không?

Có. Hãy set PermitRootLogin no để không ai có thể log in trực tiếp dưới quyền root. Hãy log in bằng user bình thường của bạn và dùng sudo cho các tác vụ admin. Root tồn tại trên mọi máy Linux, nên việc để nó có thể truy cập được sẽ cung cấp cho attacker một username đã biết để nhắm tới. Disable nó có nghĩa là chúng phải biết tên tài khoản của bạn và phải giữ key của bạn.

Việc đổi SSH port có giúp server bảo mật hơn không?

Không đáng kể. Việc chuyển khỏi port 22 giúp bạn ẩn mình khỏi các scanner lười biếng chỉ probe port 22, giúp giảm nhiễu logs, nhưng một attacker thực sự sẽ scan mọi port và vẫn tìm ra bạn. Key-only authentication mới là thứ thực sự ngăn chặn xâm nhập. Nếu bạn đổi port, hãy mở port mới trong firewall trước, sau đó chạy sudo systemctl daemon-reload && sudo systemctl restart ssh.socket; trên Ubuntu 24.04, socket quản lý listener, và một lệnh reload thông thường sẽ để sshd ở port 22.

Tôi có cần Fail2ban nếu đã dùng SSH keys không?

Nó là tùy chọn nhưng vẫn hữu ích. Với key-only authentication, việc đoán password không thể thành công, nên Fail2ban không phải là thứ giữ attacker ở bên ngoài. Nó giới hạn tốc độ (rate-limit) các lần thất bại lặp lại từ một địa chỉ, giúp giảm nhiễu scanner trong logs và loại bỏ những kẻ vi phạm lặp lại sớm; một cuộc tấn công chậm, phân tán dù sao cũng sẽ nằm dưới ngưỡng ban của nó. Hãy chạy nó cùng với key auth, và lý tưởng nhất là giữ SSH sau một VPN.

Tôi phải làm gì để khôi phục nếu bị khóa khỏi SSH?

Sử dụng web console của nhà cung cấp, thứ cho phép bạn truy cập server qua kết nối serial hoặc VNC mà không đi qua SSH. Từ đó bạn có thể log in, sửa file drop-in sshd, và reload service. Đây chính là lý do tại sao bạn phải test một SSH config mới trong một terminal thứ hai trước khi đóng session đầu tiên, và tại sao key authentication nên hoạt động sẵn trước khi bạn tắt passwords.