SSH 是管理云主机最常用的远程入口，也是需要重点保护的攻击面。做好云服务器SSH安全配置，不只是修改一个端口，而是要同时控制身份、权限、网络范围和审计能力。以下 8 项建议可作为新服务器上线和日常加固的检查清单。
一、先建立最小权限账号
不要长期使用 root 账号直接登录。建议先创建普通管理员账号，仅在确有需要时通过 sudo 执行管理操作。这样即使凭据泄露，也能减少直接修改系统核心文件、安装程序或删除日志的风险。
- 创建个人或职责明确的管理账号。
- 将账号加入必要的管理组，并避免授予无关权限。
- 确认 sudo 权限可以正常使用后，再考虑关闭 root 远程登录。
二、优先使用 SSH 密钥认证
相比容易被猜测或重复使用的密码，SSH密钥通常更适合服务器登录。私钥应保存在受控设备中，并设置本地保护密码；公钥只写入目标服务器的授权文件。多人协作时，应为每个人配置独立密钥，避免共用一份凭据。
更换人员、设备丢失或怀疑密钥泄露时，应及时删除对应公钥。不要把私钥放入公开代码仓库、聊天记录或未经保护的共享目录。
三、关闭不必要的密码登录
完成密钥登录验证后，可在 SSH 服务配置中按需关闭密码认证。修改前先保留一个已验证的会话，避免配置错误导致无法连接。变更后应通过新连接确认生效，再关闭旧会话。
如果业务暂时必须使用密码，应设置较长且唯一的密码，并结合登录失败限制。不要因为方便排障而长期保留弱认证方式。
四、限制 SSH 的网络来源
端口限制不能替代身份认证，但可以缩小暴露范围。优先通过云平台安全组、防火墙或专用网络，仅允许办公出口、跳板机、VPN 网段等可信来源访问 SSH 端口。
- 删除不再使用的临时放行规则。
- 避免对所有公网地址永久开放管理端口。
- 变更办公网络或跳板机地址后，及时同步访问策略。
五、合理调整 SSH 服务参数
在确认业务兼容性的前提下，应检查 SSH 服务配置中的允许用户、认证方式、空闲连接和转发权限。对于不需要的端口转发、代理转发或图形化转发功能，可以关闭或限制。
修改配置前先备份文件，并使用系统提供的语法检查命令验证。配置项名称和可用参数可能因操作系统及 OpenSSH 版本不同而变化，应以当前环境文档为准。
六、增加多因素认证
对于公网管理入口、生产环境或权限较高的账号，可考虑启用多因素认证。即使密码或密钥发生泄露，攻击者仍需通过第二种校验方式才能完成登录。
部署前要准备恢复渠道，并明确设备丢失、人员离职和紧急登录的处理流程。多因素认证应与密钥、网络访问控制配合使用，而不是替代其他安全措施。
七、做好登录审计和告警
安全配置不能只看“能否登录”，还要确认“谁在什么时间从哪里登录”。应保留 SSH 登录成功、失败、账号变更、权限提升等相关日志，并将重要服务器的日志集中到受控位置。
可以针对短时间内大量失败登录、异常来源地址、非工作时段登录等情况设置告警。日志保留周期和访问权限应符合业务要求，避免审计记录被普通账号随意删除。
八、准备验证、备份与应急方案
每次调整 SSH 配置，都应先制定回退方法。推荐按以下顺序操作：
- 记录当前配置和已知可用的登录方式。
- 使用配置检查命令确认文件语法。
- 保留一个已登录的管理会话，再建立新会话测试。
- 确认普通账号、密钥、网络规则和权限均正常。
- 出现异常时，依照云平台控制台、串行终端或其他受控救援方式恢复。
同时，服务器系统、SSH 软件及相关依赖应按维护计划更新。更新前需要评估兼容性，并确保存在可用备份或快照，但不能把备份当作唯一安全措施。
常见问题
只修改 SSH 端口是否足够？
不够。修改端口只能减少部分自动化扫描，不能阻止针对真实端口的攻击，仍需使用密钥、访问控制和日志审计。
关闭 root 登录后还能管理服务器吗？
可以。使用具备必要 sudo 权限的普通账号登录，再按需执行管理命令即可。操作前应确认该账号和密钥已经验证成功。
密钥登录是否完全不需要密码？
服务器端可以关闭 SSH 密码认证，但私钥本身建议设置保护密码，以降低设备丢失后的风险。
改配置后无法连接怎么办？
不要立即关闭原有会话。先检查配置语法、网络规则和账号权限，并通过云平台提供的控制台或救援通道恢复。
总的来说，云服务器SSH安全配置应围绕“少暴露、强认证、低权限、可审计、能恢复”展开。将这 8 项建议纳入上线检查和定期复核，才能让 SSH 管理入口保持可控。
