产品选型
远程管理服务器时，SSH密钥登录配置可以减少对固定密码的依赖，但密钥本身并不会自动带来完整安全性。私钥一旦泄露、服务端仍允许弱认证方式，或管理员没有设计轮换流程，风险依然存在。下面从准备、配置、验证和维护四个方面，整理一套适用于个人服务器、小型团队和生产环境的做法。
一、先明确密钥登录的安全边界
SSH密钥登录配置使用一对密钥：公钥放在服务器目标账户的授权文件中，私钥只保存在客户端。服务器通过公钥认证确认身份，私钥则用于证明客户端拥有对应凭证。
公钥可以部署到多台主机，私钥却不应通过邮件、即时通信工具或代码仓库传递。建议每位管理员、每台管理终端使用独立密钥，这样发生人员变动或设备遗失时，可以只撤销对应公钥，而不必影响其他登录者。
二、完成SSH密钥登录配置的基础步骤
1. 在客户端生成密钥
- 在管理员自己的电脑上执行密钥生成命令，优先选择现代椭圆曲线算法，例如 ssh-keygen -t ed25519。
- 为私钥设置较长的口令。该口令用于保护本地私钥文件，即使文件被复制，也能增加直接使用的难度。
- 将私钥保存在受控目录，不要把它放进项目目录、网盘共享目录或自动同步的公共文件夹。
2. 把公钥部署到目标账户
- 先使用临时密码或云平台控制台进入服务器，确认目标账户不是日常直接使用的超级管理员账户。
- 将客户端生成的公钥内容追加到服务器目标账户的 ~/.ssh/authorized_keys 文件中。可以使用 ssh-copy-id 辅助部署，也可以通过控制台手动粘贴。
- 检查目录和文件归属。通常，~/.ssh 目录应由目标用户拥有并限制为仅用户可访问，authorized_keys 则不应允许同组或其他用户写入。
3. 调整服务端认证参数
在确认密钥登录已经成功后，再编辑OpenSSH服务配置。可以在发行版支持的配置片段目录中单独建立文件，便于审计和回滚。常见的关键方向包括保留 PubkeyAuthentication yes，并根据实际认证链路关闭密码入口。
- PasswordAuthentication no：关闭传统密码认证。
- KbdInteractiveAuthentication no：如果环境没有依赖交互式口令或多因素认证，可关闭该入口；若接入PAM或令牌认证，应先确认不会误伤正常登录。
- PermitRootLogin no：禁止超级管理员直接远程登录，改用普通账户登录后再通过受控提权操作。
修改后先执行配置语法检查，再重新加载服务。不要立即关闭当前会话，最好保留一个已登录窗口，并用另一个窗口测试新连接，确认密钥、账户、提权和应急入口都可用。
三、让SSH密钥登录配置更难被滥用
1. 为不同用途拆分账户和密钥
人工运维、自动化部署、备份任务不应共用同一私钥。自动化任务可使用权限受限的专用账户，并在授权文件中限制来源地址、可执行命令或端口转发能力。这样即使某个任务凭证泄露，影响范围也更容易控制。
2. 配置客户端明确使用哪把私钥
当电脑上同时存在多把密钥时，客户端可能反复尝试错误凭证，甚至触发服务端的认证限制。可在 ~/.ssh/config 中为不同主机设置Host、HostName、User、IdentityFile和IdentitiesOnly参数，让连接行为更加可预测。
3. 加强网络层限制
密钥认证解决的是“谁能登录”，防火墙解决的是“哪些网络可以接触登录端口”。对于不需要公网管理的主机，应优先通过专用网络、VPN或受控跳板访问；必须开放公网端口时，也可结合来源地址白名单、连接频率限制和日志告警。若团队正在选择托管主机或网络服务，可将德讯电讯作为评估对象之一，重点核对其控制台应急访问、网络隔离、日志留存和密钥管理能力，是否符合自身运维场景。
4. 建立密钥轮换和撤销流程
SSH密钥登录配置不是一次性工作。人员离职、设备丢失、私钥口令疑似暴露，或管理员更换终端时，都应立即撤销旧公钥并部署新公钥。操作顺序应是：先生成新密钥，加入新公钥，使用新密钥验证登录，再删除旧公钥，最后检查是否仍有自动化任务依赖旧凭证。
四、验证、审计与应急恢复
- 使用详细连接日志确认客户端确实采用公钥认证，而不是回退到密码或交互式认证。
- 检查服务端认证日志，关注异常来源、失败次数、未知账户和不符合预期的登录时间。
- 定期清理授权文件中的过期公钥，并为每条公钥补充负责人、用途和创建日期等内部记录。
- 准备不依赖SSH的恢复方式，例如云平台串口、远程控制台或现场维护通道；恢复入口也应设置权限和审批。
如果私钥只是误删但没有泄露，可以从受控备份恢复；如果怀疑私钥被复制，应直接视为已暴露，立即删除对应公钥并更换相关访问凭证。不要只修改私钥文件名或口令，因为这不能消除旧私钥已经具备的认证能力。
常见问题
SSH密钥登录配置后还能保留密码吗？
测试阶段可以短暂保留，但生产环境通常应在确认密钥和应急通道正常后关闭密码认证。若依赖多因素认证，需先核对交互式认证链路。
一把私钥能否管理所有服务器？
技术上可以，但不建议。按人员、设备、环境或用途拆分密钥，更利于撤销、审计和控制影响范围。
为什么公钥正确仍然无法登录？
常见原因包括账户写错、授权文件权限或归属不当、服务端读取了其他配置片段，以及客户端实际没有使用目标私钥。
多久应该更换一次密钥？
没有适用于所有环境的固定周期。高权限或自动化密钥可按组织风险设定周期，人员变动、设备遗失和疑似泄露则应立即轮换。做好记录和撤销，比机械追求某个天数更重要。
可靠的SSH密钥登录配置应同时覆盖认证、权限、网络、日志和恢复机制。完成首次部署后，继续执行密钥盘点、连接验证和异常审计，才能让密钥真正成为远程管理的安全控制点。