Ssh – long delay when logging in with CentOS7

centos7ssh

I have a CentOS 7 system and when I login with putty or ssh there is a long delay before I get the password prompt. I ran ssh -v and I found that it gets up to this:

debug1: ssh_ecdsa_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

and then it sits there for 1-2 minutes and then this output blasts out:

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
No Kerberos credentials available
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available
debug1: Unspecified GSS failure.  Minor code may provide more information
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available
debug1: Next authentication method: publickey
debug1: Trying private key: /home/motor/.ssh/id_rsa
debug1: Trying private key: /home/motor/.ssh/id_dsa
debug1: Trying private key: /home/motor/.ssh/id_ecdsa
debug1: Trying private key: /home/motor/.ssh/id_ed25519
debug1: Next authentication method: password

And then the password prompt comes out. This happens no matter which user is logging in. It only happens on the 1 system. I have 5 others where it proceeds without the delay.

There are no disk or memory or any other errors in the logs.

What could be causing it to delay like this?

UPDATE:

I tried setting GSSAPIAuthentication to no and that did not solve the issue.

I ran ssh again, this time with -vvv. This output came out and then it hung:

debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/motor/.ssh/id_rsa ((nil)),
debug2: key: /home/motor/.ssh/id_dsa ((nil)),
debug2: key: /home/motor/.ssh/id_ecdsa ((nil)),
debug2: key: /home/motor/.ssh/id_ed25519 ((nil)),

After 1-2 minutes this came out:

debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/motor/.ssh/id_rsa
debug3: no such identity: /home/motor/.ssh/id_rsa: No such file or directory
debug1: Trying private key: /home/motor/.ssh/id_dsa
debug3: no such identity: /home/motor/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/motor/.ssh/id_ecdsa
debug3: no such identity: /home/motor/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /home/motor/.ssh/id_ed25519
debug3: no such identity: /home/motor/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password

And then the password prompt.

Best Answer

In your /etc/ssh/sshd_config on the remote server you should change the option GSSAPIAuthentication to no. Restart sshd and you should be good to go.

edit: GSSAPI (Generic Security Service Application Programming Interface) is essentially an API that utilises Kerberos libraries to provide strong network encrypton. Unless there is a particular reason why you need GSSAPI enabled this method should resolve the issue you are having.

edit2: For clarity, it may also be possible that the reverse DNS check is timing out (specifically checking the connecting hosts' PTR record) . SSH does this check as a matter of course because it acts as a security measure to validate the connecting host.

Saying that, the process does not add much in terms of real security because realistically there's a significant proportion of hosts that do not have a PTR anyway. There are three ways to fix this issue:

1). You can amend the sshd_config file to use the UseDNS no parameter. This will stop the reverse DNS lookup. It is safe to do.

2). Add a PTR record in the appropriate DNS system for the host that's slow in connecting.

3). Add a manual entry into the OS hosts file with the relevant entry.

Hope that helps!

Related Topic