128 votes

Pourquoi mon SSH connexion est lente?

Je constate des retards dans les connexions SSH. Plus précisément, il y a 2 points où je vois un éventail de retards allant de l'instantané à plusieurs secondes.

  1. Entre l'émission de la commande ssh et l'obtention d'un invite de connexion et
  2. entre la saisie de la phrase secrète et le chargement de l'interpréteur de commandes

Maintenant, je me concentre spécifiquement sur les détails du ssh. Évidemment, la latence du réseau, la vitesse du matériel et les systèmes d'exploitation impliqués, des scripts de connexion complexes, etc peuvent causer des retards. Pour contextualiser, je me connecte en ssh à une multitude de distributions Linux et à certains hôtes Solaris en utilisant principalement Ubuntu, CentOS et MacOS X comme systèmes client. La configuration du serveur ssh est presque toujours inchangée par rapport aux paramètres par défaut de l'OS.

Quelles configurations de serveur ssh devrais-je envisager ? Y a-t-il des paramètres OS/noyau à ajuster ? Des astuces pour le shell de connexion ? Etc ?

159voto

Paul R Points 5306

Essayez de définir UseDNS sur no dans /etc/sshd_config ou /etc/ssh/sshd_config.

50voto

Joshua Points 601

Lorsque j'ai exécuté ssh -vvv sur un serveur avec des performances lentes similaires, j'ai vu un blocage ici :

debug1: Next authentication method: gssapi-with-mic

En éditant /etc/ssh/ssh_config et en commentant cette méthode d'authentification, j'ai retrouvé des performances de connexion normales. Voici ce que j'ai dans mon /etc/ssh/ssh_config sur le serveur :

GSSAPIAuthentication no

Vous pouvez définir ceci globalement sur le serveur, afin qu'il n'accepte pas GSSAPI pour s'authentifier. Ajoutez simplement GSSAPIAuthentication no à /etc/ssh/sshd_config sur le serveur et redémarrez le service.

25voto

debugme Points 611

Pour moi, le coupable était la résolution IPv6, elle prenait trop de temps. (Mauvais réglage DNS chez mon fournisseur d'hébergement, je suppose.) J'ai découvert cela en faisant ssh -v, ce qui a montré à quel moment ça bloquait.

La solution est de faire ssh avec l'option -4:

ssh -4 moi@monserveur.com

19voto

Bastien Durel Points 290

Avec systemd, la connexion peut rester bloquée sur la communication dbus avec logind après certaines mises à jour, puis vous devez redémarrer logind

systemctl restart systemd-logind

J'ai vu cela sur debian 8, arch linx, et sur une liste suse

9voto

Michael Medin Points 605

Vous pouvez toujours démarrer ssh avec l'option -v qui affiche ce qui est fait à l'instant.

$ ssh -v you@host

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

  • Comme vous écrivez que vous saisissez les mots de passe manuellement, je vous suggère d'utiliser l'authentification par clé publique si possible. Cela vous évite d'être un goulot d'étranglement en termes de vitesse.

  • Vous pourriez également désactiver le transfert X avec -x et le transfert d'authentification avec -a (ces options pourraient déjà être désactivées par défaut). Désactiver en particulier le transfert X peut vous apporter une nette amélioration de la vitesse si votre client doit démarrer un serveur X pour la commande ssh (par exemple sous OS X).

Tout le reste dépend vraiment des types de retards que vous rencontrez et de leur nature.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X