Pourquoi ma connexion SSH est-elle lente?

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?

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

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.

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 [email protected]

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

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.

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.

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.

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 .

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

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.

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/*.

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é?

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

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 [email protected]
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 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?

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

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é

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.

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.

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

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é.

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.