0

I'm using a FreeIPA server configured with SSH keys added to users. I am trying to get servers to authenticate using the ssh keys from the IPA server, so I don't have to manage as many authorized_keys files.

I can confirm that the keys are added and retrievable using sss_ssh_authorizedkeys <user> from the command line, which returns the appropriate keys for each user when queried. However, when sshd runs the command, sss_ssh_authorizedkeys fails with error code 13.

My test system is my CentOS IPA server.

I added the following snippet to my sshd_config to enable this configuration:

AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser nobody

I have also tried the AuthorizedKeysCommandUser as root to make sure it wasn't a permissions problem.

I've googled my error, which returns a single result from an IRC archive where the end result (from what I can tell) was that the solution was emailed to the asker. I thought it might have been a problem with SELinux (which has plagued me in web server scenarios), but searching for "ssh", "sshd", or "authorizedkeys" yields nothing out of the ordinary that I could see. I'm also not super good at reading auth logs, so I'm not ruling out SELinux as the culprit here.

Here is a snippet from the log generated by sshd -ddd on the IPA box:

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 chacha20-poly1305@openssh.com <implicit> none [preauth]
debug1: kex: server->client chacha20-poly1305@openssh.com <implicit> none [preauth]
debug1: kex: curve25519-sha256@libssh.org need=64 dh_need=64 [preauth]
debug1: kex: curve25519-sha256@libssh.org 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 ryan service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug1: PAM: initializing for "ryan"
debug1: PAM: setting PAM_RHOST to "10.77.1.198"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: userauth-request for user ryan 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/ryan/.ssh/authorized_keys
debug1: Could not open authorized keys '/home/ryan/.ssh/authorized_keys': No such file or directory
debug1: restore_uid: 0/0
Failed publickey for ryan 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 ryan service ssh-connection method keyboard-interactive [preauth]
debug1: attempt 2 failures 1 [preauth]
debug1: keyboard-interactive devs  [preauth]
debug1: auth2_challenge: user=ryan devs= [preauth]
debug1: kbdint_alloc: devices 'pam' [preauth]
debug1: auth2_challenge_start: trying authentication method 'pam' [preauth]
Postponed keyboard-interactive for ryan from 10.77.1.198 port 56579 ssh2 [preauth]
0

The sss_ssh_authorizedkeys binary is just a dumb wrapper which doesn't even log much and just talks to sssd's sss_ssh process. So the best way to find out is to put debug_level into the [ssh] section in sssd.conf and take a look into the sssd logs..

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.