Linux SSH 密钥登录配置与常见故障排查

前言

平时管理 Linux 云服务器，SSH 基本是每天都会用到的工具。相比每次输入服务器账号密码，使用 SSH 密钥认证可以减少重复操作，也便于管理多台服务器。

不过第一次配置时，经常会碰到公钥明明已经上传，连接时却仍要求输入密码的问题。下面以 Ubuntu、Debian 为例，介绍密钥登录的基本流程以及常见排查方法。

一、SSH 密钥认证的原理

SSH 密钥认证使用一对密钥：

• 私钥：保存在客户端，不应该上传到服务器或公开分享。
• 公钥：放在服务器对应用户的 authorized_keys 文件中。

连接时，客户端通过私钥证明自己的身份，服务器使用已授权的公钥验证。

需要注意，密钥登录不代表私钥一定没有密码。如果生成密钥时设置了口令（passphrase），使用私钥时仍可能需要输入口令，但不再依赖服务器账户密码完成认证。

二、在本地生成密钥

在本地 Linux 终端或 Windows PowerShell 中执行：

ssh-keygen -t ed25519 -C "cloud-server"

按照提示选择保存路径，并根据需要设置私钥口令。

默认情况下会生成两个文件：

~/.ssh/id_ed25519
~/.ssh/id_ed25519.pub

其中不带 .pub 的是私钥，带 .pub 的是公钥。

Ed25519 是目前 OpenSSH 常用的密钥类型之一，密钥较短，适合日常服务器登录。

三、把公钥添加到服务器

如果本地使用 Linux 或 WSL，并且安装了 ssh-copy-id，可以执行：

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server-ip

把 user 替换成服务器登录用户名，server-ip 替换成服务器地址。

这条命令会把本地公钥添加到目标用户的授权密钥文件中。执行时通常需要先使用服务器当前允许的认证方式完成登录。

如果没有 ssh-copy-id，也可以手动把公钥内容追加到服务器对应用户的：

~/.ssh/authorized_keys

每个公钥一般占一行，不要把私钥内容放进去。

如果 SSH 使用了自定义端口，ssh-copy-id 可以通过 -p 指定端口。

四、检查文件权限

如果公钥已经添加，但服务器仍然拒绝密钥认证，可以先检查文件权限。

使用目标账号登录服务器后执行：

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

同时确认 .ssh 目录和 authorized_keys 属于正确的用户。

OpenSSH 默认会检查相关文件和目录的安全性。如果授权密钥文件或上级目录可以被其他用户随意修改，服务器可能拒绝使用该文件进行认证。

另外，也要确认公钥放在了正确账号的家目录下。例如使用 ubuntu 登录，就需要检查 ubuntu 用户的授权密钥文件，而不是其他账号的文件。

五、测试 SSH 密钥登录

在本地执行：

ssh -i ~/.ssh/id_ed25519 user@server-ip

如果服务器使用非默认端口，可以指定：

ssh -p 2222 -i ~/.ssh/id_ed25519 user@server-ip

这里的 2222 只是示例端口，需要替换成实际配置。

如果连接失败，可以添加详细日志参数：

ssh -vvv -i ~/.ssh/id_ed25519 user@server-ip

重点查看客户端是否尝试使用了指定密钥，以及服务器是否接受该公钥。

六、检查服务端配置和日志

如果确认公钥文件没有问题，可以继续查看 SSH 服务端配置。

在 Ubuntu、Debian 中，常见配置文件是：

/etc/ssh/sshd_config

部分系统还会读取：

/etc/ssh/sshd_config.d/

重点关注两个配置项：

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

这里展示的是常见配置方式，实际生效值可能受到其他配置文件及 Match 规则影响。

修改 SSH 服务端配置后，建议先进行语法检查：

sudo sshd -t

确认无误后，再根据需要重新加载或重启 SSH 服务。

还可以查看最近的认证日志：

sudo journalctl -u ssh -n 50 --no-pager

如果系统使用的服务单元名称不同，应替换成实际的 SSH 服务名。

七、不要急着关闭密码登录

配置密钥认证后，有些教程会建议直接把 PasswordAuthentication 设置为 no。

这样做可以减少服务器密码登录的攻击面，但前提是密钥登录已经正常工作。

比较稳妥的做法是：

1. 保持现有 SSH 会话不关闭。
2. 新开一个终端，确认密钥登录成功。
3. 检查其他需要登录的账号和自动化任务。
4. 确认有云控制台等应急访问途径后，再考虑关闭密码认证。

如果还没验证密钥能正常登录就关闭密码认证，可能会把自己锁在服务器外。

总结

SSH 密钥认证配置并不复杂，关键是确认三件事：

1. 客户端使用了正确的私钥。
2. 公钥已经添加到服务器目标用户的 authorized_keys。
3. 服务端允许公钥认证，且文件权限正确。

遇到连接问题时，先看 ssh -vvv 的客户端日志，再结合服务器的 journalctl 日志定位原因，比反复重新生成密钥更有效。