云服务器密钥对登录是替代密码登录的一种更安全的认证方式，也是安全加固的基础操作之一。很多用户在配置时容易忽略权限设置或误改 SSH 配置导致无法登录。本文先给出一个清晰的判断路径，再逐步展开配置细节与加固要点，帮助你避开常见陷阱。
判断路径：先看场景，再定方案
在动手之前，先回答三个问题：你的云服务器是单机还是集群？是否已有现有用户？是否需要自动化？根据答案选择不同的密钥管理和配置方式：
- 单机且手动管理：直接在服务器上生成密钥对，并将公钥添加到 ~/.ssh/authorized_keys。
- 多实例或团队协作：使用集中式密钥管理或配置管理工具（如 Ansible）分发公钥，避免手工复制。
- 自动化部署：将公钥嵌入镜像或使用 cloud-init 注入，实现首次启动即可用密钥登录。
明确场景后，再进入具体配置步骤。
密钥对的生成与导入
云服务器密钥对通常由云厂商生成，例如 AWS EC2 在启动实例时允许创建或导入密钥对。你也可以在本地生成 RSA 或 Ed25519 密钥，然后将公钥上传到服务器。生成命令如下：
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"生成后，私钥保存在本地（如 ~/.ssh/id_rsa），公钥为 ~/.ssh/id_rsa.pub。将公钥内容追加到服务器的 ~/.ssh/authorized_keys 文件中：
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys注意：如果使用云厂商的控制台创建密钥对，私钥只会下载一次，务必妥善保管。
权限设置：最常见的失败原因
密钥登录失败往往是因为文件权限过于宽松。SSH 会严格检查以下权限：
- ~/.ssh 目录权限应为 700（仅所有者可读写执行）
- ~/.ssh/authorized_keys 文件权限应为 600
- 私钥文件权限应为 600（本地）
如果权限不正确，SSH 会拒绝使用密钥。修正命令：
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys配置 SSH 服务：启用密钥认证，禁用密码登录
编辑 /etc/ssh/sshd_config，确保以下配置：
PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no修改后重启 SSH 服务：
sudo systemctl restart sshd在禁用密码登录前，务必先测试密钥登录是否可用，否则可能被锁在外面。建议在另一个终端保持会话，确认无问题后再重启服务。
安全加固：不止于密钥
密钥对只是第一步。根据 AWS 安全性支柱的建议，还需要考虑以下加固措施：
- 使用强加密算法：优先选择 Ed25519 或 4096 位 RSA 密钥。
- 定期轮换密钥：定期更换密钥对，并撤销旧密钥。
- 限制 root 登录：禁止 root 直接 SSH，使用普通用户登录后 su 切换。
- 配置防火墙和安全组：仅允许来自可信 IP 的 SSH 连接。
- 使用 SSH 代理或跳板机：避免私钥在多个设备间复制。
此外，成本优化支柱提醒，合理配置实例规格和资源，避免过度配置，这也是安全与成本的平衡。
常见误区与失败条件
以下误区容易导致配置失败或安全漏洞：
- 忽略权限设置：这是最常见的失败原因，务必检查。
- 在禁用密码登录前未测试密钥：极易导致无法登录。
- 将私钥泄露或上传到公开仓库：私钥应严格保密，可考虑使用 SSH agent。
- 在 authorized_keys 中添加多余公钥：应定期审计。
- 未设置 SELinux/AppArmor 策略：某些系统可能阻止 SSH 读取 authorized_keys，需调整策略。
总结
云服务器密钥对登录是安全加固的基石，但配置过程需要细心。先明确场景，再按步骤生成密钥、设置权限、修改 SSH 配置，最后测试并加固。记住：密钥登录不是终点，还需结合安全组、权限审计等综合措施，才能构建稳固的防线。
参考资料
延伸阅读