Linux SSH安全提升需系统性落实身份验证、通信加密、访问控制和日志审计四环节：禁用密码登录启用密钥认证，限制用户与IP，调整端口及超时参数，开启PAM失败锁定，并配置详细日志与告警。
Linux SSH 安全提升不是靠一两个技巧堆砌，而是建立在身份验证、通信加密、访问控制和日志审计四个核心环节上的系统性实践。标准流程不追求“最严”，而强调“可落地、可维护、可追溯”——适用于从单台VPS到百台集群的全部场景。
禁用密码登录，强制密钥认证
密码登录是暴力破解的主入口，90%以上的 SSH 入侵始于弱口令或撞库。必须关闭它，只保留公钥认证。
- 编辑 /etc/ssh/sshd_config，确认以下三项已设置：
- PubkeyAuthentication yes
- PasswordAuthentication no
- PermitEmptyPasswords no
- 重启服务：sudo systemctl restart sshd（或 sshd，取决于发行版）
- 操作前务必确保本地已有可用密钥对，且公钥已写入目标机 ~/.ssh/authorized_keys；建议先开一个备用会话验证连通性再重启
限制登录用户与来源IP
最小权限原则在 SSH 层最直接的体现就是：谁可以登、从哪登、登到哪。
- 用 AllowUsers 或 AllowGroups 明确放行账户（如 AllowUsers deploy admin），拒绝未列明用户
- 配合防火墙（如 ufw 或 iptables）限制 SSH 端口（默认22）仅对可信 IP 段开放，例如：
ufw allow from 192.168.10.0/24 to any port 22 - 如需远程办公，避免直接暴露 22 端口，可改用非标端口（如 2222），但注意：端口混淆 ≠ 安全，仅作基础过滤，仍需配合密钥+IP白名单
加固SSH服务配置本身
OpenSSH 默认配置偏宽松，几项关键调整能大幅降低攻击面。
- Port 22 → 改为非标端口（如 Port 2222），虽不防专业扫描，但能过滤掉绝大多数自动化脚本
- LoginGraceTime 60：缩短登录等待时间，减少暴力尝试窗口
- MaxAuthTries 3：单次连接最多允许3次认证失败
- ClientAliveInterval 300 与 ClientAliveCountMax 2：5分钟无响应断连，防会话堆积与僵尸连接
- 启用 UsePAM yes 后，可联动 faillock（RHEL/CentOS）或 pam_faildelay（Debian/Ubuntu）实现登录失败锁定
开启审计与异常响应
安全不是“防住就完事”，而是“出事能定位、能回溯、能止损”。
- 确保 LogLevel VERBOSE 或 INFO（避免 DEBUG，防止日志爆炸），日志路径通常为 /var/log/auth.log（Debian系）或 /var/log/secure（RHEL系）
- 用 journalctl -u sshd -f 实时监控新连接与失败记录
- 部署简易告警：例如用 awk + grep + mail 脚本检测 10 分钟内连续5次失败登录，自动发邮件；或接入 fail2ban 自动封禁可疑 IP（注意勿误封云厂商健康检查IP）
- 定期归档日志并校验完整性（如用 aide 或 sha256sum 记录日志文件哈希）
基本上就这些。没有银弹，但每一步都踩在攻击链的关键节点上。做全不难，难在坚持——尤其别让“临时开个密码登录调试一下”变成常态。安全是习惯，不是补丁。
