ssh hostname与ssh [user@]hostname的差异及公钥权限问题排查

我来帮你拆解这两个SSH命令的核心差异，再结合你遇到的permission denied(publickey)问题给出针对性的排查思路：

一、ssh -v hostname 和 ssh -v user@hostname 的核心差异 #

1. 默认登录用户不同
   ssh hostname会自动用你当前本地终端的用户名去尝试登录远程主机——比如你本地现在是alice，就会以alice的身份请求连接远程hostname；而ssh user@hostname是强制指定用user这个账户登录远程，完全和你本地当前用户是谁没关系。

2. 公钥验证的目标对象不同
   两种命令都会加载你本地当前用户~/.ssh/下的默认密钥（id_rsa、id_ecdsa这些），但验证的是远程主机上对应账户的~/.ssh/authorized_keys：

   • 用ssh hostname时，验证的是远程主机上本地用户名@hostname的authorized_keys；
   • 用ssh user@hostname时，验证的是远程主机上user@hostname的authorized_keys。

二、针对你遇到的问题的排查与解决步骤 #

你提到已经尝试了调整权限、恢复SELinux上下文但没效果，而且ssh hostname的调试日志里有unable to get valid context的提示，结合这些信息，建议你补充以下操作：

1. 检查远程主机目标用户的SSH文件SELinux上下文
   你之前在本地执行了restorecon，但问题很可能出在远程主机上指定用户的~/.ssh/目录和文件：

   • 先通过其他方式登录远程主机（比如用成功的ssh hostname切换到目标用户），执行：

     ls -Z ~/.ssh/
     

   • 正常情况下，目录和authorized_keys的SELinux上下文应该是ssh_home_t，类似这样的输出：

     drwx------. user user unconfined_u:object_r:ssh_home_t:s0 .ssh
     -rw-------. user user unconfined_u:object_r:ssh_home_t:s0 authorized_keys
     

   • 如果上下文不对，在远程主机上执行这条命令修复：

     restorecon -Rv ~/.ssh/
     

2. 确认远程主机sshd配置没限制目标用户
   查看远程主机的/etc/ssh/sshd_config文件，确保：

   • 有PubkeyAuthentication yes（这个你应该已经满足，毕竟ssh hostname能成功）；
   • 没有AllowUsers或DenyUsers规则把目标用户排除在允许登录的列表外；
   • 目标用户的/etc/passwd条目正常，没有被锁定。

3. 查看远程主机的安全日志找具体原因
   当你执行ssh user@hostname失败后，立刻登录远程主机查看日志：

   • CentOS/RHEL系看/var/log/secure；
   • Debian/Ubuntu系看/var/log/auth.log。
     日志里会明确告诉你拒绝的原因——比如是不是sshd因为SELinux上下文问题读不了authorized_keys，或者你的本地公钥根本没加到目标用户的authorized_keys里，甚至可能是目标用户的家目录权限太松（比如设成777，sshd会直接拒绝公钥验证）。

4. 验证本地公钥和远程目标用户的authorized_keys匹配
   最后再确认一遍：你本地当前用户的公钥（比如~/.ssh/id_rsa.pub）确实已经正确添加到远程目标用户的~/.ssh/authorized_keys里，格式要对（一行一个公钥，没有多余的空格或换行）。

内容的提问来源于stack exchange，提问作者dalihao