ssh connexion très lente


18

J'ai plusieurs systèmes distants, et l'un d'eux, un linode exécutant debian, est très lent à ssh - cela prend environ 20-25 secondes à chaque fois. Cela semble s'être produit relativement récemment. J'ai essayé de régler GSSAPIAuthenticationsur noou sur yescomme suggéré dans plusieurs réponses à des questions similaires, et cela ne fait aucune différence. Cela ne fait également aucune différence si je me connecte en utilisant le fqdn ou l'adresse IP. J'ai le même retard de sshing depuis ma boîte Linux locale ou mon Macintosh local. Je n'ai pas un tel retard de transfert du linode vers la boîte linux locale. J'ai un autre système distant utilisant la même version de Debian et je peux y accéder en 2 secondes. La seule différence entre le/etc/ssh/sshd_config fichiers sur les deux boîtes Debian est que le plus rapide n'autorise pas les mots de passe et spécifie également une liste de chiffrements autorisés.

Si je me connecte en utilisant ssh -vvv root@linode, le retard se produit à la partie marquée avec >>>>>>

debug2: key: /root/.ssh/id_ecdsa ((nil))
debug2: key: /root/.ssh/id_ed25519 ((nil))
debug3: send packet: type 5
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50

>>>>>>

debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /root/.ssh/id_rsa
debug3: send_pubkey_test

(Ceci n'est qu'un journal partiel - journal complet disponible sur demande)

Je ne trouve rien sur la connexion dans /var/log/auth.logou /var/log/syslogpendant le temps de retard - après je reçois juste

Jul 27 13:46:43 linode sshd[23049]: Accepted publickey for root from 199.241.27.237 port 51464 ssh2: RSA 89:08:ef:44:48:a4:84:b7:0a:de:14:65:1b:d9:86:f8
Jul 27 13:46:43 linode sshd[23049]: pam_unix(sshd:session): session opened for user root by (uid=0)
Jul 27 13:46:43 linode systemd-logind[3235]: New session 10361 of user root.

Réponses:


25

Si la création de la connexion est lente, mais que la vitesse est normale après sa création, vous aurez très probablement un problème que le serveur effectue une recherche DNS inversée pour le client et que, pour une raison quelconque, il échoue.

En général, lors du débogage, vous pouvez également essayer de vous connecter à partir de deux terminaux. Avec la première connexion, regardez le sshdjournal sur le serveur, pendant que vous essayez de vous connecter à partir du second. Cela vous donne plus d'informations sur ce que le serveur fait (ou attend).

Vous pouvez essayer de trouver la preuve de cela pour la cause de la recherche DNS inversée en définissant une, ou les deux, dans /etc/ssh/sshd_config:

UseDNS no
UsePAM no

et voyez si cela accélère la création de la connexion. Si c'est le cas, vous pouvez souvent laisser les choses de cette façon jusqu'à ce qu'elles soient résolues (si vous vous souciez de cela).

S'il s'agit d'un problème de recherche DNS inversée, cela dépend du serveur DNS sur lequel la machine à laquelle vous vous connectez utilise. Selon Wikipédia, toutes les adresses IP n'ont pas d'entrée inversée, car il ne s'agit pas d'une exigence réelle de normes. Mais il s'agit plus probablement d'un problème de configuration.


Mon nouveau FAI (fibre 1000Mbps à la maison!) N'a pas d'entrée rDNS pour mon IP. Donc, UseDNS nole problème a été résolu autant qu'il va l'être.
Paul Tomblin

2
L'ajout d'UserDNS n'a pas fonctionné pour moi.
Jose 'Vargas

J'ai essayé tout ça, pas de dés. Finalement, juste redémarré le client et tout allait bien.
medley56

Cela a été très utile ... a découvert que le DNS du serveur était mal configuré. Correction qui a corrigé les connexions ssh lentes.
TemporalWolf

L'ajout de UseDNS = no et le redémarrage de sshd ont fonctionné pour moi. CentOS 7.
pzy

-2

Sur les systèmes Debian / Ubuntu, l'astuce consiste à expulser le "avahi-daemon" du système et le problème a disparu.

apt-get -y purge avahi*

2
pas une bonne idée de mettre -ypour la commande de purge, l'utilisateur doit revoir l'action avant l'exécution.
Rabin
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.