web-dev-qa-db-fra.com

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

Je n'ai aucune idée de comment cela se produit. La distribution est Scientific Linux 6.1 et tout est configuré pour effectuer une 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 morceau de journal, j'ai changé le script sshd pour 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?? Quelqu'un a-t-il vu quelque chose comme ça?

Remarques:

Les autorisations de fichiers ont été revérifiées:

# 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 root en "mode démon". La réponse la plus proche que j'obtiens à 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 s'exécute en tant que root, je ne sais pas comment il n'est pas possible d'accéder à ses propres fichiers. SELinux pourrait-il en être la cause?

linuxsshauthenticationdaemonkeys
33
user666412

Oui, SELinux en est probablement la cause. Le .ssh dir est probablement mal étiqueté. Regarder /var/log/audit/audit.log. Il doit être étiqueté ssh_home_t. Vérifier avec ls -laZ. Courir restorecon -r -vv /root/.ssh si besoin est.

43
Mark Wagner

J'ai eu le même problème. Dans mon cas, restorecon et chcon n'ont pas fonctionné.

Je ne voulais pas désactiver selinux. Après de nombreuses recherches, j'ai finalement pensé que c'était parce que mon répertoire personnel était monté depuis un autre emplacement (NFS). J'ai trouvé ce rapport de bogue qui m'a renseigné.

L'Iran:

> getsebool use_nfs_home_dirs
use_nfs_home_dirs --> off

pour confirmer que use_nfs_home_dirs était désactivé, puis:

Sudo setsebool -P use_nfs_home_dirs 1

pour l'allumer.

Maintenant, je peux accéder à ma machine en utilisant ma clé et sans entrer de mot de passe. Basculer le booléen use_home_nfs_dirs a été ce qu'il m'a fallu.

3
Gerard

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 des répertoires personnels d’utilisateurs dans, par exemple, /myhome, courir:

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

Il semble que vous utilisiez des clés différentes lors du test des connexions, 0x7f266e1a8840 vs 0x7f85527ef230. Essayez de vous connecter en utilisant '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 "Offrir la clé publique RSA".

0
Johan Nilsson