Publié à l'origine sur Ask Ubuntu
Si vous avez exclu tout facteur "externe", l'ensemble d'étapes suivant permet généralement de le réduire. Ainsi, bien que cela ne réponde pas directement à votre question, cela peut aider à rechercher la cause de l'erreur.
Dépannage sshd
Ce que je trouve généralement très utile dans de tels cas, c'est de commencer sshd sans le laisser démoniser. Le problème dans mon cas était que ni syslog ni auth.log a montré quelque chose de significatif.
Quand je l'ai démarré depuis le terminal, j'ai :
# $(which sshd) -Ddp 10222
/etc/ssh/sshd_config line 8: address family must be specified before ListenAddress.
Bien mieux ! Ce message d'erreur m'a permis de voir ce qui ne va pas et de le corriger. Aucun des fichiers journaux ne contenait cette sortie.
NB : au moins sur Ubuntu le $(which sshd) est la meilleure méthode pour satisfaire sshd exigence d'un chemin absolu. Sinon, vous obtiendrez l'erreur suivante :sshd re-exec requires execution with an absolute path . Le -p 10222 fait sshd écouter sur ce port alternatif, en remplaçant le fichier de configuration - ceci afin qu'il n'entre pas en conflit avec l'exécution potentielle de sshd instances. Assurez-vous de choisir un port libre ici.
Enfin :connectez-vous au port alternatif (ssh -p 10222 [email protected] ).
Cette méthode m'a aidé à plusieurs reprises à trouver des problèmes, qu'il s'agisse de problèmes d'authentification ou d'autres types. Pour obtenir une sortie vraiment détaillée à stdout , utilisez $(which sshd) -Ddddp 10222 (notez le dd ajouté pour augmenter la verbosité). Pour plus de débogage, vérifiez man sshd .
Le principal avantage de cette méthode est qu'elle permet de vérifier le sshd configuration sans devoir redémarrer le sshd sur le port par défaut. Normalement cela ne devrait pas interférer avec les connexions SSH existantes, mais je l'ai vu. Cela permet donc de valider le fichier de configuration avant - potentiellement - de couper l'accès à un serveur distant (par exemple j'ai ça pour certains VPS et même pour des serveurs physiques où je dois payer un supplément pour avoir un accès hors bande à la machine).
Vous pouvez également avoir un hôte dont la mémoire est tellement fragmentée qu'il ne peut pas allouer à une page une mémoire contiguë pour bifurquer le processus d'hébergement d'une session SSH.
Dans ce cas, vous pouvez obtenir l'un ou l'autre des messages :
ssh_exchange_identification: read: Connection reset by peer
ou :
Connection closed by aaa.bbb.ccc.ddd
en fonction de la distance parcourue par l'hôte avant qu'il ne renonce.
Si la fragmentation de la mémoire en est la cause apparente, la solution consiste à accéder au serveur par d'autres moyens et à redémarrer certains des services pertinents. J'ai trouvé qu'Apache et MySQL étaient les coupables sur les VM puisque les VM n'ont pas de partition de swap. À défaut, redémarrez l'hôte.
Au cas où, car cela m'est arrivé. Assurez-vous que sshd est en cours d'exécution sur l'hôte !
C'est un échec stupide, mais c'est peut-être vraiment votre problème.