很多人第一次在 FinalShell 里做密钥登录，体验都差不多：照着教程敲完命令，提示成功，第二天再连却弹出“认证失败”。问题往往不在软件，而在几个想当然的判断上。下面这些误区，几乎每个都能在实操中被验证一次。
误区一：以为生成了密钥就等于配置好了
ssh-keygen 只是在本地生成一对文件，公钥还得送到服务器上，并写进对应用户的 authorized_keys，密钥认证才真正成立。
- 生成时建议明确类型和备注：ssh-keygen -t ed25519 -C "办公笔记本"，老系统可用 -t rsa -b 4096
- 最省事的投递方式是在本地执行 ssh-copy-id -i ~/.ssh/id_ed25519.pub 用户名@服务器IP
- 没有 ssh-copy-id 的环境，手动把 id_ed25519.pub 的内容追加到服务器的 ~/.ssh/authorized_keys，一行一把钥匙，不要挤成一行
- 投递完先在命令行 ssh 用户名@服务器IP 验证一次，再去改 FinalShell 的设置，两边分开排查
误区二：公私钥搞反，或者把私钥传上服务器
公钥可以公开，私钥必须留在本地。常见的翻车是有人把 id_rsa 上传到服务器，或者反过来把 .pub 文件选进了 FinalShell 的私钥路径。
- FinalShell 里选择的是本地私钥文件（id_ed25519 或 id_rsa），不是 .pub
- 私钥一旦泄露，等于把门钥匙挂在门把手上，发现泄露要立刻从 authorized_keys 删掉对应公钥并重新生成
- 服务器上只需要公钥，~/.ssh 目录里不该出现任何私钥文件
误区三：忽略权限，配置全对也登不上
sshd 对权限很敏感，权限过宽会直接拒绝使用密钥。这类失败通常只在服务器的安全日志里留一行提示，客户端只看到“认证失败”。
- chmod 700 ~/.ssh
- chmod 600 ~/.ssh/authorized_keys
- 家目录本身不能是 777，chmod 700 /home/用户名 或 /root 更稳妥
- 改完权限可执行 restorecon -R -v ~/.ssh，在启用 SELinux 的系统上，否则仍可能被拦
误区四：密钥格式没对上，FinalShell 认不出
PuTTY 生成的 .ppk 和 OpenSSH 格式的私钥不是一回事，直接混用就会报错。
- FinalShell 一般使用 OpenSSH 私钥；手上只有 .ppk 的，用 PuTTYgen 的 Conversions 功能转成 OpenSSH 格式再导入
- 复制公钥内容时注意别被聊天工具或文档自动换行，中间多一个空格或换行都会让密钥失效
- 私钥设了口令（passphrase）的，FinalShell 连接时要填的是这个口令，不是服务器登录密码，两者别混
误区五：急着关掉密码登录，改完不测试
密钥还不可用就关闭密码认证，是把自己锁在门外最快的方式。
- 正确顺序是：密钥能正常登录 → 再编辑 /etc/ssh/sshd_config，设置 PasswordAuthentication no、PubkeyAuthentication yes
- 改完先跑 sshd -t 检查语法，再 systemctl reload sshd 重载服务
- 保留一个已经连上的会话不要关，另开窗口验证新配置，确认无误再退出旧会话
- 需要 root 密钥登录的，还要确认 PermitRootLogin 为 prohibit-password 或 yes
误区六：会话里还留着旧的认证方式
在 FinalShell 的连接管理器里改完私钥，却发现行为没变化，多半是会话没保存，或者同时勾选了密码认证，客户端先走了密码通道。
- 右键会话进入设置，认证方式选密钥，指定私钥文件路径，保存后重新打开会话
- 之前勾选过“保存密码”的，把保存的密码清掉，避免掩盖密钥配置的问题
- 同一台机器有多个会话时，确认改的是正在用的那一个
一份不容易出错的实操顺序
- 本地生成密钥对，记下私钥路径
- ssh-copy-id 把公钥送到目标用户
- 命令行验证密钥登录成功
- 检查 .ssh 与家目录权限
- FinalShell 会话改为密钥认证并测试
- 最后再关闭密码登录，保留回退手段
密钥登录本身并不复杂，麻烦的是每一步都“看起来成功了”。把验证动作放在改配置之前，多数坑其实不会踩到。