SSH 登录报 Permission denied，先查这几处再重装系统

用密钥登录云服务器时，终端只回一句 Permission denied，很多人第一反应是重装系统。其实大多数情况下问题出在认证链路的某一步，顺着下面几处查一遍，往往几分钟就能定位，不用走到重装那一步。

一、先定性：是密钥被拒，还是密码也被拒

Permission denied 本身只说明"这次认证没通过"，不说明原因。先分清两种情况：

• 只用密钥登录被拒，密码登录还能进：问题大概率在密钥这一侧。
• 密钥和密码都进不去：问题可能在服务端配置或账号状态上，优先走控制台兜底。

定性不清就换方法，容易把简单问题查复杂。

二、本地密钥先自查

在换服务器配置之前，先看本地这把钥匙对不对：

1. 确认用的是正确的私钥文件，文件名、路径有没有拿错。
2. 私钥文件权限是不是太开放。权限过松时，客户端会直接拒绝使用这把钥匙，表现为认证失败。
3. 私钥格式有没有损坏。比如文件被编辑器改过行尾、复制时缺了头尾行，都会导致钥匙本身不可用。
4. 如果是新生成的密钥对，确认公钥确实已经放到了服务器上，而不是只生成在本地。

本地钥匙没问题，再往服务器侧查。

三、确认公钥有没有正确放到服务器上

密钥登录要靠服务器端的公钥比对，常见卡点有：

• 公钥没有写进对应用户的家目录下的授权文件里。
• 授权文件里混进了多余空格、换行，或者公钥被截断。
• 公钥放到了 A 用户名下，登录时却用了 B 用户。
• 家目录或授权文件的权限过松，服务端出于安全考虑直接忽略这份授权。

查的时候按"用户对不对、文件在不在、内容全不全、权限合不合规"四步走，比逐行猜要快。

四、看服务端有没有关掉密钥或密码登录

有些服务器出于安全策略，会关掉密码登录、只允许密钥登录；也有些会限制密钥登录方式。遇到"密码也被拒绝"时，先确认：

• 服务端是否允许密码登录，是否只允许密钥登录。
• 登录用户名是否被允许远程登录，有没有被锁定或禁用。
• 认证失败次数过多后，账号或来源地址有没有被临时限制。

这些属于服务端策略问题，换钥匙、换客户端都解决不了，得先把策略确认清楚。

五、看日志定方向，不要凭感觉换配置

定位到最后一步，靠日志说话：

• 服务端的认证日志会记录每一次登录尝试被拒绝的原因类别，是钥匙不匹配、用户不存在，还是配置拒绝。
• 客户端加详细输出，也能看到认证走到哪一步断掉，是钥匙根本没被接受，还是接受后又被服务端拒绝。
• 有了日志里的具体原因，再回头改对应的那一处，改完只验证这一处，不要一次改好几处。

一次改多处、改完又记不清改了什么，是排查中最容易反复的地方。

六、实在进不去时的兜底顺序

如果上面几步都查过还是进不去，按这个顺序兜底：

1. 用云厂商控制台提供的网页终端或救援登录先进去，先恢复管理通道。
2. 在控制台里核对密钥对绑定、用户状态和登录策略。
3. 确认无误后再从本地重新试一次密钥登录，确认恢复。
4. 最后再考虑是不是要重置密码或重建密钥对，而不是一上来就重装系统。

结语

Permission denied 大多数时候不是系统坏了，而是认证链路里某一步没对上。按"本地钥匙、服务器公钥、登录策略、日志定性"这个顺序查，既省时间，也避免把能修的小问题拖成重装。养成每次只改一处、改完验证一次的习惯，下次再遇到类似报错，定位会快很多。