我正在使用配置了已添加给用户的 SSH 密钥的 FreeIPA 服务器。我尝试使用 IPA 服务器的 ssh 密钥让服务器进行身份验证，这样我就不必管理那么多 authorized_keys 文件。
我可以确认密钥已添加并可通过sss_ssh_authorizedkeys <user>命令行检索，查询时会返回每个用户的相应密钥。但是，当 sshd 运行该命令时，sss_ssh_authorizedkeys会失败并显示错误代码 13。
我的测试系统是我的 CentOS IPA 服务器。
我添加了以下代码片段来sshd_config启用此配置：
AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser nobody
我也尝试AuthorizedKeysCommandUser以 root 身份进行操作，以确保这不是权限问题。
我用 Google 搜索了我的错误，它返回了来自 IRC 存档的单个结果，最终结果（据我所知）是解决方案已通过电子邮件发送给提问者。我以为这可能是 SELinux 的问题（这在 Web 服务器场景中一直困扰着我），但搜索“ ssh”、“ sshd”或“ authorizedkeys”并没有发现任何异常。我也不太擅长阅读身份验证日志，所以我不排除 SELinux 是罪魁祸首。
sshd -ddd以下是IPA 框上生成的日志的片段：
Connection from 10.77.1.198 port 56579 on 10.77.1.20 port 22
debug1: Client protocol version 2.0; client software version OpenSSH_7.5
debug1: match: OpenSSH_7.5 pat OpenSSH* compat 0x04000000
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1
debug1: SELinux support enabled [preauth]
debug1: permanently_set_uid: 74/74 [preauth]
debug1: list_hostkey_types: ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug1: kex: client->server [email protected] <implicit> none [preauth]
debug1: kex: server->client [email protected] <implicit> none [preauth]
debug1: kex: [email protected] need=64 dh_need=64 [preauth]
debug1: kex: [email protected] need=64 dh_need=64 [preauth]
debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user [username] service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug1: PAM: initializing for "[username]"
debug1: PAM: setting PAM_RHOST to "10.77.1.198"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: userauth-request for user [username] service ssh-connection method publickey [preauth]
debug1: attempt 1 failures 0 [preauth]
debug1: test whether pkalg/pkblob are acceptable [preauth]
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
Found matching RSA key: 2a:be:8a:c9:4f:62:7a:66:99:70:c1:ca:02:17:ee:94
AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys exited on signal 13
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 1954400001/1954400001 (e=0/0)
debug1: trying public key file /home/[username]/.ssh/authorized_keys
debug1: Could not open authorized keys '/home/[username]/.ssh/authorized_keys': No such file or directory
debug1: restore_uid: 0/0
Failed publickey for [username] from 10.77.1.198 port 56579 ssh2: RSA 2a:be:8a:c9:4f:62:7a:66:99:70:c1:ca:02:17:ee:94
debug1: userauth-request for user [username] service ssh-connection method keyboard-interactive [preauth]
debug1: attempt 2 failures 1 [preauth]
debug1: keyboard-interactive devs [preauth]
debug1: auth2_challenge: user=[username] devs= [preauth]
debug1: kbdint_alloc: devices 'pam' [preauth]
debug1: auth2_challenge_start: trying authentication method 'pam' [preauth]
Postponed keyboard-interactive for [username] from 10.77.1.198 port 56579 ssh2 [preauth]
答案1
sss_ssh_authorizedkeys 二进制文件只是一个愚蠢的包装器，它甚至不会记录太多内容，只会与 sssd 的 sss_ssh 进程对话。因此，找出答案的最佳方法是将 debug_level 放入 sssd.conf 中的 [ssh] 部分，然后查看 sssd 日志。