SSH 安全加固怎么做？生产服务器必改的 8 项配置与面试追问
SSH 安全加固是运维和后端面试中的高频考点，也是生产服务器上线前必须完成的配置。本文从实际生产场景出发，梳理 SSH 加固的核心配置项，每项给出"为什么做"和"怎么配"，并在文末附上面试常见追问。
修改默认端口：降低被扫描概率
SSH 默认监听 22 端口，这是所有自动化扫描工具的首要目标。改成非标准端口后，扫描流量会大幅下降，日志噪音也明显减少。
# /etc/ssh/sshd_config Port 2222
修改端口后记得同步更新防火墙规则和 Fail2Ban 配置，否则改了端口反而把自己锁在外面。另外，改端口属于"降低攻击面"而非"增强安全性"，不要因此放松其他加固措施。
禁用 root 登录：权限最小化
允许 root 直接 SSH 登录意味着一旦密钥或密码泄露，攻击者立即获得最高权限。正确的做法是用普通用户登录，再通过 sudo 提权。
# /etc/ssh/sshd_config PermitRootLogin no
部署前要确认普通用户的 sudo 权限已配置好，否则禁用 root 后将无法执行管理操作。
强制公钥认证：干掉暴力破解
密码认证最大的风险是暴力破解，即使设了复杂密码也难逃字典攻击。公钥认证用非对称加密，私钥不离开本地，攻击面极小。
# /etc/ssh/sshd_config PasswordAuthentication no PubkeyAuthentication yes
切换顺序很重要：先部署公钥到服务器，测试公钥登录成功，再禁用密码认证。如果反着来，你可能会丢掉唯一能登录的方式。
限制登录用户：白名单比黑名单可靠
不限制登录用户意味着系统上的所有账户（包括服务账户）都可以尝试 SSH 登录。用白名单方式只允许运维人员登录，是更安全的做法。
# /etc/ssh/sshd_config AllowUsers deploy admin@10.0.0.0/8 AllowGroups sshusers
SSH 处理顺序是 DenyUsers → AllowUsers → DenyGroups → AllowGroups，建议用 AllowUsers 或 AllowGroups 做白名单，比 DenyUsers 黑名单更可控。
启用多因素认证：密钥 + 动态口令
密钥认证虽然安全，但如果私钥文件被盗，攻击者就能直接登录。多因素认证（MFA）要求同时持有密钥和动态口令，即使私钥泄露也无法单独使用。
# /etc/ssh/sshd_config AuthenticationMethods publickey,keyboard-interactive:pam # 安装 Google Authenticator PAM 模块 sudo apt-get install libpam-google-authenticator # 为用户生成 TOTP 密钥 google-authenticator # /etc/pam.d/sshd 添加 auth required pam_google_authenticator.so
生产环境建议 MFA 仅对跳板机或入口机开启，内网机器可以只做密钥认证，平衡安全和效率。
加密算法优化：淘汰弱算法
OpenSSH 支持多种加密算法，其中一些已被证明存在安全缺陷（如 3DES、CBC 模式、SHA1）。只保留安全的算法可以防止降级攻击。
# /etc/ssh/sshd_config Ciphers aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group16-sha512 MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com
可以用 ssh -Q cipher 查看当前 OpenSSH 支持的算法列表，用 sshd -T | grep -i cipher 查看实际生效配置。推荐使用 ssh-audit 工具对服务器做算法安全审计。
连接限制与超时：防暴力破解和会话劫持
暴力破解靠大量尝试碰运气，限制认证次数和连接速率能有效遏制。空闲会话不断开则可能被他人利用，设置超时是必要的。
# /etc/ssh/sshd_config MaxAuthTries 3 MaxSessions 2 MaxStartups 10:30:100 LoginGraceTime 60 ClientAliveInterval 300 ClientAliveCountMax 0
MaxStartups 10:30:100 的含义：未完成认证的连接超过 10 个时，新连接有 30% 概率被拒绝；超过 100 个则全部拒绝。ClientAliveCountMax 0 表示连续 0 次无响应即断开，配合 ClientAliveInterval 300 实现 5 分钟无操作自动断开。
网络层防护：防火墙 + Fail2Ban + TCP Wrapper
SSH 加固不能只靠 sshd_config，网络层防护是第二道防线。三层配合使用效果最好。
防火墙限制来源 IP：
# iptables: 仅允许内网段访问 iptables -A INPUT -p tcp --dport 2222 -s 10.0.0.0/8 -j ACCEPT iptables -A INPUT -p tcp --dport 2222 -j DROP # ufw: 更简洁的写法 ufw allow from 10.0.0.0/8 to any port 2222
Fail2Ban 自动封禁：
# /etc/fail2ban/jail.local [sshd] enabled = true port = 2222 filter = sshd logpath = /var/log/auth.log maxretry = 3 bantime = 3600 findtime = 600
TCP Wrapper 兜底：
# /etc/hosts.allow sshd: 10.0.0.0/8 # /etc/hosts.deny sshd: ALL
三者防护逻辑不同：防火墙在网络层过滤数据包，Fail2Ban 根据行为模式动态封禁，TCP Wrapper 在应用层做访问控制。不要只依赖其中一种。
面试追问与回答
Q: 只改端口能防住攻击吗？
不能。改端口只是降低了被自动化工具发现的概率，端口扫描器仍然可以遍历所有端口找到 SSH 服务。改端口是辅助手段，核心安全还是要靠密钥认证、禁用 root、限制来源 IP 这些实质性加固。
Q: 密钥认证就够安全了吗？什么场景还需要 MFA？
密钥认证比密码安全得多，但私钥文件一旦泄露（比如开发机被入侵），攻击者就能直接登录服务器。以下场景必须上 MFA：面向公网暴露的跳板机、拥有高权限的核心服务器、合规要求（等保三级及以上）的场景。
Q: ClientAliveInterval 和 LoginGraceTime 区别是什么？
两者作用阶段完全不同。LoginGraceTime 控制的是"连接建立后多久没完成认证就断开"，防的是半开连接占用资源；ClientAliveInterval 控制的是"认证成功后多久没操作就断开"，防的是空闲会话被利用。生产环境建议前者设 60 秒，后者设 300 秒。
Q: 怎么验证 SSH 加固配置是否生效？
分三步验证：用 sshd -T 检查配置是否被正确加载；用 ssh-audit 工具扫描服务器，它会给出算法强度和配置问题的评分；用另一台机器尝试以 root 登录、密码登录、从非白名单 IP 登录，确认都被拒绝。修改配置前务必保留一个已登录的会话，防止配置错误把自己锁在外面。