一次凌晨的交接，前同事在文档里只留了一句“服务器已改成密钥登录”。新同事打开 Finalshell，新建 SSH 连接，导入私钥，点连接却看到 no supported authentication methods available。密码登录已经关闭，现场又没有别的入口，只能先找云控制台 VNC 进去。事后复盘，问题不在工具，而在三个细节：私钥格式、认证方式选择、服务器端公钥权限。
先分清私钥、公钥和私钥口令
- 私钥留在本地电脑，公钥追加到服务器的 ~/.ssh/authorized_keys。
- 私钥口令用来保护私钥文件，不是服务器登录密码；Finalshell 导入私钥时会提示输入。
- OpenSSH 私钥通常以 BEGIN OPENSSH PRIVATE KEY 开头，PuTTY 的 .ppk 是另一种格式，导入前要确认工具支持。
- 把私钥内容贴到服务器上，是交接中最常见的错误；服务器只需要公钥。
Finalshell密钥登录教程：这次复盘的六步路径
- 第一步，在本地确认私钥文件可用，最好先用 ssh -i 私钥路径 用户@主机 测试，排除网络与账号问题。
- 第二步，登录服务器，把公钥追加进 ~/.ssh/authorized_keys，不要覆盖已有公钥，避免把其他同事锁在门外。
- 第三步，收紧权限：home 目录不能是 777，~/.ssh 设为 700，authorized_keys 设为 600，属主必须是目标用户。
- 第四步，回到 Finalshell 新建 SSH 连接，认证方式选“密钥”，导入私钥；如果有口令，填入口令而不是服务器密码。
- 第五步，保留一个已登录的密码会话或云控制台会话，再开新窗口测试密钥登录，成功后再动 sshd 配置。
- 第六步，确认密钥可登录后，再关闭密码认证；改完先执行 sshd -t 校验，再 reload 服务，别直接重启。
四个误判，让简单问题变复杂
- 误判一：以为“导入私钥”等于“启用密钥认证”，连接配置里仍停留在密码方式。
- 误判二：忽略私钥口令，反复输入服务器密码，日志里其实提示的是 publickey 失败。
- 误判三：只改 authorized_keys，没看 SELinux 上下文；CentOS 上可用 restorecon -R -v ~/.ssh 修复。
- 误判四：权限过宽被 sshd 拒绝，却把问题归到 Finalshell 版本或网络。
- 误判五：改完配置不校验，sshd 起不来，现有会话一断就失去入口。
云主机和旧系统要多看一步
云厂商控制台创建的密钥对，公钥通常已经注入实例；本地生成的密钥则要自己追加。Ubuntu 上服务名可能是 ssh，CentOS 上多是 sshd，reload 命令要按系统来。若服务器禁止 root 直接登录，密钥也要绑到普通用户，再用 sudo 提权。旧系统对密钥算法支持有限，遇到报错可先看 /var/log/secure 或 /var/log/auth.log，不要盲目换工具。
交接清单：让下一个人少走弯路
- 记录密钥用途、指纹、保管位置和对应主机，别只写“用密钥登录”。
- 生产、测试环境分开建密钥，离职交接时按主机轮换，不共用一把私钥。
- 关闭密码登录前，确认至少两个可用入口：密钥会话和云控制台。
- 在 Finalshell 里给连接分组命名，备注认证方式，减少下一任同事的试错。
- 定期查看登录日志，发现异常公钥或失败尝试及时处理。
这次交接最后花了四十分钟恢复，真正改配置只用了五分钟，其余时间都在确认“到底哪一步没对上”。Finalshell密钥登录教程看起来是工具操作，背后其实是密钥生命周期管理：本地私钥保管好，服务器公钥权限收好，改配置前留好退路。把这三件事写进交接文档，比留一句“已改密钥登录”有用得多。