web-dev-qa-db-fra.com

La connexion ssh prend une éternité à démarrer, bloquée sur "pledge: network"

La connexion à l'un de mes serveurs à l'aide de ssh prend plus de 20 secondes à démarrer.

Ceci n'est pas lié aux conditions LAN ou WAN, car la connexion à elle-même prend la même chose (ssh localhost). Une fois la connexion établie, il est très rapide d'interagir avec le serveur.

L'utilisation de -vvv montre que la connexion est bloquée après avoir dit "pledge: network". À ce stade, l'authentification (ici à l'aide de la clé) est déjà effectuée, comme visible ici:

...
debug1: Authentication succeeded (publickey).
Authenticated to myserver.mydomain.com ([xx.xx.xx.xx]:22).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: network

(... coincé ici pendant 15 à 25 secondes ...)

debug1: client_input_global_request: rtype [email protected] want_reply 0
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
...

Le serveur est Ubuntu 16.04. Cela m'est déjà arrivé dans le passé avec un autre serveur (était Ubuntu 12.04), nerver a trouvé la solution et le problème a disparu au bout d'un moment ...

sshd_config est celui par défaut fourni par Ubuntu.

Jusqu'à présent, j'ai essayé:

  • en utilisant -o GSSAPIAuthentication = no dans la commande ssh
  • en utilisant un mot de passe au lieu d'une clé
  • en utilisant UsePrivilegeSeparation no au lieu de yes, dans sshd_config
ssh
50
M-Jack

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

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

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

Si oui, redémarrez simplement systemd-logind un 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 le service est appelé sur CentOS).

43
Strahinja Kustudic

trouvé la réponse:

changé UsePAM de oui à non 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, pas LDAP.

Eh bien, c'est plus un moyen 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 peut aider quelqu'un ...

19
M-Jack

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

(Les suggestions courantes d'utilisation de GSSAPIAuthentication=no et UseDNS=no, ou 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 l'option showfailed:

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 les fichiers étaient énormes en raison de nombreuses tentatives de connexion infructueuses. Les fichiers journaux btmp n'étaient pas non plus tournés.

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

J'ai également supprimé les énormes fichiers journaux btmp; dès que je l'ai fait, la connexion aux serveurs était à nouveau instantanée.

11
Richard Fearn

Pour moi, ce problème est dû à un gros fichier (des centaines de Mo) btmp. Ce fichier enregistre les tentatives de connexion. Lorsque des personnes essaient de forcer votre mot de passe par force brute, ce fichier peut être volumineux et entraîner des retards dans le "pledge: network" phase.

Essayez d'effacer le fichier journal

echo "" > /var/log/btmp

et voyez si cela aide.

2
Marek Nagy

Dans mon cas, la raison en était un rsyslogd écrasé. J'ai découvert cela parce qu'il n'y avait plus de messages de journal, par ex./var/log/syslog ou /var/log/mail.log

Donc service rsyslog restart a résolu le problème pour nous.

2
randomcontrol

Pour moi, la solution ajoutait

UseDNS no

à la /etc/ssh/sshd_config puis bien sûr service ssh restart (sur notre serveur Debian/Jessie). Rien d'autre...

avant:

ssh git@git.*****.de true  0.03s user 0.01s system 0% cpu 13.440 total
ssh git@git.*****.de true  0.03s user 0.01s system 0% cpu 20.990 total
ssh git@git.*****.de true  0.03s user 0.02s system 0% cpu 31.114 total
ssh git@git.*****.de true  0.03s user 0.01s system 0% cpu 25.898 total

après:

ssh git@git.*****.de true  0.03s user 0.02s system 5% cpu 0.832 total
ssh git@git.*****.de true  0.03s user 0.01s system 7% cpu 0.523 total
ssh git@git.*****.de true  0.03s user 0.01s system 7% cpu 0.574 total
1
tamasgal

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

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

Cela évite d'avoir à arrêter complètement PAM, ce qui paralyse la connexion avec les mots de passe.

1
Jonathan Gutow

J'ai remarqué la ligne suivante dans mes commentaires de débogage:

Control socket connect(/var/lib/jenkins/.ssh/USER@Host:22): Permission denied

Qui était un fichier appartenant à root:root pendant que je suis jenkins. La suppression de ce fichier a résolu mes problèmes.

0
Ambidex

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

Commenter les paramètres de motd m'a fait entrer.

0
Walter