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

Question

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

Demandé el 28 de Juillet, 2016: Quand la question a-t-elle été
58392 affichage: Nombre de visites la question a
5 Réponses: Nombre de réponses aux questions
Résolu: Situation réelle de la question

La connexion à l'un de mes serveurs à l'aide de ssh prend plus de 20 secondes pour être initiée.

Ceci n'est pas lié aux conditions de LAN ou WAN, puisque la connexion à lui-même se fait de la même manière (ssh localhost). Une fois que la connexion est enfin établie, il est super rapide d'interagir avec le serveur.

L'utilisation de -vvv montre que la connexion est bloquée après avoir dit "pledge : network". A ce moment, l'authentification (ici en utilisant la clé) est déjà faite, 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 no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network

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

debug1: client_input_global_request: rtype hostkeys-00@openssh.com 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 (Ubuntu 12.04), j'ai trouvé la solution et le problème a disparu après un certain temps...

sshd_config est celui fourni par défaut par Ubuntu.

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

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

Demandé el 28 de Juillet, 2016 par M-Jack

1 votes

Pour moi, les connexions SSH lentes sont généralement dues à des problèmes de DNS, est-ce que cela pourrait être le cas ici ? Par exemple, le serveur peut être bloqué en essayant d'effectuer un reverse DNS pour l'IP du client et en attendant que cela se termine.

Commenté el 28 de Juillet, 2016 par Eric Renouf

1 votes

En fait non : par défaut UseDNS n'est pas défini dans sshd_config et la page de manuel indique que cette option est "no" par défaut.

Commenté el 28 de Juillet, 2016 par M-Jack

4 votes

Quelques recherches sur Google suggèrent que cela peut être causé par la mise à jour de systemd sans redémarrage. Et il y avait un Mise à jour de systemd pour xenial le 12 juillet . systemctl restart systemd-logind ne résout le problème que pendant une courte période pour moi.

Commenté el 15 de Août, 2016 par Andy

Afficher 3 autres commentaires

Answer 1

5 Réponses

Answer 2

5voto

Marek Nagy Points 71

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

Essayez d'effacer le fichier journal

echo "" > /var/log/btmp

et voir si ça aide.

Répondu el 15 de Juin, 2017 par Marek Nagy (71 Points )

4 votes

Cela nécessite beaucoup plus d'explications. Tout d'abord, pourquoi pensez-vous que c'est utile ?

Commenté el 15 de Juin, 2017 par Sven

0 votes

Conseil : il suffit de taper :> /var/log/btmp fait de même.

Commenté el 7 de Mars, 2019 par headsling

1 votes

Sven, quelques années après la réponse de Marek, ce problème est désormais répertorié comme un bogue PAM : github.com/linux-pam/linux-pam/issues/270. L'option "showedfail" activée par défaut par de nombreuses distributions Linux, affiche "NNNN failed logins since the last successful login" à chaque connexion. Mais pour calculer ce NNNN, il faut parcourir l'intégralité du fichier /var/log/btmp, qui ne cesse de croître et qui, après quelques années, peut devenir énorme et prendre plus d'une minute à traiter lors de chaque connexion ! C'est triste, mais c'est vrai. J'ai eu le même problème et la suppression de /var/log/btmp l'a résolu.

Commenté el 22 de Août, 2021 par Nadav Har'El

Answer 3

3voto

bvasiliev Points 421

Pour moi, le premier indice a été fourni par

UseDNS no

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

antes de :

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

Cela a révélé que ma configuration DNS était erronée (j'avais une erreur de frappe dans l'adresse DNS). Après avoir corrigé l'IP et restauré la configuration UseDNS yes tout a bien fonctionné.

Répondu el 30 de Octobre, 2018 par bvasiliev (421 Points )

1 votes

Non, ajout UseDNS no est une solution à un problème complètement différent.

Commenté el 30 de Octobre, 2018 par martin

1 votes

@kasperd Cela n'a pas d'importance. Dans mon cas, j'ai eu les mêmes symptômes (brièvement : bloqué après avoir dit "pledge : network") et c'est ce qui a finalement aidé, donc c'est une solution à au moins un problème très similaire et je suis sûr que cela aidera l'un ou l'autre à un moment ou à un autre.

Commenté el 30 de Octobre, 2018 par bvasiliev

0 votes

Même chose ici, deux blocages pendant la connexion, un après. sign_and_send_pubkey , un plus long après pledge: network . Ajouter seulement UseDNS no avec des service ssh restart a résolu le problème sur une ancienne installation Ubuntu 14.04.5 LTS ici.

Commenté el 26 de Mars, 2019 par Hound

Afficher 1 autres commentaires

Answer 4

2voto

Sascha Points 159

Dans mon cas, la raison était un plantage de rsyslogd. Je l'ai découvert parce qu'il n'y avait plus de messages dans /var/log/syslog ou /var/log/mail.log, par exemple.

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

Répondu el 29 de Juin, 2018 par Sascha (159 Points )

0 votes

Même cause sur un de nos serveurs fonctionnant sous CentOS 6.10. Le redémarrage de rsyslog a réglé le problème. Le problème, c'est qu'il n'était pas mort. Il fonctionnait, mais ne faisait apparemment rien d'utile.

Commenté el 24 de Octobre, 2018 par UtahJarhead

Answer 5

1voto

hongquan Points 1

Dans mon cas, c'est parce qu'il y a trop de journaux. Vous pouvez tester si vous êtes dans le cas, en lançant cette commande :

sudo journalctl --list-boots

S'il met du temps à donner des résultats, et s'il donne de nombreuses lignes de résultats, alors, vous êtes dans le coup.

Pour tronquer les journaux, procédez comme suit :

sudo journalctl --vacuum-time 2d

Il supprimera les journaux datant de plus de deux jours.

Répondu el 17 de Juillet, 2020 par hongquan (1 Points )

Answer 6

1voto

Rishabh Malviya Points 21

Dans mon cas, il s'agissait d'un problème de pare-feu après la mise à jour vers Debian 11.

Résolu en ajoutant :

iptables -t filter -A INPUT -i lo -j ACCEPT

Au début du pare-feu script.

Répondu el 16 de Août, 2021 par Rishabh Malviya (21 Points )

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

Réponses

Questions en vedette

Top Tags

SistemesEz.com

Powered by:

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

Réponses

Questions connexes

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

Powered by: