☰

当服务器中的用户未登录 ssh 时，会出现：权限被拒绝（公钥）

tag-icon • tag-icon ubuntu ssh public-key
当服务器中的用户未登录 ssh 时，会出现：权限被拒绝（公钥）

我正在使用公钥身份验证设置 ssh 服务器。为此，我使用了本教程：http://www.g-loaded.eu/2005/11/10/ssh-with-keys/

我能够通过 ssh 登录。但这只有在我让用户保持登录状态时才有效（这意味着我必须在服务器机器上输入我的用户名和密码并保持登录状态）。如果我在服务器上注销用户，当我尝试通过 ssh 登录时，它会显示：“权限被拒绝（公钥）”。

我的问题是...是否真的需要让用户保持登录状态才能使用带有公钥身份验证的 ssh？或者我做错了什么？

谢谢！

附加信息：使用

ssh [email protected] -v

我得到以下输出（当没有用户登录到服务器时）。

debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: Connecting to 10.0.1.200 [10.0.1.200] port 22.
debug1: Connection established.
debug1: identity file /Users/thecommodore/.ssh/id_rsa type -1
debug1: identity file /Users/thecommodore/.ssh/id_rsa-cert type -1
debug1: identity file /Users/thecommodore/.ssh/id_dsa type -1
debug1: identity file /Users/thecommodore/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: DSA 2e:ca:e6:66:d1:61:35:7c:98:bb:cb:1f:49:aa:24:81
debug1: Host '[10.0.1.200]:22' is known and matches the DSA host key.
debug1: Found key in /Users/thecommodore/.ssh/known_hosts:7
debug1: ssh_dss_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering DSA public key: /Users/thecommodore/.ssh/id_dsa
debug1: Authentications that can continue: publickey
debug1: Trying private key: /Users/thecommodore/.ssh/id_rsa
debug1: Trying private key: /Users/thecommodore/.ssh/id_dsa
debug1: key_parse_private_pem: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
debug1: read PEM private key done: type DSA
Identity added: /Users/thecommodore/.ssh/id_dsa (/Users/thecommodore/.ssh/id_dsa)
debug1: read PEM private key done: type DSA
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

答案1

这可能是主目录加密的结果。这会阻止 SSH 守护程序读取密钥文件，并导致基于密钥的登录失败。您基本上有两个选项可以缓解此问题：

  • 禁用主目录加密。参见此教程l （由OP提供）。
  • 配置 SSH 守护程序以从另一个未加密的位置读取密钥文件。

对于第二种选择，您可以/sshkeys/为每个用户创建一个带有子目录的目录。然后设置参数并将AuthorizedKeysFile文件放在适当的子目录中，并确保每个用户都具有读取/执行权限，并且用户特定目录的权限属于相应的用户并设置为权限/etc/ssh/sshd_config/sshkeys/%u/authorized_keys/sshkeys700

另一个更高级的选项是使用参数AuthorizedKeysCommand并为密钥编写查找脚本，例如从 LDAP 目录中查找。这也有助于解决 Thorsten 提出的 NFS4/Kerberos 问题。这需要您允许用户将密钥放入相关的 LDAP 字段，例如使用一些额外的帮助脚本。

答案2

从使用强身份验证（kerberized NFSv4、CIFS）的网络共享获取您的主页可能会导致同样的问题。PAM 将使用您的密码来挂载共享。没有密码 -> 没有主页 -> 没有授权密钥

相关内容