Перевірка автентичності відкритого ключа не працює ТІЛЬКИ, коли sshd - демон

Я не маю поняття, як це відбувається. Дистрибутив є Scientific Linux 6.1, і все налаштовано для аутентифікації за допомогою відкритого ключа. Однак, коли sshd працює як демон (сервіс sshd start), він не приймає відкриті ключі. (Щоб отримати цей фрагмент журналу, я змінив скрипт 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 бути причиною?

Так, SELinux, ймовірно, є причиною. .sshРеж ймовірно позначаються. Погляньте /var/log/audit/audit.log. Він повинен бути маркований ssh_home_t. Перевірте ls -laZ. Бігайте, restorecon -r -vv /root/.sshякщо потрібно.

У мене було те саме питання. У моєму випадку відновленняconcon і 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 на свою машину за допомогою свого ключа та без введення пароля. Для мене було потрібне перемикання boolean 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".