Аутентификация с открытым ключом завершается неудачей ТОЛЬКО, когда sshd является демоном
Я понятия не имею, как это происходит. Дистрибутив - Scientific Linux 6.1, и все настроено для аутентификации через открытый ключ. Тем не менее, когда sshd работает как демон (запуск службы sshd), он не принимает открытые ключи. (Чтобы получить этот фрагмент журнала, я изменил скрипт sshd, добавив опцию -ddd)
debug1: trying public key file /root/.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys2
debug1: restore_uid: 0/0
Failed publickey for root from xxx.xxx.xxx.xxx port xxxxx ssh2
debug3: mm_answer_keyallowed: key 0x7f266e1a8840 is not allowed
debug3: mm_request_send entering: type 22
debug3: mm_request_receive entering
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
debug3: Wrote 64 bytes for a total of 1853
debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 2 failures 1
Если sshd запущен в режиме отладки /usr/sbin/sshd -dddаутентификация работает как шарм:
debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
debug1: matching key found: file /root/.ssh/authorized_keys, line 1
Found matching RSA key: d7:3a:08:39:f7:28:dc:ea:f3:71:7c:23:92:02:02:d8
debug1: restore_uid: 0/0
debug3: mm_answer_keyallowed: key 0x7f85527ef230 is allowed
debug3: mm_request_send entering: type 22
debug3: mm_request_receive entering
debug3: Wrote 320 bytes for a total of 2109
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
Postponed publickey for root from xxx.xxx.xxx.xxx port xxxxx ssh2
debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 2 failures 0
Есть идеи?? Кто-нибудь видел что-нибудь подобное?
Заметки:
Права доступа к файлам были дважды проверены:
# ll -d .ssh
drwx------. 2 root root 4096 Oct 14 10:05 .ssh
# ll .ssh
total 16
-rw-------. 1 root root 786 Oct 14 09:35 authorized_keys
-rw-------. 1 root root 1675 Oct 13 08:24 id_rsa
-rw-r--r--. 1 root root 393 Oct 13 08:24 id_rsa.pub
-rw-r--r--. 1 root root 448 Oct 13 12:51 known_hosts
Меня спросили, может ли sshd получить доступ к файлам root в "режиме демона". Ближайший ответ, который я получаю на этот вопрос:
# netstat -ntap | grep 22
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 19847/sshd
# ps -ef | grep 19847
root 19847 1 0 09:58 ? 00:00:00 /usr/sbin/sshd
Если sshd работает от имени пользователя root, я не знаю, как получить доступ к его собственным файлам невозможно. Может ли SELinux быть причиной?
4 ответа
Да, скорее всего, причиной является SELinux. .ssh dir, вероятно, неправильно маркирован. смотреть на /var/log/audit/audit.log, Это должно быть помечено ssh_home_t, Проверить с ls -laZ, Бежать restorecon -r -vv /root/.ssh если нужно.
Я была такая же проблема. В моем случае не работали restorecon и chcon.
Я не хотел отключать selinux. После долгих исследований я наконец понял, что это потому, что мой домашний каталог был смонтирован откуда-то еще (NFS). Я нашел этот отчет об ошибке, который дал мне понять.
Я побежал:
> getsebool use_nfs_home_dirs
use_nfs_home_dirs --> off
чтобы убедиться, что use_nfs_home_dirs выключен, а затем:
sudo setsebool -P use_nfs_home_dirs 1
включить это.
Теперь я могу подключиться к моей машине по ssh, используя мой ключ и не вводя пароль. Переключение логического значения use_home_nfs_dirs было тем, что мне потребовалось.
Добавить к ответу Марка Вагнера, если вы используете собственный путь к домашнему каталогу (т.е. /home), вам нужно убедиться, что вы установили контекст безопасности SELinux. Для этого, если у вас есть домашние каталоги пользователей, например, в /myhome, бежать:
semanage fcontext -a -e /home /myhome
restorecon -vR /myhome
Похоже, вы используете разные ключи при тестировании соединений, 0x7f266e1a8840 против 0x7f85527ef230. Попробуйте подключиться с помощью 'ssh -v example.com' к sshd, работающему в качестве демона и в режиме отладки, и найдите ключи, используемые ssh, в строке "Предложение открытого ключа RSA".