Case study of slow Linux SSH Logon

Case study of slow Linux SSH Logon
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: gssapi authentication for ssh 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 side and the client side. 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 problem OpenSSH will verify the IP address when the user logs on. It uses reverse DNS to find the host name based on the user's IP address, and then uses DNS to find the IP address, finally, check 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: You can add the "-v" parameter after the ssh command to output the debug information to locate the problem. The specific operation is ssh-v root @ serverip

[root@localhost ~]# ssh -v root@192.168.xxx.xxxOpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008debug1: Reading configuration data /etc/ssh/ssh_configdebug1: Applying options for *debug1: Connecting to 192.168.xxx.xxx [192.168.xxx.xxx] port 22.debug1: Connection established.debug1: permanently_set_uid: 0/0debug1: identity file /root/.ssh/identity type -1debug1: identity file /root/.ssh/id_rsa type -1debug1: identity file /root/.ssh/id_dsa type -1debug1: loaded 3 keysdebug1: Remote protocol version 2.0, remote software version OpenSSH_4.3debug1: match: OpenSSH_4.3 pat OpenSSH*debug1: Enabling compatibility mode for protocol 2.0debug1: Local version string SSH-2.0-OpenSSH_4.3debug1: SSH2_MSG_KEXINIT sentdebug1: SSH2_MSG_KEXINIT receiveddebug1: kex: server->client aes128-ctr hmac-md5 nonedebug1: kex: client->server aes128-ctr hmac-md5 nonedebug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sentdebug1: expecting SSH2_MSG_KEX_DH_GEX_GROUPdebug1: SSH2_MSG_KEX_DH_GEX_INIT sentdebug1: expecting SSH2_MSG_KEX_DH_GEX_REPLYThe 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)? yesWarning: Permanently added '192.168.xxx.xxx' (RSA) to the list of known hosts.debug1: ssh_rsa_verify: signature correctdebug1: SSH2_MSG_NEWKEYS sentdebug1: expecting SSH2_MSG_NEWKEYSdebug1: SSH2_MSG_NEWKEYS receiveddebug1: SSH2_MSG_SERVICE_REQUEST sentdebug1: SSH2_MSG_SERVICE_ACCEPT receiveddebug1: Authentications that can continue: publickey,gssapi-with-mic,passworddebug1: Next authentication method: gssapi-with-micdebug1: Unspecified GSS failure.  Minor code may provide more informationNo credentials cache founddebug1: Unspecified GSS failure.  Minor code may provide more informationNo credentials cache founddebug1: Unspecified GSS failure.  Minor code may provide more informationNo credentials cache founddebug1: Next authentication method: publickeydebug1: Trying private key: /root/.ssh/identitydebug1: Trying private key: /root/.ssh/id_rsadebug1: Trying private key: /root/.ssh/id_dsadebug1: Next authentication method: passwordroot@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-8Last login: Sun Sep  6 08:30:47 2015 from 192.168.7.222[root@ceglnx01 ~]# clip_image001

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 statusopenssh-daemon (pid 3594) is running...[root@localhost ~]# service sshd restartStopping 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 the common ip address and hostname to the/etc/hosts file on the server, then in/etc/nsswitch. conf to check whether the program first queries the hosts file 2: modify or add UseDNS = no to the/etc/ssh/sshd_config file on the server. Then 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.