SSH Hardening: Authentication, Access & Lockout Safety

SSH Hardening là việc thu hẹp remote-access boundary của Linux server: ai được phép mở SSH session, họ xác thực bằng cách nào, root có được login trực tiếp hay không, source network nào được phép kết nối và những forwarding feature nào thực sự cần. Bài này không sở hữu việc thiết kế sudo/root privilege sau khi user đã đăng nhập; phần đó thuộc Root, sudo & Least Privilege.

OpenSSH hiện hỗ trợ các policy như PermitRootLogin, AllowUsers, AllowGroups, PasswordAuthentication và forwarding controls. Upstream hiện để PermitRootLogin prohibit-password và PasswordAuthentication yes theo mặc định, nhưng distro/include/Match có thể làm effective state khác. Vì vậy owner task của bài này là effective SSH config → safe change → reload → new-session login test → rollback safety.

Chuẩn bị và đọc effective SSH state

1. Khóa đường recovery trước khi sửa SSH

Rủi ro lớn nhất của SSH hardening là tự lockout. Trước thay đổi production:

Giữ ít nhất một SSH session đang hoạt động.
Xác minh console/rescue path từ VPS/cloud provider nếu có.
Backup config và include liên quan.
Chỉ thay một nhóm policy mỗi lần.
Chạy syntax check trước reload.
Mở session mới để test trước khi đóng session cũ.

sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.before-hardening
sudo sshd -t

2. Đọc effective config, không chỉ đọc một file

OpenSSH có thể dùng Include và conditional Match. Vì vậy evidence chính nên là:

sudo sshd -T

Có thể lọc các option sở hữu bởi bài này:

sudo sshd -T | egrep 'permitrootlogin|passwordauthentication|pubkeyauthentication|maxauthtries|permitemptypasswords|allowusers|allowgroups|allowtcpforwarding|allowagentforwarding|x11forwarding'

Nếu cần đánh giá một Match cụ thể, dùng cách test phù hợp với user/source tương ứng thay vì suy luận từ global block.

Authentication và identity controls

PermitRootLogin quyết định root có thể mở SSH session trực tiếp hay không. Với nhiều web server, policy rõ ràng là dùng named admin account rồi mới nâng quyền khi cần:

PermitRootLogin no

Chỉ áp dụng sau khi xác minh account quản trị thay thế đăng nhập được và recovery path tồn tại. Nếu automation/recovery đang phụ thuộc root SSH, dependency đó phải được thiết kế lại trước khi cắt đường cũ.

Sau khi user login, câu hỏi “user đó được sudo tới đâu?” thuộc bài Least Privilege, không phải SSH Hardening.

4. Public-key authentication và password authentication

Key-based authentication giúp giảm exposure với brute-force password, nhưng key vẫn là credential cần owner và revocation path. Bài này chỉ kiểm tra SSH có chấp nhận đúng authentication method intended hay không; vòng đời secret/key chi tiết thuộc Server Secrets Management.

Nếu key-based access và recovery đã được test, có thể cân nhắc:

PubkeyAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no

Với PAM, MFA hoặc identity provider, phải hiểu authentication chain thực tế trước khi tắt password vì các option có thể tương tác với nhau.

5. Giới hạn user/group nào được mở SSH session

AllowUsers và AllowGroups giúp tách “local account tồn tại” khỏi “account được remote login”. Ví dụ:

AllowGroups ssh-admins

Trước rollout, xác minh group membership và test bằng session mới. Service account không cần SSH có thể vẫn tồn tại cho daemon mà không cần được phép remote login.

6. MaxAuthTries và authentication noise

MaxAuthTries giới hạn số authentication attempts trong một connection. Có thể hạ giá trị nếu phù hợp với client thực tế:

MaxAuthTries 3

Đừng chọn số chỉ vì “hardening chuẩn”. SSH agent có nhiều key có thể gây failure ngoài ý muốn; cần test từ client thật.

Network và SSH capabilities

7. Forwarding là một phần của remote-access capability

SSH có TCP forwarding, agent forwarding, X11 forwarding và Unix-socket forwarding. Nếu workload không cần, có thể thu hẹp:

X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no

OpenSSH lưu ý rằng tắt forwarding không tạo boundary mạnh nếu user vẫn có shell và có thể chạy forwarder khác. Vì vậy đây là giảm capability trong SSH, không thay privilege control ở OS.

8. Giới hạn source network nếu kiến trúc cho phép

Firewall hoặc cloud security group có thể giới hạn SSH chỉ từ VPN, bastion, office CIDR hoặc management network. Đây thường là cách giảm Internet exposure mạnh hơn đổi port.

Trước restrict, cần inventory source quản trị, IPv4/IPv6, bastion/VPN dependency và console fallback. Network rule chi tiết thuộc Linux Firewall.

9. Đổi port SSH chỉ là noise reduction

Đổi khỏi port 22 có thể giảm bot noise/log volume nhưng không thay authentication, source restriction hay privilege. Scanner vẫn có thể tìm service ở port khác. Vì vậy port change không nên là acceptance criterion chính của SSH security.

Logging và validation

10. Logging và brute-force signal

SSH cần log đủ để thấy login success/failure, user, source và policy violation. Tùy distro:

journalctl -u ssh --since '1 hour ago' --no-pager
journalctl -u sshd --since '1 hour ago' --no-pager

Fail2ban hoặc rate limiting có thể bổ sung cho Internet-facing SSH, nhưng không thay key authentication hoặc network restriction.

11. Safe reload và new-session validation

sudo sshd -t
sudo sshd -T | egrep 'permitrootlogin|passwordauthentication|allowusers|allowgroups|maxauthtries'

Sau reload theo service manager của distro, mở một session mới bằng đúng user/key/source intended. Chỉ đóng session cũ khi login mới hoạt động. Nếu user cần privileged task, chỉ xác minh task đó theo runbook; thiết kế sudo policy thuộc owner page riêng.

SSH Access Policy Matrix

Artifact này tập trung vào remote access, không phải toàn bộ privilege model.

Control	Observed	Expected	Validation
Root SSH	`sshd -T`	Policy-defined	Effective config + login test
Auth method	Password/key/MFA chain	Intended method only	New-session test
Allowed identities	User/group policy	Named remote users/groups	Membership + login test
Source network	Public/private	Intended sources	Socket/firewall/read-back
Forwarding	Enabled/disabled	Workload-specific	Effective config

Checklist SSH Hardening

Recovery/console path đã xác minh.
Backup SSH config/include.
sshd -t PASS.
Đọc sshd -T.
Root-login policy rõ.
Authentication method đúng thiết kế.
Named users/groups được giới hạn khi phù hợp.
MaxAuthTries được test với client thực tế.
Forwarding chỉ bật khi cần.
Source network được giới hạn khi kiến trúc cho phép.
Auth logs hoạt động.
New-session login test PASS trước khi đóng session cũ.

Nguồn kỹ thuật tham khảo

Kết luận

Owner của SSH Hardening là remote access: identity nào được mở session, authentication method nào được chấp nhận, source nào được phép kết nối và capability forwarding nào cần thiết.

Sau khi SSH session được mở, quyền root/sudo thuộc Least Privilege; vòng đời private key/token thuộc Secrets Management. Tách ba owner này giúp giảm overlap và làm acceptance test của SSH rõ: effective config đúng + new-session login đúng + rollback path còn hoạt động.

Dịch vụ liên quan: Nếu bạn cần triển khai hoặc vận hành chuyên sâu, xem dịch vụ bảo mật server.