24

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.

2 Answers 2

29

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!

4
  • 2
    This did not fix the problem. There still is the delay. I will update my original post with more info. Commented Nov 17, 2016 at 21:31
  • 10
    It may be the reverse DNS lookup taking its time; you could try to add UseDNS no in the sshd_config file and reload the service to see if that makes any difference. Commented Nov 17, 2016 at 22:07
  • I will not be able to try that until the week after next. I'll let you know how it goes. Thanks. Commented Nov 18, 2016 at 16:36
  • 4
    Yes, that was the issue. Using UseDNS no fixed it and removed the delay. Thanks. Commented Nov 29, 2016 at 16:27
8

This sounds like a DNS issue - during a log-in attempt, a reverse DNS lookup is performed to provide the remote hostname in the auth logs.

Check to ensure that the server does not have an unresponsive resolver in the /etc/resolv.conf file.

3
  • Yes, that was the issue. Fixing this removed the delay. Thanks! Commented Nov 29, 2016 at 16:26
  • Larry, I'm glad this solved the issue. Would you mind selecting this as the accepted answer? Thanks, and good luck in your future endeavours.
    – Admin
    Commented Nov 29, 2016 at 20:04
  • I selected the answer given by Brett Levene as he answered before you. Commented Dec 1, 2016 at 2:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .