Я использую сервер FreeIPA, настроенный с добавлением ключей SSH для пользователей. Я пытаюсь настроить серверы для аутентификации с использованием ключей ssh с сервера IPA, поэтому мне не нужно управлять таким количеством файлов authorized_keys.
Я могу подтвердить, что ключи добавлены и могут быть получены с помощью sss_ssh_authorizedkeys <user>
из командной строки, которая при запросе возвращает соответствующие ключи для каждого пользователя. Однако, когда sshd запускает команду, sss_ssh_authorizedkeys
выходит из строя с кодом ошибки 13.
Моя тестовая система - это мой IPA-сервер CentOS.
Я добавил следующий фрагмент в свой sshd_config
чтобы включить эту конфигурацию:
AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser nobody
Я также пробовал AuthorizedKeysCommandUser
как root, чтобы убедиться, что это не проблема с разрешениями.
Я погуглил свою ошибку, которая возвращает единственный результат из архива IRC, где конечным результатом (насколько я могу судить) было то, что решение было отправлено по электронной почте спрашивающему. Я подумал, что это может быть проблема с SELinux (который мучил меня в сценариях веб-сервера), но поиск "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 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]
Бинарный файл sss_ssh_authorizedkeys - это просто тупая оболочка, которая даже не регистрирует много данных, а просто взаимодействует с процессом sss_ssh sssd. Так что лучший способ узнать это - поместить debug_level в раздел [ssh] в sssd.conf и просмотреть журналы sssd ..