la connexion ssh met une éternité à s'initier, bloquée à "pledge : network" (gage : réseau)

Il s'agit probablement d'un problème avec D-Bus y systemd . Si le dbus est redémarré pour une raison quelconque, vous devrez aussi redémarrer le service systemd-logind .

Vous pouvez vérifier si c'est le problème en ouvrant le journal du démon ssh (sur Ubuntu, ce devrait être /var/log/auth.log ) et vérifiez s'il comporte ces lignes :

sshd[2721]: pam_systemd(sshd:session): Failed to create session: Connection timed out

Si oui, il suffit de redémarrer systemd-logind service :

systemctl restart systemd-logind

J'ai eu ce même problème sur CentOS 7, car le messagebus a été redémarré (c'est ainsi que le D-Bus est appelé sur CentOS).

A trouvé la réponse :

changement de UsePAM de yes à no dans le fichier sshd_config

Après avoir redémarré le service ssh, la connexion est maintenant immédiate avec le serveur. Sur ce serveur, PAM est lié à ldap, c'est donc probablement la raison, même si ici je me connecte avec un utilisateur déclaré sur le serveur lui-même, et non un utilisateur LDAP.

C'est plutôt une façon de contourner le problème, pas vraiment une solution... J'ai d'autres serveurs configurés de la même manière qui n'ont pas ce problème.

J'espère que cela pourra aider quelqu'un...

Cela s'est produit sur deux de mes serveurs Fedora 25, et était dû à de nombreuses tentatives de connexion SSH ratées.

(Les suggestions communes d'utiliser GSSAPIAuthentication=no y UseDNS=no ou le redémarrage systemd-logind n'a fait aucune différence).

Sur ces serveurs, /etc/pam.d/postlogin contient :

session     optional      pam_lastlog.so silent noupdate showfailed

La page de manuel de pam_lastlog explique que le showfailed l'option sera :

Affiche le nombre de tentatives de connexion échouées et la date de la dernière tentative échouée de btmp.

Sur ces serveurs, le /var/log/btmp étaient énormes en raison de l'échec de nombreuses tentatives de connexion. Le site btmp les fichiers journaux n'ont pas été tournés non plus.

J'ai installé le logrotate pour s'assurer que les fichiers journaux seront tournés à l'avenir. (Sous Fedora, la configuration fournie avec le paquetage logrotate gère la rotation de /var/log/btmp .)

J'ai aussi supprimé l'énorme btmp Dès que j'ai fait cela, la connexion aux serveurs était à nouveau instantanée.

Sur Ubuntu 16+, chaque fois que j'ai vu ssh -v XXX@YYY décrochage à pledge: network il peut être réparé en suivant les instructions que j'ai trouvées ici Un guide complet pour remédier à la lenteur des connexions SSH . Plus précisément, un module PAM optionnel qui ne semble pas être nécessaire est à l'origine du retard.

Sur /etc/pam.d/common-session sur la machine pour laquelle vous constatez un ralentissement des connexions (c'est-à-dire le serveur). Commentez la ligne session optional pam_systemd.so . Cela devrait immédiatement régler le problème.

Cela évite d'avoir à fermer complètement PAM qui paralyse la connexion avec les mots de passe.

Le problème pour moi (Ubuntu 19.10) était que mon :

/etc/pam.d/sshd

# Print the message of the day upon successful login.
# This includes a dynamically generated part from /run/motd.dynamic
# and a static (admin-editable) part from /etc/motd.
session    optional     pam_motd.so  motd=/run/motd.dynamic
session    optional     pam_motd.so noupdate

En commentant les paramètres du motd, j'y suis entré directement.