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


33

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?


1
Le script d'initialisation sshd fait-il quelque chose d'intéressant? (Devrait être /etc/init.d/sshd?) Que vous ne faites pas sur la ligne de commande? Au lieu de 'service sshd start', essayez 'sh -x /etc/init.d/ssh start'.
PT

Réponses:


42

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.


1
Oui, SELinux en était la cause: type = AVC msg = audit (1318597097.413: 5447): avc: refusée {lecture} pour pid = 19849 comm = "sshd" name = "hoekko "dev = dm-0 ino = 262398 : system_r: sshd_t: s0-s0: c0.c1023 tcontext = unconfined_u: object_r: admin_home_t: s0 tclass = fichier Cela fonctionne après l'exécution de "restorecon -r -vv /root/.ssh". Merci beaucoup.
user666412

1
merci MERCI MERCI pour le correctif de la ligne de commande selinux que je cherche depuis longtemps à expliquer pourquoi j’ai pu utiliser ssh en tant que root sur mon serveur redhat enterprise 6.2 en utilisant l’authentification de clé ssh, mais je ne pouvais pas utiliser ssh en tant qu’utilisateur non root. sans avoir à entrer un mot de passe. "ssh -v" n'a rien indiqué d'inhabituel. J'avais vérifié et revérifié les protections de fichiers sur /home/example/.ssh. Ce n'est que lorsque j'ai exécuté "/ usr / sbin / sshd -d" et pour une raison qui fonctionnait normalement que je me suis rendu compte qu'il se passait autre chose, essayé une recherche google différente et a trouvé cela. Donc, les symptômes étaient je pourrais ssh as
Paul M

1
Je devais faire cela sur tout le système de fichiers, à savoir restorecon -r /YMMV.
Irfy

1
J'ai essayé ceci - mais ne fonctionne toujours pas. dans le journal d'audit j'ai type=AVC msg=audit(1434642809.455:94717): avc: denied { search } for pid=27032 comm="sshd" name="/" dev=dm-2 ino=2 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:file_t:s0 tclass=dir- je ne sais pas ce que cela signifie
Yehosef

1
La réponse était dans le name="/"- je devais exécuter le restorecon -r /comme suggéré par @Irfy.
Yehosef

3

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.


1

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

Si vous êtes sur CentOS, vous devrez exécuter ceci pour obtenir semanage:sudo yum install policycoreutils-python
sm4rk0

0

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".


Oui, il y avait id_rsa et id_dsa. La clé DSA est partie et je vais refaire le test.
user666412

La valeur mentionnée dans debug3: mm_answer_keyallowed: key 0xFFFFFFFFFFchangera chaque fois que le sshd reçoit une nouvelle connexion. Pour ce faire, recherchez un serveur sur lequel SSH fonctionne, lancez sshd LOGLEVEL pour déboguer3, redémarrez sshd, exécutez tail -f /var/log/secure |grep mm_answer_keyallowed-vous puis connectez-vous à quelques reprises, en attendant quelques secondes (ou minutes) entre chaque connexion. Vous verrez que la valeur change à chaque fois. Et en fait, cela ressemble à un compteur pour moi.
Stefan Lasiewski
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.