L'authentification par clé publique échoue UNIQUEMENT lorsque sshd est un démon

Je ne sais pas comment cela se passe. La distribution est Scientific Linux 6.1 et tout est configuré pour effectuer l’authentification via une clé publique. Pourtant, lorsque sshd s’exécute en tant que démon (service sshd start), il n’accepte pas les clés publiques. (Pour obtenir ce journal, j'ai modifié le script sshd afin d'ajouter l'option -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

Si sshd est exécuté en mode débogage /usr/sbin/sshd -ddd, l'authentification fonctionne comme un charme:

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

Des idées?? Est-ce que quelqu'un a vu quelque chose comme ça?

Remarques:

Les autorisations de fichiers ont été vérifiées deux fois:

# 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

On m'a demandé si sshd pouvait accéder aux fichiers de root en "mode démon". La réponse la plus proche que je parviens à cette question est:

# 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

Si sshd fonctionne en tant que root, je ne sais pas comment il est impossible d'accéder à ses propres fichiers. SELinux pourrait-il être la cause?

Oui, SELinux est probablement la cause. Le .sshrépertoire est probablement mal étiqueté. Regarde /var/log/audit/audit.log. Il devrait être étiqueté ssh_home_t. Vérifiez avec ls -laZ. Courez restorecon -r -vv /root/.sshsi besoin est.

J'ai eu le même problème. Dans mon cas, restorecon et chcon ne fonctionnaient pas.

Je ne voulais pas désactiver selinux. Après de nombreuses recherches, j'ai finalement compris que c'était parce que mon répertoire personnel avait été monté ailleurs (NFS). J'ai trouvé ce rapport de bogue qui m'a indiqué .

Iran:

> getsebool use_nfs_home_dirs
use_nfs_home_dirs --> off

pour confirmer que use_nfs_home_dirs était éteint puis:

sudo setsebool -P use_nfs_home_dirs 1

pour l'allumer.

Maintenant, je peux ssh sur ma machine en utilisant ma clé et sans entrer de mot de passe. Basculer le booléen use_home_nfs_dirs était ce qu'il me fallait.

Pour ajouter à la réponse de Mark Wagner, si vous utilisez un chemin de répertoire personnel personnalisé (c'est-à-dire pas /home), vous devez vous assurer que vous avez défini le contexte de sécurité SELinux. Pour ce faire, si vous avez par exemple des répertoires personnels d’utilisateur /myhome, exécutez:

semanage fcontext -a -e /home /myhome
restorecon -vR /myhome

Il semblerait que vous utilisiez différentes clés pour tester les connexions, 0x7f266e1a8840 vs 0x7f85527ef230. Essayez de vous connecter à l'aide de 'ssh-v example.com' à sshd exécuté en tant que démon et en mode débogage et recherchez les clés utilisées par ssh autour de la chaîne "Offering RSA public key".