Une autre option est une variante de l » @Jagadish réponse : au strace
démon ssh.
Il a l'avantage important de ne pas avoir besoin d'arrêter sshd, ce qui peut entraîner un verrouillage complet si quelque chose se passe mal.
Premièrement, nous trouvons le pid du processus sshd principal. Ici nous pouvons le voir en exécutant un fichier pstree -pa|less
.
|-sshd,633 -D <-- THIS IS WHAT WE WANT!
| `-sshd,21973
| `-sshd,21996
| `-bash,22000
| `-screen,638 -r
Après avoir su que le pid est de 633, on peut strace
le suivre, à la suite de ses enfants:
strace -p 633 -s 4096 -f -o sux
Le résultat sera que tout ce que ce sshd et ses processus enfants ont fait sera intégré dans le fichier nommé sux
dans le répertoire local.
Puis reproduisez le problème.
Il y aura une liste massive de journaux d'appels dans le noyau, ce qui est pour la plupart incompréhensible / non pertinent pour nous, mais pas partout. Dans mon cas, l’important était le suivant:
6834 sendto(4, "<38>Jan 15 18:49:21 sshd[6834]: User cica not allowed because account is locked\0", 84, MSG_NOSIGNAL, NULL, 0) = 84
Sshd a essayé de consigner le message. L' utilisateur cica n'est pas autorisé car le compte est verrouillé . Il ne pouvait pas le faire, car la journalisation n'est pas assez détaillée pour cela. Mais nous savons déjà que la clé publique a été rejetée car le compte était bloqué.
Ce n'est pas encore une solution - il faut maintenant google, ce qui signifie un "compte verrouillé" dans le cas de sshd. Ce sera probablement de la magie triviale /etc/passwd
, /etc/shadow
mais l’essentiel est fait: le problème n’est pas mystérieux, mais facile à mettre au point et à mettre au point.