ssh, scp ou sftp vers un nœud qui n'apparaît pas dans le fichier DNS ou /etc/hosts est lent à établir une connexion initiale. Une fois la connexion établie, la vitesse est celle attendue. Il y a deux cas à considérer, voir ci-dessous. Notez que dans la plupart des environnements, ce problème ne se produira pas car les adresses IP seront dans /etc/hosts ou DNS.
Le temps est consacré à la résolution de l'adresse IP du nom d'hôte cible/source ou à la recherche du nom d'hôte pour l'adresse IP cible/source et/ou à l'authentification basée sur les mêmes données. Il existe deux symptômes verbeux différents lorsque nous utilisons -vvv avec ssh constituant deux cas différents.
Cas 1
# ssh -vvv 10.10.10.205 ... ... debug1: Next authentication method: gssapi-with-mic debug3: Trying to reverse map address 10.10.10.205. debug1: Unspecified GSS failure. Minor code may provide more information No credentials cache found
Dans les systèmes CentOS/RHEL, le démon SSH est configuré pour utiliser Generic Security Services Application Program Interface (GSSAPI) authentification par défaut. Le GSSAPI effectue par défaut une recherche (via DNS ou d'autres moyens basés sur /etc/resolv.conf) pour l'IP demandée. Notez que la recherche se produit même si vous utilisez des adresses IP. Cela est nécessaire pour une authentification sécurisée/fiable.
Si vous consultez la page de manuel de configuration SSH :
# man ssh_config
...
GSSAPIAuthentication
Specifies whether user authentication based on GSSAPI is allowed. The default is no
... Si l'adresse IP / hôte n'apparaît pas dans /etc/hosts ou dans la base de données DNS, la requête de recherche expire, car elle réessaie, finit par abandonner et continue d'ouvrir la connexion. Le temps est passé pendant la recherche (50 secondes ou plus), jusqu'à ce que l'invite de mot de passe s'affiche. Ce décrochage n'arrive qu'aux hôtes qui se trouvent sur le LAN local et non dans le fichier DNS ou /etc/hosts. Notez que la méthode d'authentification est GSSAPI.
Cas 2
# ssh -vvv 10.10.10.12 . . . debug1: Offering public key: /root/.ssh/id_dsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply --stalls for 8 seconds--
Ici, l'hôte distant essaie d'effectuer une recherche DNS sur l'adresse IP du nœud client. Il peut s'agir d'une toute nouvelle installation de machine physique ou virtuelle qui n'est pas mise à jour dans /etc/hosts ou DNS et donc se bloque jusqu'à ce que la requête DNS expire. Encore une fois, la recherche DNS / hôtes est effectuée (basée sur le /etc/resolv.conf sur le client / serveur).
La solution
La solution prise en charge et appropriée à ce problème consiste à réussir les recherches de nom d'hôte / IP. Pour ce faire, vous pouvez :
- Vérifiez votre configuration dans /etc/resolv.conf pour la résolution de noms et la configuration du serveur DNS.
- Si non défini, définissez le nouvel hôte/IP à inclure dans le serveur DNS
- S'il s'agit d'un problème ou s'il est indigne de faire des définitions DNS (très probablement l'affectation est temporaire - c'est-à-dire un système de test, une machine virtuelle temporaire, etc.), assurez-vous que la paire nom d'hôte/adresse IP est incluse dans la source et la cible fichier /etc/hosts des environnements (c'est bien plus pratique)
Solutions de contournement
Sans un DNS / hosts approprié (ou /etc/resolv.conf config d'ailleurs), les connexions SSH sont censées être initialement lentes. C'est ainsi que l'on s'attend à ce qu'il en soit dans OEL. Alternativement, la situation d'attente peut être contournée par certaines modifications de configuration.
Pour le cas 1 l'authentification GSSAPI aurait pu être désactivée. Bien que cela soit possible, cela est fortement déconseillé car l'utilisation de GSSAPI est l'une des fonctionnalités de sécurité fondamentales fournies par SSH. SSH permet non seulement de sécuriser le contenu de la communication, mais peut également s'assurer que cette cible est celle qui est prévue. C'est parce que GSSAPIAuthentication est défini sur oui dans OEL (bien que la page de manuel indique que c'est "Non" par défaut - mais c'est la valeur par défaut des packages ssh principaux - pas la distribution spécifique). Il est tout de même possible de le désactiver, si vous êtes parfaitement sûr d'être sur un réseau fermé et conscient de savoir ce que vous faites :
Configuration temporaire - juste pour voir si cela fonctionne sur la ligne de commande :
# ssh -o "GSSAPIAuthentication no" 10.10.10.205
L'invite de mot de passe devrait apparaître instantanément si le cas 1 est votre cas. Pour le configurer de manière permanente (malgré toute autre recommandation), vous pouvez modifier GSSAPIAuthentication sur no de l'une des manières suivantes sur le client :
1. Ajoutez la ligne ci-dessous au fichier de configuration ssh du répertoire personnel de l'utilisateur (~/.ssh/config ):
GSSAPIAuthentication no
2. Ajoutez-le au fichier de configuration SSH du système sur le client. c'est-à-dire - /etc/ssh/ssh_config et côté serveur. Modifiez le fichier de configuration côté serveur (c'est-à-dire le système auquel vous vous connectez, dans ce cas il s'agit de 10.10.10.205) - /etc/ssh/sshd_config et redémarrez sshd :
# service sshd restart
cela peut être fait alors qu'il existe déjà des connexions SSH établies.
Pour le cas 2, si vous ne pouvez pas/ne voulez pas modifier la configuration DNS ou les fichiers /etc/hosts (malgré toute autre recommandation), vous pouvez contourner la situation en désactivant les recherches DNS effectuées pour le protocole SSH. Vous pouvez le faire en définissant
UseDNS no
dans le fichier de configuration SSH du serveur – /etc/ssh/sshd_config
et redémarrez sshd sur le serveur
# service sshd restart
cela peut être fait pendant que les connexions sont actives.