兄弟，你这个情况大概率是公钥没有被正确添加到服务器的授权列表里，先别着急，咱们一步步捋清楚问题出在哪，以及怎么解决：

首先得纠正一个你可能搞错的点：你说把客户端的id_rsa_other密钥对scp到了服务器，但SSH密钥认证的逻辑不是这样的——正确的流程是：

客户端用自己的私钥（id_rsa_other）签名请求，服务器需要用客户端对应的公钥（id_rsa_other.pub）来验证身份，所以服务器需要把客户端的公钥添加到自己的~/.ssh/authorized_keys文件里，而不是直接复制客户端的密钥文件。

从你说ssh -vvv server看到已经在提供id_rsa_other但还是认证失败，基本可以确定是服务器端没把这个公钥加入授权列表，导致验证不通过，只能 fallback 到密码登录。

下面是具体的排查和解决步骤：

• 第一步：确认客户端公钥并同步到服务器
  先在客户端查看你的id_rsa_other.pub内容：

  cat ~/.ssh/id_rsa_other.pub
  

  复制输出的整行内容（开头是ssh-rsa的那一串）。

  然后用密码登录到服务器，先确保.ssh目录和authorized_keys的权限正确（权限不对会直接导致公钥认证失败）：

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

  接着把刚才复制的公钥内容追加到authorized_keys里：

  echo "你复制的公钥内容" >> ~/.ssh/authorized_keys
  

  嫌手动复制麻烦的话，也可以直接在客户端用这个命令一键完成：

  ssh-copy-id -i ~/.ssh/id_rsa_other <服务器用户名>@<服务器实际地址>
  

  这个命令会自动把指定的公钥添加到服务器的授权列表，还会帮你检查权限问题，非常省心。

• 第二步：检查客户端的~/.ssh/config配置
  确认你写的配置没有拼写错误，格式要正确：

  Host server
    IdentityFile ~/.ssh/id_rsa_other
    Hostname <实际服务器域名/IP>
    User <服务器上的用户名>
  

  可以用这个命令查看SSH实际加载的配置，确认IdentityFile确实指向了id_rsa_other：

  ssh -G server
  

• 第三步：额外排查（如果上面两步都没解决）
  检查服务器的sshd配置是否开启了公钥认证：
  打开/etc/ssh/sshd_config文件，确认PubkeyAuthentication的值是yes，如果是no就改成yes，然后重启sshd服务：

  # 基于systemd的系统（CentOS、Fedora等）
  sudo systemctl restart sshd
  # 基于upstart的系统（Ubuntu旧版本等）
  sudo service ssh restart
  

做完这些步骤之后，再试试ssh server，应该就能直接用密钥认证登录，不用输密码了。

备注：内容来源于stack exchange，提问作者Troy Daniels