Ssh prend beaucoup de temps à se connecter à certains hôtes

Essayez d'ajouter la ligne suivante à /etc/ssh/sshd_config sur le nœud 2 :

UseDNS no

Ensuite, redémarrez sshd :

/etc/init.d/ssh restart

Ou si ce qui précède n'existe pas :

/etc/init.d/sshd restart

Modifiez /etc/ssh/sshd_config sur le serveur et ajoutez (si ce n'est pas déjà fait) en bas UseDNS no puis redémarrez le démon SSH.

Cela empêchera vos machines de résoudre les DNS et accélérera le processus.

2. Prenez un coup d'œil ici: OpenSSH FAQ en particulier le chapitre 3.3. Il pointe également vers d'autres causes possibles de retard.

3. ou La méthode la plus appropriée pour connaître le problème est de se connecter en utilisant ssh en mode debug :

   # ssh -v 
   
   OpenSSH_5.8p1 Debian-1ubuntu3, OpenSSL 0.9.8o 01 Jun 2010
   debug1: Lecture des données de configuration /etc/ssh/ssh_config
   debug1: Application des options pour *
   debug1: Connexion à mysql [192.168.0.29] port 22.
   debug1: Connexion établie.
   debug1: permanently_set_uid: 0/0
   debug1: fichier d'identité /root/.ssh/id_rsa de type -1
   debug1: fichier d'identité /root/.ssh/id_rsa-cert de type -1
   debug1: fichier d'identité /root/.ssh/id_dsa de type -1
   debug1: fichier d'identité /root/.ssh/id_dsa-cert de type -1
   debug1: fichier d'identité /root/.ssh/id_ecdsa de type -1
   debug1: fichier d'identité /root/.ssh/id_ecdsa-cert de type -1
   debug1: Version du protocole à distance 2.0, version logicielle à distance OpenSSH_5.3
   debug1: correspondance : OpenSSH_5.3 pat OpenSSH*
   debug1: Activation du mode de compatibilité pour le protocole 2.0
   debug1: Chaîne de version locale SSH-2.0-OpenSSH_5.8p1 Debian-1ubuntu3
   debug1: SSH2_MSG_KEXINIT envoyé
   debug1: SSH2_MSG_KEXINIT reçu
   debug1: kex: serveur->client aes128-ctr hmac-md5 aucun
   debug1: kex: client->serveur aes128-ctr hmac-md5 aucun
   debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) envoyé
   debug1: en attente de SSH2_MSG_KEX_DH_GEX_GROUP
   debug1: SSH2_MSG_KEX_DH_GEX_INIT envoyé
   debug1: en attente de SSH2_MSG_KEX_DH_GEX_REPLY
   debug1: Clé d'hôte serveur : RSA 1a:2c:c4:62:cc:27:1b:76:6b:f7:b2:38:00:7b:3f:63
   debug1: L'hôte 'mysql' est connu et correspond à la clé hôte RSA.
   debug1: Clé trouvée dans /root/.ssh/known_hosts:5
   debug1: ssh_rsa_verify: signature correcte
   debug1: SSH2_MSG_NEWKEYS envoyé
   debug1: en attente de SSH2_MSG_NEWKEYS
   debug1: SSH2_MSG_NEWKEYS reçu
   debug1: Roaming non autorisé par le serveur
   debug1: SSH2_MSG_SERVICE_REQUEST envoyé
   debug1: SSH2_MSG_SERVICE_ACCEPT reçu
   debug1: Authentications qui peuvent continuer : publickey, gssapi-keyex, gssapi-with-mic, password
   ->> debug1: Prochaine méthode d'authentification : gssapi-keyex
   debug1: Aucun contexte d'échange de clés valide
   debug1: Prochaine méthode d'authentification : gssapi-with-mic
   debug1: Échec GSS non spécifié. Le code mineur peut fournir plus d'informations Le fichier du cache des identités '/tmp/krb5cc_0' n'a pas été trouvé

   La ligne marquée d'une flèche causait le retard dans mon cas. J'ai commenté la ligne suivante sur le serveur de destination et cela a résolu le problème dans mon cas

   #Options GSSAPI
   #Authentification GSSAPI no
   #Authentification GSSAPI yes
   #Nettoyage des informations d'identification GSSAPI yes
   #Nettoyage des informations d'identification GSSAPI yes
   #Vérification stricte de l'acceptateur GSSAPI yes
   #Échange de clés GSSAPI no

   redémarrez le démon SSH sur le serveur distant et essayez de vous reconnecter.. c'est bon!

4. Certaines versions de glibc (notamment glibc 2.1 livré avec Red Hat 6.1) peuvent prendre beaucoup de temps pour résoudre les adresses “IPv6 ou IPv4 à partir des noms de domaine. Cela peut être contourné en spécifiant l'option AddressFamily inet dans ssh_config.

5. Il peut y avoir un problème de recherche DNS, soit au niveau du client, soit du serveur. Vous pouvez utiliser la commande nslookup pour vérifier cela à la fois sur le client et le serveur en recherchant le nom et l'adresse IP de l'autre extrémité. De plus, sur le serveur, recherchez le nom retourné par la recherche du nom d'IP du client. Vous pouvez désactiver la plupart des recherches côté serveur en définissant UseDNS no dans sshd_config.

J'ai trouvé aussi cette réponse :

1. Spécifiez l'option pour désactiver l'authentification GSSAPI lors de l'utilisation de la commande SSH ou SCP, par exemple : ssh -o GSSAPIAuthentication=no appssupp@10.50.100.111

-OU-

2. Désactivez explicitement l'authentification GSSAPI dans le fichier de configuration du programme client SSH, c'est-à-dire modifiez le /etc/ssh/ssh_config et ajoutez dans cette configuration (si ce n'est pas déjà dans le fichier de configuration) : GSSAPIAuthentication no

-OU-

3. Comme le 2 mais dans votre configuration ssh privée
   Modifiez /home/VOTRENOMDUTILISATEUR/.ssh/config et ajoutez GSSAPIAuthentication no

\=== BUG ===

Lorsque j'essaie de me connecter à un serveur ssh (avec ssh -v) j'obtiens toujours (mon système est un Ubuntu 8.04) :

debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
No credentials cache found
debug1: Unspecified GSS failure. Minor code may provide more information
No credentials cache found
debug1: Unspecified GSS failure. Minor code may provide more information
debug1: Next authentication method: publickey

Le fait est que sur de nombreux serveurs, l'établissement de la connexion ssh est très lent à cause de ce problème.

https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/416264