Question Pourquoi ma connexion SSH est-elle lente?


Je constate des retards dans les connexions SSH. Plus précisément, il y a 2 points où je vois une plage de délais instantanés à des délais de 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. De toute évidence, la latence du réseau, la vitesse du matériel et des systèmes d'exploitation impliqués, les scripts de connexion complexes, etc. peuvent entraîner des retards. Pour le contexte, je me suis intéressé à une multitude de distributions Linux et à des hôtes Solaris utilisant principalement Ubuntu, CentOS et MacOS X comme systèmes clients. 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 OS / kernel pouvant être ajustés? Connectez-vous des astuces de shell? Etc?


84
2017-07-22 07:02


origine


utilisez-vous des comptes locaux? - parfois je trouve que l'authentification pam peut retarder la connexion avec ssh - Sirex
Généralement des comptes locaux. Parfois NIS. - Peter Lyons


Réponses:


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


107
2017-07-22 08:38



+1 qui est la cause la plus courante de retard lors de la connexion à ssh - matthias krull
"Remarque sur Solaris 11: j'ai essayé le paramètre UseDNS no sur Solaris 11 et il a corrompu le démarrage du service. Pas exactement une réponse amicale du service. YMMV avec d'autres variantes de * Nix, mais apparemment UseDNS non peut ne pas être valide dans Solaris 11 . " - commentaire par Keith Hoffman - Sathya♦
J'étais sceptique car je me connectais en utilisant l'adresse IP (réseau local domestique), mais cette solution a résolu mon problème. Pour Google, bien qu’il se produise juste après, le délai n’a rien à voir avec le message "key: /home/mylogin/.ssh/id_ecdsa ((nil))" ssh -vvv). - Skippy le Grand Gourou
+1 pour le rendre explicite, le fichier /etc/ssh/sshd_config ! J'ajoutais dans /etc/sshd_config et ne voyant aucune différence du tout !! - vyom
@ SkippyleGrandGourou: Certaines versions de Solaris utilisaient un OpenSSH modifié, appelé SunSSH, qui présentait des incompatibilités ennuyeuses. Solaris 11.3 ajoute OpenSSH et SunSSH sera éventuellement supprimé ... - Gert van den Berg


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

debug1: Next authentication method: gssapi-with-mic

En éditant /etc/ssh/ssh_config et commentant cette méthode d’authentification, j’ai récupéré les performances de connexion. Voici ce que j'ai dans mon /etc/ssh/ssh_config sur le serveur:

GSSAPIAuthentication no

Vous pouvez définir cela 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émarrer le service.


33
2017-09-22 17:42



J'ai trouvé que c'était le cas avec mes serveurs RHEL5 une fois les connexions winbind / ad configurées. - Chad
Travaillé pour moi merci +1. - racic
Cela fonctionne pour moi sur un serveur Ubuntu 14.04. - Penghe Geng
Pour CentOS 7, vous devez définir les deux GSSAPIAuthentication no et UseDNS no dans /etc/ssh/sshd_config fichier. - Sunry


Pour moi, le coupable était la résolution IPv6, elle était dépassée. (Je suppose que le mauvais paramétrage du DNS chez mon hébergeur). Je l'ai découvert en faisant ssh -v, qui montrait quelle étape était suspendue.

La solution est de ssh avec le -4 option:

ssh -4 me@myserver.com


12
2017-08-14 00:50



Je soupçonne que de plus en plus d'entre nous vont voir cela avec le temps et les choses (mal et) lentement accueillir IPV6. Merci! - sage
... et cette réponse est particulièrement inutile sans le message de débogage qui confirme que c'est le problème. - E.P.
D'après mon expérience, c'est un problème très courant lorsque SSH écoute sur des interfaces dualstack et que je vérifie d'abord quand je peux me connecter, mais cela prend plus de temps que prévu. - Mogget


Avec systemd, la connexion peut se bloquer sur la communication dbus avec Logind après quelques mises à niveau, puis vous devez redémarrer

systemctl restart systemd-logind

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


11
2018-05-21 09:41



Oh wow, maintenant c'était le coupable! Merci beaucoup! - mahatmanich
Pareil pour moi. J'ai mis du temps à écarter d'abord tous les problèmes possibles de DNS et de SSH. Remarque: Si le problème concerne également ralentir sudo, essayez d’abord cette opération. - Michael


Vous pouvez toujours commencer ssh avec le -v option qui affiche ce qui se fait actuellement.

$ 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 si possible l’authentification par clé publique. Cela vous élimine comme un goulot d'étranglement.

  • Vous pouvez également désactiver le transfert X avec -x et transfert d'authentification avec -a (ceux-ci peuvent déjà être désactivés par défaut). En particulier, la désactivation de X-forwarding peut vous apporter une amélioration rapide si votre client doit démarrer un serveur X pour le ssh commande (par exemple sous OS X).

Tout le reste dépend des retards que vous rencontrez où et quand.


9
2017-07-22 08:28



Bon conseil à propos de la verbosité, vous pouvez également l’augmenter en ayant plus de v. Jusqu'à 3 IIRC. - vtest


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

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

vi $HOME/.ssh/config

(Remarque: vous devez 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 désormais la saisie semi-automatique pour ce serveur. Donc, vous pouvez taper ssh lin+ Tab et il devrait se compléter automatiquement pour ssh linux-srv.


7
2018-06-29 07:41





Vérifier /etc/resolv.conf sur le serveur pour être sûr que le serveur DNS, répertorié dans ce fichier, fonctionne correctement et supprimez tout DNS non fonctionnel.

Parfois, c'est très utile.


4
2018-06-08 07:57





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


2
2017-07-22 14:24





Bien travailler

# 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 non ne fonctionne pas avec OpenIndiana !!!

Lire "man sshd_config" pour toutes les options

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


1
2018-04-25 13:37





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 (nom du service cache du démon) est installé et en cours d'exécution.

Si tel est le problème, c’est parce que vous n’avez pas de cache DNS, et chaque fois que vous interrogez un nom d’hôte qui n’est 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 fonctionnait était le démarrage nscd.

Vous devriez également vérifier l'ordre pour que la résolution de requête DNS soit /etc/nsswitch.conf utiliser d'abord le fichier hosts.


1
2018-05-02 23:01