Chaque fois que j'utilise PuTTY pour me connecter en SSH à un système Linux distant pour l'administration, le processus de connexion à distance est très lent—après avoir saisi le nom d'utilisateur, je dois attendre environ 30 secondes avant que l'invite de mot de passe n'apparaisse. Lorsqu'on doit réellement traiter des problèmes, surtout lorsqu'une réponse rapide est nécessaire, cette situation est vraiment insupportable.
Mais plus tard, après l'avoir testé spécifiquement, j'ai découvert qu'il ne s'agit pas d'un problème courant sur tous les systèmes. Les machines concernées sont principalement des CentOS. Avec le même système Debian, le processus de connexion à distance est rapide comme l'éclair, sans aucune sensation d'hésitation ni de latence. Serait-ce un problème lié à CentOS ?
Par curiosité, j'ai examiné les différences entre les deux systèmes lors de l'utilisation de SSH
CentOS：
ssh -v ssh_test@192.168.128.137
Les informations affichées lors d'une connexion à distance en SSH sont les suivantes :
OpenSSH_6.0p1 Debian-4, OpenSSL 1.0.1e 11 Feb 2013 ...Some sensitive information... debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3 debug1: match: OpenSSH_5.3 pat OpenSSH_5* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY ...Some sensitive information... debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug1: Next authentication method: gssapi-keyex debug1: No valid Key exchange context debug1: Next authentication method: gssapi-with-mic debug1: Unspecified GSS failure. Minor code may provide more information Cannot determine realm for numeric host address debug1: Unspecified GSS failure. Minor code may provide more information Cannot determine realm for numeric host address debug1: Unspecified GSS failure. Minor code may provide more information debug1: Unspecified GSS failure. Minor code may provide more information Cannot determine realm for numeric host address debug1: Next authentication method: publickey debug1: Trying private key: /home/mitchellchu/.ssh/id_rsa debug1: Trying private key: /home/mitchellchu/.ssh/id_dsa debug1: Trying private key: /home/mitchellchu/.ssh/id_ecdsa debug1: Next authentication method: password
Et le résultat de l'exécution du même test de commande sur Debian est :
OpenSSH_6.0p1 Debian-4, OpenSSL 1.0.1e 11 Feb 2013 ...Some sensitive information... debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debian-4 debug1: match: OpenSSH_6.0p1 Debian-4 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY ...Some sensitive information... debug1: ssh_ecdsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Trying private key: /home/mitchellchu/.ssh/id_rsa debug1: Trying private key: /home/mitchellchu/.ssh/id_dsa debug1: Trying private key: /home/mitchellchu/.ssh/id_ecdsa debug1: Next authentication method: password
D'après ce qui précède, on peut voir que dans CentOS, le système utilise publickey, gssapi-keyex, gssapi-with-mic et password pour l'authentification (la ligne colorée ci-dessus, ligne 23), alors que Debian n'utilise que Publickey et password. Lors de la connexion à CentOS, un temps considérable est passé à la ligne 23. Si nous commençons à regarder vers le bas à partir de là, nous pouvons clairement voir les informations suivantes :
#下面使用的是GSSAPI-KEYEX来进行验证 debug1: Next authentication method: gssapi-keyex #但是报错：没有可用的Key来交换信息 debug1: No valid Key exchange context #系统接着又使用下一个验证方法：GSSAPI-WITH-MIC debug1: Next authentication method: gssapi-with-mic #但遗憾的是，GSSAPI-WITH-MIC方法也失败。 #原因：不能确定数字主机地址的域 debug1: Unspecified GSS failure. Minor code may provide more information Cannot determine realm for numeric host address debug1: Unspecified GSS failure. Minor code may provide more information Cannot determine realm for numeric host address debug1: Unspecified GSS failure. Minor code may provide more information debug1: Unspecified GSS failure. Minor code may provide more information Cannot determine realm for numeric host address # 在尝试几次后，SSH认证终于放弃了这种验证。进入下一个验证：Publickey debug1: Next authentication method: publickey
Existe-t-il d'autres méthodes que celle-ci ? Naturellement, oui. CentOS nous fournit en fait déjà une solution : désactiver l'authentification GSSAPI lors de l'utilisation de la connexion à distance SSH. Bien sûr, il y a un autre problème qu'il faut noter. Si UseDNS est activé sur votre machine, vous devez également le désactiver. Pour plus de détails, voir l'explication finale.
D'après l'erreur, on peut voir que cela devrait être lié au domaine de l'hôte — probablement il ne peut pas confirmer le domaine correspondant à l'IP, d'où ce problème. GSSAPI est principalement basé sur Kerberos, donc pour résoudre ce problème, le système devrait avoir Kerberos configuré. Pour ceux qui n'ont pas Kerberos, configurer Kerberos juste pour résoudre un problème de délai de connexion ne semble pas être une décision judicieuse — surtout dans un environnement de production ! Minimiser la configuration pour répondre aux besoins est la bonne approche.
Tout d'abord, présentons la méthode de gestion de GSSAPI
Il y a deux façons de désactiver l'authentification GSSAPI : côté client et côté serveur
1. Désactiver sur le client
C'est relativement simple et cela n'affecte qu'un seul utilisateur client. Cela peut être mis en œuvre avec la méthode suivante :
ssh -o GSSAPIAuthentication=no your-server-username@serverIP
Utiliser la méthode ci-dessus pour se connecter à distance permet de désactiver GSSAPIAuthentication.
Si vous trouvez cela fastidieux, vous pouvez directement configurer votre fichier client ssh /etc/ssh/ssh_config pour résoudre définitivement ce problème :
vi /etc/ssh/ssh_config ### 找到ssh_config文件里面的GSSAPIAuthentication yes这行 ### 修改为GSSAPIAuthentication no ### 保存ssh_config文件并退出
Cette modification affecte tous les utilisateurs de cette machine. Si vous ne voulez pas que l'impact soit aussi large et que vous souhaitez uniquement désactiver GSSAPIAuthentication pour un utilisateur spécifique, vous pouvez alors trouver le répertoire .ssh dans le répertoire personnel de cet utilisateur, y ajouter un fichier config, et ajouter la ligne ci-dessus au fichier. Si ce fichier n'existe pas, vous pouvez également le faire directement comme ceci :
cat >>~/.ssh/config<<EOF GSSAPIAuthentication no EOF
Utilisez cat pour exporter directement l'entrée vers le fichier. À ce stade, lorsque vous utilisez ssh pour vous connecter à l'hôte cible distant, l'authentification GSSAPI ne sera plus utilisée.
Les fichiers ci-dessus se trouvent côté client, pas côté serveur. Autrement dit, pour modifier ce fichier, votre client doit également être sous Linux.
Si vous utilisez un outil client comme PuTTY sous Windows, n'utilisez pas la méthode ci-dessus. Avec PuTTY, vous pouvez essayer de le configurer avant la connexion :
PuTTY Configuration -> Connection -> SSH -> Auth -> GSSAPI -> (décochez) Attempt GSSAPI authentication (SSH-2 only)
Si vous n'avez pas désactivé GSSAPIAuthentication de PuTTY, vous pouvez faire un clic droit sur la fenêtre de connexion (ou : Ctrl + clic droit) pour consulter le journal, et vous pouvez trouver des journaux où PuTTY tente automatiquement une connexion GSSAPI :
2014-05-18 23:46:54 Using SSPI from SECUR32.DLL 2014-05-18 23:46:54 Attempting GSSAPI authentication 2014-05-18 23:46:54 GSSAPI authentication request refused
Bon, ce qui précède liste essentiellement les méthodes pour désactiver GSSAPIAuthentication côté client.
Remarque : les méthodes ci-dessus sont relativement universelles.
2. Si vous avez déjà configuré Kerberos
Vous pouvez alors aussi essayer les solutions côté client suivantes pour résoudre ce problème :
Ajoutez le nom d'hôte de l'hôte distant au fichier hosts de votre machine locale (Linux : /etc/hosts, Windows : system drive:/Windows/System32/drivers/etc/hosts). Linux et Windows peuvent tous les deux ajouter la ligne suivante.
### 注意：下面这样的IP-Addr要替换成你的远程机器的IP地址，HostName，自然是主机名 IP-Addr HostName
Après l'avoir ajouté, enregistrez et quittez.
Si vous n'avez pas configuré Kerberos, configurer uniquement le fichier hosts ne résoudra toujours pas le problème. Lorsque vous utilisez ssh pour vous connecter, vous pouvez voir un journal d'erreurs similaire à ce qui suit :
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mi debug1: Next authentication method: gssapi-keyex debug1: No valid Key exchange context debug1: Next authentication method: gssapi-with-mic debug1: Unspecified GSS failure. Minor code may provide more information Credentials cache file '/tmp/krb5cc_0' not found debug1: Unspecified GSS failure. Minor code may provide more information Credentials cache file '/tmp/krb5cc_0' not found debug1: Unspecified GSS failure. Minor code may provide more information debug1: Unspecified GSS failure. Minor code may provide more information Credentials cache file '/tmp/krb5cc_0' not found debug1: Next authentication method: publickey
J'ai aussi fait cette erreur au début ; cela mérite attention.
3. Désactiver GSSAPIAuthentication côté serveur.
Allez directement dans /etc/ssh/sshd_config et changez GSSAPIAuthentication yes en no. Notez également que vous devrez peut-être aussi changer UseDNS en UseDNS no (cela mérite attention, car la valeur par défaut diffère selon le système ; ici CentOS 6 est utilisé comme exemple) :
sudo vi /etc/ssh/sshd_config ### 普通用户权限不够，需要root权限 ### 找到GSSAPIAuthentication yes，修改为 ### GSSAPIAuthentication no ### 注意，这里你也需要将UseDNS修改为no，CentOS默认是yes，即使这行已被注释，你也需要加上 ### UseDNS no ### 有看到人说UseDNS yes不需要修改为UseDNS no，Mitchell测试下来是需要的。 ### 保存文件，退出
Après l'avoir désactivé, nous devons redémarrer le service SSH pour garantir que le nouveau fichier de configuration est correctement appliqué :
service sshd restart
À ce moment-là, lorsque vous utilisez SSH pour vous connecter à cet hôte à nouveau, ne trouvez-vous pas cela rapide ?
Ouf~ Enfin terminé ce long article. Il est en effet quelque peu difficile de bricoler tout en produisant tout ce texte. Cependant, de cette façon, le problème a été plutôt bien résolu. J'espère que vous pourrez comprendre l'article. N'hésitez pas à en discuter.
Notes
1. GSSAPI : Generic Security Services Application Program Interface. GSSAPI lui-même est un ensemble d'API standardisées par l'IETF. Son implémentation la plus importante et aussi la plus célèbre est basée sur Kerberos. Généralement, lorsque l'on mentionne GSSAPI, cela implique l'implémentation Kerberos.
2. UseDNS : il s'agit d'une option de recherche DNS sur le serveur OpenSSH, et elle est activée par défaut. Lorsqu'elle est activée, chaque fois qu'un client tente de se connecter au serveur OpenSSH, le serveur effectue automatiquement une recherche DNS PTR inverse en fonction de l'IP du client (la résolution inverse d'IP aura des enregistrements), trouve le nom d'hôte correspondant à l'IP, puis effectue une requête DNS directe d'enregistrement A en fonction du nom d'hôte du client. Grâce à cette requête, il vérifie si l'IP correspond à l'IP du client qui se connecte. Mais la grande majorité de nos machines obtiennent des adresses IP dynamiquement, ce qui signifie que cette option est inutile dans cette situation—même pour les serveurs ordinaires à IP statique, tant qu'aucune résolution inverse d'IP n'est effectuée, elle est difficile à appliquer. Si vous vous trouvez dans ces conditions, il est recommandé de désactiver UseDNS pour accélérer l'authentification lors de la connexion à distance SSH.
Source : http://blog.useasp.net/archive/2014/05/19/solved-the-problem-of-ssh-client-such-as-putty-remote-login-linux-very-slowly.aspx