Every time I use PuTTY to SSH login to a remote Linux system for management, the remote login process is very slow—after entering the username, I have to wait about 30 seconds before the password prompt appears. When actually dealing with problems, especially when rapid response is needed, this situation is truly unbearable.
But later, after testing it specifically, I found that this is not a common problem in every system. The machines with the problem are mainly concentrated on CentOS. With the same Debian system, the remote connection process is as fast as flying, with no sense of hesitation or lag. Could this be a CentOS problem?
Out of curiosity, I looked at the differences between the two systems when using SSH
CentOS：
ssh -v ssh_test@192.168.128.137
The information displayed during SSH remote login is as follows:
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
And the result of running the same command test on Debian is:
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
From the above, it can be seen that in CentOS, the system uses publickey, gssapi-keyex, gssapi-with-mic, and password for authentication (the colored line above, line 23), while Debian uses only Publickey and password. When connecting to CentOS, a considerable amount of time is spent at line 23. If we start looking down from there, we can clearly see the following information:
#下面使用的是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
Are there other methods besides this one? Naturally, there are. CentOS actually provides us with a solution already—disable GSSAPI authentication when using SSH remote login. Of course, there is another issue that must be noted. If UseDNS is enabled on your machine, you need to disable it as well. For details, see the final explanation.
From the error, it can be seen that it should be related to the host domain—probably it cannot confirm the domain corresponding to the IP, hence this problem occurs. GSSAPI is mainly based on Kerberos, so to solve this problem, the system would need to have Kerberos configured. For those who do not have Kerberos, configuring Kerberos just to solve a login delay problem does not seem like a wise decision—especially in a production environment! Minimizing configuration to meet needs is the right approach.
First, let's present the method for handling GSSAPI
There are two ways to disable GSSAPI authentication: client-side and server-side
1. Disable on the client
It is relatively simple and only affects a single client user. It can be implemented with the following method:
ssh -o GSSAPIAuthentication=no your-server-username@serverIP
Using the above method to login remotely can achieve disabling GSSAPIAuthentication.
If you find it troublesome, you can directly configure your ssh client file /etc/ssh/ssh_config to permanently solve this problem:
vi /etc/ssh/ssh_config ### 找到ssh_config文件里面的GSSAPIAuthentication yes这行 ### 修改为GSSAPIAuthentication no ### 保存ssh_config文件并退出
This modification affects all users on this machine. If you do not want the impact to be so wide and only want to disable GSSAPIAuthentication for a specific user, then you can find the .ssh directory in that user's home directory, add a config file there, and add the above line to the file. If this file does not exist, you can also do it directly like this:
cat >>~/.ssh/config<<EOF GSSAPIAuthentication no EOF
Use cat to directly export the input to the file. At this point, when you use ssh to connect to the remote target host, GSSAPI authentication will no longer be used.
The above files are on the client side, not the server side. That is, to modify this file, your client must also be Linux.
If you are using a client tool like PuTTY under Windows, do not use the above method. With PuTTY, you can try to configure it before connecting:
PuTTY Configuration -> Connection -> SSH -> Auth -> GSSAPI -> (uncheck) Attempt GSSAPI authentication (SSH-2 only)
If you have not disabled PuTTY's GSSAPIAuthentication, you can right-click on the connection window (or: Ctrl + right-click) to view the log, and you can find logs where PuTTY automatically attempts GSSAPI connection:
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
Well, the above basically lists the methods for disabling GSSAPIAuthentication on the client side.
Note: The above methods are relatively universal.
2. If you have already configured Kerberos
Then you can also try the following client-side solutions to solve this problem:
Add the remote host's hostname to your local machine's hosts file (Linux is /etc/hosts, Windows is system drive:/Windows/System32/drivers/etc/hosts). Both Linux and Windows can add the following line.
### 注意：下面这样的IP-Addr要替换成你的远程机器的IP地址，HostName，自然是主机名 IP-Addr HostName
After adding it, save and exit.
If you have not configured Kerberos, configuring only the hosts file will still not solve the problem. When using ssh to login, you can see an error log similar to the following:
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
I also made this mistake at the beginning; it needs attention.
3. Disable GSSAPIAuthentication on the server side.
Go directly to /etc/ssh/sshd_config and change GSSAPIAuthentication yes to no. Also, please note that you may also need to change UseDNS to UseDNS no (this needs attention, as the default value differs by system; here CentOS 6 is used as an example):
sudo vi /etc/ssh/sshd_config ### 普通用户权限不够，需要root权限 ### 找到GSSAPIAuthentication yes，修改为 ### GSSAPIAuthentication no ### 注意，这里你也需要将UseDNS修改为no，CentOS默认是yes，即使这行已被注释，你也需要加上 ### UseDNS no ### 有看到人说UseDNS yes不需要修改为UseDNS no，Mitchell测试下来是需要的。 ### 保存文件，退出
After disabling it, we need to restart the SSH service to ensure the new configuration file is correctly applied:
service sshd restart
At this time, when you use SSH to login to this host again, doesn't it feel fast?
Phew~ Finally finished this long post. It is indeed somewhat difficult to fiddle around while producing all this text. However, this way the problem has been sorted out pretty well. I hope you can understand the article. Feel free to discuss.
Notes
1. GSSAPI: Generic Security Services Application Program Interface. GSSAPI itself is a set of APIs standardized by IETF. Its most important and also famous implementation is based on Kerberos. Generally, when mentioning GSSAPI, it implies the Kerberos implementation.
2. UseDNS: It is a DNS lookup option on the OpenSSH server, and it is enabled by default. When enabled, whenever a client attempts to connect to the OpenSSH server, the server automatically performs a DNS PTR reverse lookup based on the client's IP (IP reverse resolution will have records), finds the Hostname corresponding to the IP, and then performs a DNS forward A record query based on the client's Hostname. Through this query, it verifies whether the IP matches the connecting client's IP. But the vast majority of our machines obtain IP addresses dynamically, which means this option is useless for this situation—even for ordinary static IP servers, as long as no IP reverse resolution is done, it is hard to apply. If you fall into these conditions, it is recommended to disable UseDNS to speed up authentication during SSH remote login.
Source: http://blog.useasp.net/archive/2014/05/19/solved-the-problem-of-ssh-client-such-as-putty-remote-login-linux-very-slowly.aspx