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
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.
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.
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-logindne résout le problème que pendant une courte période pour moi.0 votes
Ou si vous voyez
pam_systemd(sshd:session): Failed to create session: Connection timed outcomme indiqué dans une réponse, il pourrait s'agir github.com/systemd/systemd/issues/29250 votes
Je suis venu ici après avoir eu ce problème après une mise à jour, et la suggestion de @IvanKozik a résolu le problème - c'est-à-dire systemctl restart systemd-logind - donc merci pour cela.
0 votes
@EricRenouf Si le problème venait des consultations DNS, il se serait produit beaucoup plus tôt dans la connexion.