Linux系统如何配置SSH免密登录 秘钥生成与上传

配置SSH免密登录是提升Linux服务器管理效率的标配操作，但过程中遇到的算法选择、密钥上传失败、配置后仍需密码等问题，常常让操作者感到困惑。今天，我们就来深入聊聊这些关键环节，帮你彻底打通SSH免密登录的任督二脉。

ssh-keygen 生成密钥对：算法与长度的选择

使用ssh-keygen生成密钥时，很多人会直接回车使用默认选项。但默认的rsa算法在OpenSSH 8.8及以上版本中，其签名方式（ssh-rsa）已被弃用。因此，对于新环境，更推荐使用ed25519算法。它优势明显：安全性高、运算速度快，并且密钥长度固定为256位，非常简洁。

生成命令很简单：

ssh-keygen -t ed25519 -C "your_email@example.com"

注意，这里不需要指定-b参数（密钥长度），因为ed25519的位数是固定的，指定了反而会报错。那么，什么时候才考虑用RSA呢？答案是：只有在需要兼容一些老旧系统（例如某些嵌入式设备或非常早期的SSH 6.x版本）时，才退而求其次，使用-t rsa -b 4096来生成一个4096位的RSA密钥。

当 ssh-copy-id 失灵：手动上传公钥的可靠方法

ssh-copy-id这个命令确实方便，它自动将公钥追加到远程服务器的~/.ssh/authorized_keys文件中。但它并非万能，其成功运行依赖于目标服务器的shell环境支持POSIX标准，并且远程.ssh目录的权限设置必须合规。一旦遇到Permission denied (publickey)或Connection closed by remote host这类错误，手动上传就成了更可控的选择。

手动上传分两步走：

• 第一步，确保远程目录存在且权限正确。先通过SSH命令在远程服务器上创建.ssh目录并设置严格权限：

  ssh user@host 'mkdir -p ~/.ssh && chmod 700 ~/.ssh'

• 第二步，安全地追加公钥。使用管道将本地公钥内容传输到远程的authorized_keys文件末尾，并同时设置该文件的权限：

  cat ~/.ssh/id_ed25519.pub | ssh user@host 'cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys'

这里有个关键细节：务必确保远程authorized_keys文件的权限是600。如果权限过宽，OpenSSH出于安全考虑会直接拒绝读取，导致免密登录失败。

免密登录仍要密码？三大关键排查点

密钥生成和上传都做完了，但执行ssh user@host还是提示输入密码？别急，问题大概率出在以下三个地方：

• 服务器端配置未启用公钥认证。检查远程服务器的/etc/ssh/sshd_config文件，确保PubkeyAuthentication这一项的值是yes，并且不是被注释掉的状态。修改后记得重启SSH服务：sudo systemctl restart sshd。
• 目录权限过宽。OpenSSH对安全性要求极高，不仅要求.ssh目录和authorized_keys文件权限严格，连用户家目录及其所有父目录的权限都不能太宽松（例如家目录权限为755就可能被拒绝）。可以使用namei -l ~命令来逐级检查当前用户家目录的路径权限。
• 本地SSH未使用正确的私钥。如果你生成的密钥不是默认名称（如id_ed25519或id_rsa），那么ssh命令可能找不到它。解决方法有两种：一是在连接时显式指定私钥路径：

  ssh -i ~/.ssh/mykey user@host

  二是在本地~/.ssh/config文件中为特定主机配置密钥：

  Host myserver
      HostName 192.168.1.100
      User deploy
      IdentityFile ~/.ssh/mykey

多密钥管理：让 ssh-agent 精准匹配

当本地存在多套密钥对（例如分别用于工作、个人项目或持续集成）时，每次连接都使用-i指定会很麻烦。虽然启动ssh-agent并添加密钥后，OpenSSH会尝试按配置顺序或默认名称匹配，但更可靠的方式是在~/.ssh/config中为每个主机明确指定密钥，并加上IdentitiesOnly yes指令。

Host work-server
    HostName srv.example.com
    User alice
    IdentityFile ~/.ssh/id_ed25519_work
    IdentitiesOnly yes

Host personal-server
    HostName home.lan
    User bob
    IdentityFile ~/.ssh/id_ed25519_personal
    IdentitiesOnly yes

这样一来，即使你的ssh-agent里缓存了五六把不同的密钥，在连接work-server时，SSH也只会尝试使用id_ed25519_work这一把，彻底避免了因密钥尝试顺序错乱而导致的认证失败问题。