Pourquoi ma connexion SSH est-elle lente?


95

Je constate des retards dans les connexions SSH. Plus précisément, il y a deux endroits où je vois une plage de délais instantanée à plusieurs secondes.

  1. Entre l’émission de la commande ssh et l’obtention d’une invite de connexion et
  2. entre la saisie de la phrase secrète et la charge du shell

Maintenant, spécifiquement, je regarde les détails SSH seulement ici. Évidemment, la latence du réseau, la vitesse du matériel et des systèmes d'exploitation impliqués, des scripts de connexion complexes, etc. peuvent entraîner des retards. Pour le contexte, ssh utilise une multitude de distributions Linux et certains hôtes Solaris qui utilisent principalement Ubuntu, CentOS et MacOS X comme système client. Presque tout le temps, la configuration du serveur ssh est inchangée par rapport aux paramètres par défaut du système d'exploitation.

À quelles configurations de serveur ssh devrais-je m'intéresser? Existe-t-il des paramètres système / noyau pouvant être ajustés? Connexion astuces shell? Etc?


utilisez-vous des comptes locaux? - Parfois, je trouve l'authentification pam peut ajouter un délai à la connexion avec ssh
Sirex

Habituellement les comptes locaux. Parfois, NIS.
Peter Lyons

Réponses:


122

Essayez de régler UseDNSà nodans /etc/sshd_configou /etc/ssh/sshd_config.


7
+1 c'est la cause la plus fréquente de retard lorsque vous vous connectez à ssh
matthias krull

2
"Remarque Solaris 11: J'ai essayé le paramètre UseDNS no sur Solaris 11 et le démarrage du service a été corrompu. Ce n'est pas une réponse amicale du service. YMMV avec d'autres variantes * Nix, mais il semble que UseDNS no ne soit pas une option valide dans Solaris 11 . " - commentaire de Keith Hoffman
Sathyajith Bhat

3
J'étais sceptique lorsque je me connectais à l'aide de l'adresse IP (réseau local), mais cette solution a résolu mon problème. Dans l’intérêt de Google, bien que cela se soit produit juste après, le retard n’a rien à voir avec le message "key: /home/mylogin/.ssh/id_ecdsa ((nil))" (lors de l’exécution ssh -vvv).
Skippy le Grand Gourou

2
+1 pour le rendre explicite, le fichier /etc/ssh/sshd_config! J'ajoutais /etc/sshd_configet je ne voyais aucune différence !!
vyom

1
@SkippyleGrandGourou: Certaines versions de Solaris utilisaient un OpenSSH modifié, appelé SunSSH, qui présentait des incompatibilités gênantes. Solaris 11.3 rajoute OpenSSH et SunSSH sera finalement supprimé ...
Gert van den Berg

37

Quand j'ai couru ssh -vvvsur un serveur avec une performance similaire lente, j'ai vu un blocage ici:

debug1: Next authentication method: gssapi-with-mic

En modifiant /etc/ssh/ssh_configet en commentant cette méthode d'authentification, les performances de connexion sont redevenues normales. Voici ce que j'ai /etc/ssh/ssh_configsur le serveur:

GSSAPIAuthentication no

Vous pouvez définir ceci globalement sur le serveur, de sorte qu'il n'accepte pas que GSSAPI s'authentifie. Ajoutez simplement GSSAPIAuthentication noà /etc/ssh/sshd_configsur le serveur et redémarrez le service.


J'ai constaté que c'était le cas avec mes serveurs RHEL5 une fois les connexions Winbind / ad configurées.
Tchad

Cela fonctionne pour moi sur un serveur Ubuntu 14.04.
Penghe Geng

Pour CentOS 7, vous devez définir à la fois GSSAPIAuthentication noet UseDNS nodans le /etc/ssh/sshd_configfichier.
Sunry

19

Pour moi, le coupable était la résolution IPv6, le délai était écoulé. (Je suppose que le paramètre DNS est mauvais chez mon fournisseur d’hôte.) C’est ce que j’ai découvert, ce ssh -vqui a montré quelle étape était suspendue.

La solution consiste à sshavec l' -4option:

ssh -4 me@myserver.com


2
Je suppose que de plus en plus d’entre nous verrons cela à mesure que le temps passe et que les choses (mal et) s’adaptent lentement à IPV6. Merci!
Sage

1
... et cette réponse est particulièrement inutile sans le message de débogage qui confirme que c'est le problème.
EP

D'après mon expérience, il s'agit d'un problème très courant lorsque SSH écoute sur des interfaces dualstack et la première chose que je vérifie lorsque je peux me connecter, mais cela prend plus de temps que prévu.
Mogget

Y a-t-il une chance que nous puissions corriger IPv6 plutôt que de passer par défaut à IPv4?
msrd0

C'est probablement la raison pour laquelle la réponse non utilisée par UseDNS fonctionne. utiliser -vvv ne montre que la pause debug2: resolving "thing.net.au" port 22sans erreur, mais cela ne se produit pas avec -4, ce qui indique qu'il s'agit d'un problème DNS IPv6.
pmc

16

Avec systemd, la connexion peut se bloquer sur la communication dbus avec logind après certaines mises à niveau, vous devez alors redémarrer logind.

systemctl restart systemd-logind

Vu cela sur debian 8, arch linx et sur une liste de choix


1
Oh wow, maintenant c'était le coupable! Merci beaucoup!
Mahatmanich

Pareil pour moi. Il a fallu un certain temps pour éliminer d’abord tous les problèmes DNS et SSH possibles. Remarque: si le problème s’applique également à sudo lent, essayez d’abord.
Michael

Je viens de terminer certaines mises à niveau sur place de RHEL6 à RHEL7 et j'ai remarqué ce problème. Cette réponse a également résolu mon problème.
user53029

merci beaucoup, cela fonctionne comme un charme.
Bảo Nam

9

Vous pouvez toujours commencer sshavec l' -voption qui affiche ce qui est fait pour le moment.

$ ssh -v you@host

Avec les informations que vous avez données, je ne peux que suggérer certaines configurations côté client:

  • Puisque vous écrivez que vous entrez les mots de passe manuellement, je vous suggérerais d'utiliser l'authentification par clé publique si possible. Cela vous élimine comme un goulot d'étranglement.

  • Vous pouvez également désactiver X-forwarding avec -xet authentification -a(ceux-ci sont peut-être déjà désactivés par défaut). En particulier, la désactivation de X-forwarding peut vous apporter une grande amélioration en sshtermes de vitesse si votre client doit démarrer un serveur X pour la commande (par exemple sous OS X).

Tout le reste dépend vraiment du type de retard que vous rencontrez, où et quand.


Bon indice sur la verbosité, vous pouvez aussi l'augmenter en ayant plus de v. Jusqu'à 3 IIRC.
vtest

7

En ce qui concerne le point 2., voici une réponse qui ne nécessite pas de modifier le serveur ni d’avoir les privilèges root / administratif.

Vous devez éditer votre fichier "user ssh_config" qui est:

vi $HOME/.ssh/config

(Remarque: vous devrez créer le répertoire $ HOME / .ssh s'il n'existe pas)

Et ajouter:

Host *
  GSSAPIAuthentication no
  GSSAPIDelegateCredentials yes

Vous pouvez le faire par hôte si nécessaire :) exemple:

Host linux-srv
  HostName 192.158.1.1
  GSSAPIAuthentication no
  GSSAPIDelegateCredentials yes

Assurez-vous que l'adresse IP correspond à l'adresse IP de votre serveur. Un avantage intéressant est que ssh fournira maintenant la saisie semi-automatique pour ce serveur. Donc, vous pouvez taper ssh lin+ Tabet il devrait compléter automatiquement ssh linux-srv.


4

Vérifiez /etc/resolv.confsur le serveur que le serveur DNS, répertorié dans ce fichier, fonctionne correctement et supprimez tout DNS qui ne fonctionne pas.

Parfois, c'est très utile.


2

Outre les problèmes DNS déjà mentionnés, si vous êtes connecté à un serveur avec de nombreux montages NFS, il peut y avoir un délai entre mot de passe et invite, car la quotacommande vérifie votre utilisation / quota sur tous les systèmes de fichiers non montés avec noquota. Sur les systèmes Solaris, vous pouvez le voir par défaut /etc/profileet le ignorer en le faisant fonctionner touch $HOME/.hushlogin .


1

Travailler bien.

# uname -a
SunOS oi-san-01 5.11 oi_151a3 i86pc i386 i86pc Solaris
# ssh -V
Sun_SSH_1.5, SSH protocols 1.5/2.0, OpenSSL 0x009080ff
# echo "GSSAPIAuthentication no" >> /etc/ssh/sshd_config
# echo "LookupClientHostnames no" >> /etc/ssh/sshd_config
# svcadm restart ssh

UseDNS no ne fonctionne pas avec OpenIndiana !!!

Lisez "man sshd_config" pour toutes les options

"LookupClientHostnames no" si votre serveur ne peut pas résoudre


1

Si aucune des réponses ci-dessus ne fonctionne et que vous rencontrez des problèmes de recherche inversée DNS, vous pouvez également vérifier si nscd(démon cache de service de noms) est installé et en cours d'exécution.

Si tel est le problème, c’est que vous n’avez pas de cache DNS, et chaque fois que vous recherchez un nom d’hôte qui ne figure pas sur votre fichier hôte, vous envoyez la question à votre serveur de noms au lieu de chercher dans votre cache.

J'ai essayé toutes les options ci-dessus et le seul changement qui a fonctionné a été de commencer nscd.

Vous devez également vérifier l'ordre de résolution des requêtes DNS /etc/nsswitch.confafin d'utiliser d'abord le fichier hosts.


1

Ceci est probablement uniquement spécifique à l’OpenSSH Debian / Ubuntu, qui comprend le groupe user-group-modes.patch écrit par l’un des responsables de la maintenance du paquet Debian. Ce correctif permet aux fichiers ~ / .ssh de définir le bit d’inscription de groupe (g + w) s’il n’ya qu’un seul utilisateur avec le même gid que celui du fichier. La fonction secure_permissions () du patch effectue cette vérification. L'une des phases de la vérification consiste à parcourir chaque entrée de mot de passe à l'aide de getpwent () et à comparer le gid de l'entrée avec le gid du fichier.

Sur un système comportant de nombreuses entrées et / ou une authentification lente NIS / LDAP, cette vérification sera lente. nscd ne met pas en cache les appels getpwent (), donc chaque entrée de mot de passe sera lue sur le réseau si le serveur n’est pas local. Sur le système, j'ai trouvé cela, il a ajouté environ 4 secondes pour chaque invocation de ssh ou connexion au système.

Le correctif consiste à supprimer le bit en écriture sur tous les fichiers de ~ / .ssh en le faisant chmod g-w ~/.ssh/*.


1

J'ai constaté que le redémarrage de systemd-logind.service ne réglait le problème que pendant quelques heures. La modification de UsePAM de oui à non dans sshd_config a entraîné des connexions rapides, bien que motd ne soit plus affiché. Des commentaires sur des problèmes de sécurité?


J'avais déjà examiné CHAQUE autre suggestion, et c'est la seule chose qui ait résolu le problème sur mon serveur d'activation Samba4 ... MERCI!
Deven Phillips

AVERTISSEMENT: "UsePAM no" n'est pas pris en charge dans Red Hat Enterprise Linux et peut entraîner plusieurs problèmes.
bbaassssiiee

1

Pour compléter toutes les réponses montrant que les résolutions DNS peuvent ralentir votre connexion SSH, il manque parfois une règle de pare-feu. Par exemple, si vous supprimez tous les paquets INPUT par défaut

iptables -t filter -P INPUT DROP

alors vous devrez accepter INPUT pour le port ssh et la requête DNS

iptables -t filter -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A INPUT -p udp --dport 53 -j ACCEPT

1

ssh -vvv La connexion s’est très bien déroulée jusqu’à ce que le système tente de récupérer le terminal pendant au moins 20 secondes:

debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
... waiting ... waiting ... waiting

Après avoir fait un systemctl restart systemd-logind sur le serveur, j'ai eu une connexion instantanée à nouveau!

C'était sur debian8 ! Donc, le problème était ici!

Remarque: Bastien Durel a déjà donné une réponse à ce problème, mais les informations de débogage manquent. J'espère que cela est utile à quelqu'un.


J'ai eu le même problème avec "Entrer session interactive" accroché sur RHEL7 (CentOS 7) et résolu en commentant session [default=1] pam_lastlog.so nowtmp showfaileddans /etc/pam.d/postlogin. Apparemment, la mise à jour du fichier lastlog a été incroyablement lente sous OpenVZ VPS basé sur un conteneur.
Justin ᚅᚔᚈᚄᚒᚔ

1

J'ai récemment trouvé une autre cause de connexions ssh lentes.

Même si vous avez UseDNS noà /etc/sshd_config, sshd peut encore effectuer des recherches DNS inverses si /etc/hosts.denya une entrée comme:

nnn-nnn-nnn-nnn.rev.some.domain.com

Cela peut arriver si DenyHosts est installé sur votre système.

Ce serait formidable si quelqu'un savait comment faire en sorte que DenyHosts évite de mettre ce type d'entrée dans /etc/hosts.deny.

Voici un lien vers la FAQ DenyHosts pour savoir comment supprimer des entrées de /etc/hosts.deny- voir Comment puis-je supprimer une adresse IP bloquée par DenyHosts?


1

Nous pouvons constater que la méthode de résolution de noms préférée n'est pas le fichier hôte, puis DNS.

Par exemple, ce serait la configuration habituelle:

[root@LINUX1 ~]# cat /etc/nsswitch.conf|grep hosts
#hosts:     db files nisplus nis dns
hosts:      files dns myhostname

Tout d'abord, le fichier hosts est atteint (option: fichiers), puis DNS (option: dns). Cependant, nous pouvons constater qu'un autre système de résolution de noms a été ajouté. Il n'est pas opérationnel et nous ralentit lorsque nous essayons de faire la résolution inverse.

Si l'ordre de résolution de nom n'est pas correct, vous pouvez le modifier à l'adresse suivante: /etc/nsswitch.conf

Extrait de: http://www.sysadmit.com/2017/07/linux-ssh-login-lento.html


1

J'ai essayé toutes les réponses mais aucune d'entre elles n'a fonctionné. enfin je découvre mon problème:

Je lance d'abord sudo tail -f /var/log/auth.log pour que je puisse voir le journal de SSH puis dans une autre session ssh 172.16.111.166et remarqué d'attendre

/usr/bin/sss_ssh_knownhostsproxy -p 22 172.16.111.166

après avoir cherché, j'ai trouvé cette ligne dans / etc / ssd / ssh_config

ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h

Je l'ai commenté et le délai est passé


1

Note: Ceci a commencé comme un tutoriel "Comment déboguer", mais a fini par être la solution qui m'a aidé sur un serveur Ubuntu 16.04 LTS.

TLDR : Exécuter landscape-sysinfoet vérifier si cette commande prend beaucoup de temps pour se terminer; c'est l'impression des informations système sur une nouvelle connexion SSH. Notez que cette commande n'est pas disponible sur tous les systèmes, le landscape-commonpackage l'installe. ("Mais attendez, il y a plus ...")


Démarrez un deuxième serveur ssh sur un autre port de la machine qui a le problème, faites-le en mode débogage, ce qui ne le fera pas changer et affichera les messages de débogage:

sudo /usr/sbin/sshd -ddd -p 44321

connectez-vous à ce serveur à partir d'une autre machine en mode prolixe:

ssh -vvv -p 44321 username@server

Mon client affiche les lignes suivantes juste avant de commencer à dormir:

debug1: Entering interactive session.
debug1: pledge: network

Googler ce n'est pas vraiment utile, mais les journaux du serveur sont meilleurs:

debug3: mm_send_keystate: Finished sending state [preauth]
debug1: monitor_read_log: child log fd closed
debug1: PAM: establishing credentials
debug3: PAM: opening session
---- Pauses here ----
debug3: PAM: sshpam_store_conv called with 1 messages
User child is on pid 28051

J'ai remarqué que lorsque je change UsePAM yesd' UsePAM noalors ce problème est résolu.

Non lié à UseDNSou à tout autre paramètre, UsePAMaffecte uniquement ce problème sur mon système.

Je n'ai pas la moindre idée pourquoi, et je suis pas non plus laisser UsePAMà no, parce que je ne sais pas que les effets secondaires sont, mais cela me permet de continuer à enquêter.

Alors, s'il vous plaît, ne considérez pas cela comme une réponse, mais comme une première étape pour commencer à découvrir ce qui ne va pas.


J'ai donc continué à enquêter et j'ai couru sshdavec strace( sudo strace /usr/sbin/sshd -ddd -p 44321). Cela a donné ce qui suit:

sendto(4, "<87>Nov 20 20:35:21 sshd[2234]: "..., 110, MSG_NOSIGNAL, NULL, 0) = 110
close(5)                                = 0
stat("/etc/update-motd.d", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
umask(022)                              = 02
rt_sigaction(SIGINT, {SIG_IGN, [], SA_RESTORER, 0x7f15dce784b0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN, [], SA_RESTORER, 0x7f15dce784b0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
clone(child_stack=0, flags=CLONE_PARENT_SETTID|SIGCHLD, parent_tidptr=0x7ffde6152d2c) = 2385
wait4(2385, # BLOCKS RIGHT HERE, BEFORE THE REST IS PRINTED OUT # [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 2385

La ligne /etc/update-motd.dm'a rendu méfiant, apparemment le processus attend le résultat de la chose qui est dans/etc/update-motd.d

Donc , je cd« d en /etc/update-motd.det a couru un sudo chmod -x *pour inhiber PAM pour exécuter tous les fichiers qui génèrent cette dynamique Message Of The Day, qui comprend la charge du système et si les paquets doivent être mis à jour, et ce résolu la question.

Ceci est un serveur basé sur un processeur N3150 "économe en énergie" qui a beaucoup de travail à faire 24h / 24, donc je pense que la collecte de toutes ces données motd était trop pour elle.

Je peux commencer à activer les scripts de ce dossier de manière sélective, afin de voir ceux qui sont moins nocifs, mais appeler spécialement landscape-sysinfoest très lent et 50-landscape-sysinfoappelle cette commande. Je pense que c'est celui qui cause le plus gros retard.

Après la plupart des réactivation des fichiers que je suis venu à la conclusion que 50-landscape-sysinfoet 99-esmétaient la cause de mes ennuis. 50-landscape-sysinfoa pris environ 5 secondes pour exécuter et 99-esmenviron 3 secondes. Tous les fichiers restants environ 2 secondes au total.

Ni 50-landscape-sysinfoet 99-esmsont cruciaux. 50-landscape-sysinfoaffiche des statistiques système intéressantes (et aussi si vous manquez d'espace!) et 99-esmaffiche des messages relatifs àUbuntu Extended Security Maintenance

Enfin, vous pouvez créer un script avec echo '/usr/bin/landscape-sysinfo' > info.sh && chmod +x info.shet obtenir cette impression sur demande.


1

Ce fil fournit déjà un tas de solutions, mais le mien n’est pas donné ici =). Alors le voici. Mon problème (il a fallu environ 1 minute pour que SSH se connecte à mon Raspberry Pi), était dû à un fichier .bash_history corrompu. Étant donné que le fichier est lu lors de la connexion, cela entraînait un délai de connexion. Une fois le fichier supprimé, le temps de connexion est revenu à la normale, de manière instantanée.

J'espère que cela aidera d'autres personnes.


0

Pour moi, j'avais besoin de GSSAPI et je ne voulais pas désactiver les recherches DNS inversées. Cela ne semblait pas être une bonne idée, alors j’ai vérifié la page principale de resolv.conf. Il s'est avéré qu'un pare-feu entre moi et les serveurs sur lesquels je travaillais sous SSH interférait avec les requêtes DNS, car elles ne se présentaient pas sous la forme attendue par le pare-feu. En fin de compte, tout ce que j'avais à faire était d'ajouter cette ligne à resolv.conf sur les serveurs pour lesquels j'étais SSHing:

options single-request-reopenUn séjour sans faille


0

Remarquablement, une mise à jour du paquet de bind sur CentOS 7 a été nommée de manière erronée, indiquant maintenant dans le journal que /etc/named.conf avait un problème d’autorisations. Cela fonctionnait bien depuis des mois avec 0640. Maintenant, il veut 0644. Cela a du sens, car le démon nommé appartient à l'utilisateur 'nommé'.

Avec le nom choisi, tout était lent, des connexions ssh aux serveurs de pages du serveur Web local, en passant par les applications LAMP lentes, etc., probablement parce que chaque requête expirait sur le serveur local inactif avant de rechercher un DNS secondaire externe configuré.


0

Pour moi, il y avait un problème dans mon /etc/hostsfichier local . Nous sshavons donc essayé deux adresses IP différentes (une fausse), ce qui a pris une éternité.

L'utilisation a ssh -vfait le tour ici:

$ ssh -vvv remotesrv
OpenSSH_6.7p1 Debian-5, OpenSSL 1.0.1k 8 Jan 2015
debug1: Reading configuration data /home/mathieu/.ssh/config
debug1: /home/mathieu/.ssh/config line 60: Applying options for remotesrv
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to remotesrv [192.168.0.10] port 22.
debug1: connect to address 192.168.0.10 port 22: Connection timed out
debug1: Connecting to remotesrv [192.168.0.26] port 22.
debug1: Connection established.

Le /etc/hostsdu serveur?
Daniel F
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.