这项整改解决什么

SSH 加固围绕两条要求展开：身份鉴别要满足复杂度与失败处理要求，远程管理要防止鉴别信息在网络传输中被窃听。落地动作主要是禁用口令登录与 root 直登、改用密钥认证、限制尝试次数、设置空闲超时断开，并可选做来源地址限制。SSH 通常也是运维唯一的入口，因此这项整改的技术动作很简单，风险却集中在「改完能不能再登录」上。

sshd_config 关键项

# /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 1
X11Forwarding no
# 如启用来源限制（在 sshd_config 末尾追加）
AllowUsers ops@10.20.* deploy@10.20.*

生效与验证

# 1 先做语法检查，避免配置错误导致服务起不来
sshd -t
# 2 重载服务（保留一个已登录会话）
systemctl reload sshd
# 3 用「最终生效配置」反向确认，而不是只看文件
sshd -T | grep -E 'permitrootlogin|passwordauthentication|maxauthtries'
# 4 新窗口验证密钥登录成功、口令登录失败
ssh -o PreferredAuthentications=publickey ops@server

加固项与对应条款

• 禁用口令登录：身份鉴别要求鉴别信息复杂度，密钥认证从根上规避弱口令
• 禁止 root 直登：访问控制中最小权限与账号责任分离
• 限制尝试次数：登录失败处理要求
• 空闲超时断开：会话管理与会话超时要求
• 管理来源限制：区域边界对管理流量的访问控制要求

基本信息

典型使用场景

• 三级测评整改：远程管理加密与身份鉴别条款的常规落地动作
• 新服务器初始化：把加固项写进镜像或初始化脚本，避免逐台配置
• 安全事件后收紧入口：爆破尝试后从口令认证切换到密钥认证
• 临时运维账号治理：结合 AllowUsers 与证书有效期控制外部人员接入

加固前先想清楚三件事

第一，谁是这台机器的合法登录者，加固后他们的密钥是否都已就位，尤其是自动化脚本、监控采集与备份任务使用的账号，它们一旦不能用口令登录就会静默失败。第二，是否存在无法使用密钥的旧设备或老旧系统，需要为它们保留受限的口令通道并加来源限制。第三，变更窗口内能不能回滚，配置备份与带外通道是否可用。把这三件事确认完再动手，加固才是可控的。

配套加固动作

• 更新 SSH 服务版本：老版本存在历史漏洞，升级比改参数更重要
• 禁用旧算法：关闭弱密钥交换与弱加密套件，仅保留现代算法
• 限制监听地址：只在内网或管理网段监听，避免暴露在业务网段
• 日志纳入集中平台：把 SSH 登录成功与失败记录转发出去，用于爆破识别
• 配合登录失败封禁：失败次数阈值与自动封禁联动，减少暴力尝试压力

常见参数与作用