Case study of slow SSH logon to CentOS Server

Case study of slow SSH logon to CentOS Server

It takes dozens of seconds to log on to a Linux server over ssh. No such problem occurs on other servers. At ordinary times, the login operation was intolerable. Today, I finally cannot help wondering why. I searched and found a lot of information about slow ssh Login, so I learned to analyze and confirm the reasons for slow ssh login.

There are two common reasons for slow ssh Logon: DNS reverse resolution and ssh gssapi authentication.

1: ssh gssapi authentication Problems

GSSAPI (Generic Security Services Application Programming Interface) is a set of universal network Security system interfaces similar to Kerberos 5. This interface is encapsulated by different client server security mechanisms to eliminate different security interfaces and reduce programming difficulty. However, this interface may cause problems when the target machine does not have domain name resolution.

By default, GSSAPIAuthentication is activated on both the server and client. If there is a problem with the DNS service, the login process will not continue until the DNS query times out. This is why the SSH logon prompt takes a long time. Why does the DNS resolution service need to be used during ssh Login? This is why GSSAPI authentication is required.

Therefore, setting the GSSAPIAuthentication parameter to no in the configuration file/etc/ssh/sshd_config (server) or/etc/ssh/ssh_config (client) can solve the problem of slow ssh login.

2: DNS reverse resolution Problems

OpenSSH will verify the IP address when you log on. It uses reverse DNS to locate the host name based on the user's IP address, then uses DNS to locate the IP address, and finally matches whether the logon IP address is valid. If the IP address of the client does not have a domain name, or the DNS server is slow or inaccessible, it will take a long time to log on.

Problem Analysis:

First, you can add the "-v" parameter after the ssh command to output the debug information to locate the problem. The specific operation is ssh-vroot @ serverip

[root@localhost ~]# ssh -v root@192.168.xxx.xxx

OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: Applying options for *

debug1: Connecting to 192.168.xxx.xxx [192.168.xxx.xxx] port 22.

debug1: Connection established.

debug1: permanently_set_uid: 0/0

debug1: identity file /root/.ssh/identity type -1

debug1: identity file /root/.ssh/id_rsa type -1

debug1: identity file /root/.ssh/id_dsa type -1

debug1: loaded 3 keys

debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3

debug1: match: OpenSSH_4.3 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_4.3

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

The authenticity of host '192.168.xxx.xxx (192.168.xxx.xxx)' can't be established.

RSA key fingerprint is 04:08:57:22:7e:8d:dc:d3:8e:91:20:d0:ba:d9:ed:78.

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added '192.168.xxx.xxx' (RSA) to the list of known hosts.

debug1: ssh_rsa_verify: signature correct

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug1: SSH2_MSG_NEWKEYS received

debug1: SSH2_MSG_SERVICE_REQUEST sent

debug1: SSH2_MSG_SERVICE_ACCEPT received

debug1: Authentications that can continue: publickey,gssapi-with-mic,password

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

No credentials cache found

debug1: Next authentication method: publickey

debug1: Trying private key: /root/.ssh/identity

debug1: Trying private key: /root/.ssh/id_rsa

debug1: Trying private key: /root/.ssh/id_dsa

debug1: Next authentication method: password

root@192.168.xxx.xxx's password: 

debug1: Authentication succeeded (password).

debug1: channel 0: new [client-session]

debug1: Entering interactive session.

debug1: Sending environment.

debug1: Sending env LANG = en_US.UTF-8

Last login: Sun Sep 6 08:30:47 2015 from 192.168.7.222

[root@ceglnx01 ~]# 

The output information above shows Unspecified GSS failure, so I set the GSSAPIAuthentication parameter to no in/etc/ssh/sshd_config (server) or/etc/ssh/ssh_config (client, restart the sshd service and test whether ssh logon is slow.

[root@localhost ~]# service sshd status

openssh-daemon (pid 3594) is running...

[root@localhost ~]# service sshd restart

Stopping sshd: [ OK ]

Starting sshd: [ OK ]

The reason should be the DNS reverse resolution problem. There are several solutions to the DNS reverse resolution problem:

1: Add common ip addresses and hostnames to the/etc/hosts file on the server, and then check whether the program first queries the hosts file in/etc/nsswitch. conf.

2: modify or add UseDNS = no to the/etc/ssh/sshd_config file on the server. Restart the sshd service.

I set UseDNS to no on/etc/ssh/sshd_config, restart the sshd service, and then test the ssh connection speed. The connection was quickly established. It seems that DNS reverse resolution is the main problem.