Note: Cela a commencé comme un tutoriel "Comment déboguer", mais a fini par être la solution qui m'a aidé sur un serveur Ubuntu 16.04 LTS.
TLDR: Exécutez landscape-sysinfo et vérifiez si cette commande met longtemps à se terminer ; c'est la sortie d'informations système lors d'une nouvelle connexion SSH. Notez que cette commande n'est pas disponible sur tous les systèmes, le package landscape-common l'installe. ("Mais attendez, il y a plus...")
Démarrer un deuxième serveur ssh sur un autre port sur la machine qui présente le problème, faites-le en mode debug, ce qui ne le fera pas bifurquer et affichera les messages de débogage :
sudo /usr/sbin/sshd -ddd -p 44321
connectez-vous à ce serveur depuis une autre machine en mode verbeux :
ssh -vvv -p 44321 nom_utilisateur@serveur
Mon client affiche les lignes suivantes juste avant de commencer à dormir :
debug1: Entering interactive session.
debug1: pledge: network
La recherche de ces informations n'est pas vraiment utile, mais les journaux du serveur sont meilleurs :
debug3: mm_send_keystate: Finished sending state [preauth]
debug1: monitor_read_log: child log fd closed
debug1: PAM: establishing credentials
debug3: PAM: opening session
---- Pauses here ----
debug3: PAM: sshpam_store_conv called with 1 messages
User child is on pid 28051
J'ai remarqué que lorsque je change UsePAM yes en UsePAM no, alors ce problème est résolu.
Non lié à UseDNS ou à tout autre réglage, seul UsePAM affecte ce problème sur mon système.
Je ne sais pas pourquoi, et je ne laisse pas non plus UsePAM à no, car je ne connais pas les effets secondaires, mais cela me permet de continuer à investiguer.
Donc ne considérez pas cela comme une réponse, mais comme un premier pas pour commencer à découvrir ce qui ne va pas.
J'ai donc continué à enquêter, et j'ai exécuté sshd avec strace (sudo strace /usr/sbin/sshd -ddd -p 44321). Cela a donné ce qui suit :
sendto(4, "<87>Nov 20 20:35:21 sshd[2234]: "..., 110, MSG_NOSIGNAL, NULL, 0) = 110
close(5) = 0
stat("/etc/update-motd.d", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
umask(022) = 02
rt_sigaction(SIGINT, {SIG_IGN, [], SA_RESTORER, 0x7f15dce784b0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN, [], SA_RESTORER, 0x7f15dce784b0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
clone(child_stack=0, flags=CLONE_PARENT_SETTID|SIGCHLD, parent_tidptr=0x7ffde6152d2c) = 2385
wait4(2385, # BLOCKS RIGHT HERE, BEFORE THE REST IS PRINTED OUT # [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 2385
La ligne /etc/update-motd.d m'a rendu suspicieux, apparemment le processus attend le résultat des choses qui se trouvent dans /etc/update-motd.d
J'ai donc fait un cd dans /etc/update-motd.d et j'ai exécuté un sudo chmod -x * afin d'empêcher PAM d'exécuter tous les fichiers qui génèrent ce Message Of the Day dynamique, qui inclut la charge système et s'il y a des packages à mettre à jour, et cela a résolu le problème.
Il s'agit d'un serveur basé sur un CPU N3150 "économe en énergie" qui a beaucoup de travail à faire 24/7, donc je pense que collecter toutes ces données motd était juste trop pour lui.
Je pourrais commencer à activer les scripts dans ce dossier de manière sélective, pour voir lesquels sont moins nocifs, mais appeler spécifiquement landscape-sysinfo est très lent, et 50-landscape-sysinfo appelle cette commande. Je pense que c'est celui qui cause le plus de retard.
Après avoir réactivé la plupart des fichiers, j'ai conclu que 50-landscape-sysinfo et 99-esm étaient la cause de mes problèmes. 50-landscape-sysinfo mettait environ 5 secondes pour s'exécuter et 99-esm environ 3 secondes. Tous les fichiers restants environ 2 secondes au total.
Ni 50-landscape-sysinfo ni 99-esm ne sont cruciaux. 50-landscape-sysinfo imprime des statistiques système intéressantes (et aussi si vous manquez d'espace !), et 99-esm imprime des messages liés à la Maintenance de Sécurité Étendue d'Ubuntu
Enfin, vous pouvez créer un script avec echo '/usr/bin/landscape-sysinfo' > info.sh && chmod +x info.sh et obtenir cette sortie à la demande.
