☰

为什么该用户的 SSH 密钥身份验证失败？ （CENTOS 7）

tag-icon • tag-icon centos ssh
为什么该用户的 SSH 密钥身份验证失败？ （CENTOS 7）

我正在尝试调试新用户帐户无法通过命令使用 RSA 密钥身份验证成功 SSH 到 Centos 7 服务器的事实

ssh theuser@theserver

可以进行以下观察：

  • 用户帐户（theuser）存在且未被锁定
  • 用户的主文件夹包含一个 .ssh 目录（700 权限），其中包含一个authorized_keys 文件（600 权限）
  • authorized_keys 文件包含来自本地计算机的公钥的副本
  • 本地计算机的 ~/.ssh/config 文件指向用于该服务器的正确密钥文件
  • 一旦密钥认证失败，通过输入用户密码即可成功实现ssh
  • 可以使用不同的用户帐户通过公钥实现 ssh
  • 当密钥被用户拒绝时，/var/log/secure 文件不会记录任何内容

由于我和我的同事陷入困境，有人可以建议我应该采取哪些后续步骤来尝试找到这个问题的根源吗？

编辑：包括 ssh -vvv 输出

debug1: Host 'theserver' is known and matches the ECDSA host key.
debug1: Found key in /Users/ambulare/.ssh/known_hosts:20
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug2: key: /Users/ambulare/.ssh/server_isr_id_rsa_ambulare (0x7fc#obfuscated#), explicit
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/ambulare/.ssh/server_isr_id_rsa_ambulare
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password

答案1

感谢@DevilaN的建议，我已经解决了这个问题。

尝试 ssh-copy-id 返回错误“authorized_keys 上的权限被拒绝”。由于这是一个权限错误，我返回检查authorized_keys文件的所有权和权限，尽管我在此文件上设置了用户的所有权（如我原来的问题），显然我或我的同事自初始设置以来已经做了一些事情这导致所有权更改为“root”。

这是一个简单的所有权问题。

chown theuser:theuser authorized_keys

瞧，ssh 正在工作。

对于通过 Google 搜索找到此答案的任何人：似乎授权密钥文件的错误用户的所有权将导致 ssh 登录尝试默默失败，而不会在任何地方返回或记录权限错误 - 直到您执行 ssh-copy- ID。

相关内容