When I tried to use ssh to log in on another computer using ssh user@192.168.0.1.
I have to wait exactly 1 minute 20 seconds, 80 seconds, for being prompted input of password. I have accepted this long delay for months(quite patient?). I don’t have same problem when I log in to bluehost server. Also no problem from OS X.
Now, I finally know the cause. I didn’t add the remote host into /etc/hosts. In other words, client-side can’t resolve 192.168.0.1. Normally, I have such name servers in /etc/resolve.conf:
; generated by /sbin/dhclient-script nameserver 168.95.192.1 nameserver 168.95.1.1
Which are from dhcp server, and these two name servers belong to my ISP. When I commented them out, the delay didn’t exist anymore.
When I run ssh -v user@192.168.0.1 results
OpenSSH_4.5p1, OpenSSL 0.9.8b 04 May 2006 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to 192.168.0.1 [192.168.0.1] port 22. debug1: Connection established. debug1: identity file /home/user/.ssh/identity type -1 debug1: identity file /home/user/.ssh/id_rsa type -1 debug1: identity file /home/user/.ssh/id_dsa type -1 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.5 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc 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 debug1: Host '192.168.0.1' is known and matches the RSA host key. debug1: Found key in /home/user/.ssh/known_hosts:2 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 ** Hangs up for several ten seconds here ** debug1: Unspecified GSS failure. Minor code may provide more information No credentials cache found ** Hangs up for several ten seconds here ** debug1: Unspecified GSS failure. Minor code may provide more information No credentials cache found ** Hangs up for several ten seconds here ** debug1: Unspecified GSS failure. Minor code may provide more information No credentials cache found debug1: Next authentication method: publickey debug1: Trying private key: /home/user/.ssh/identity debug1: Trying private key: /home/user/.ssh/id_rsa debug1: Trying private key: /home/user/.ssh/id_dsa debug1: Next authentication method: password user@192.168.0.1's password:
As you can see, ssh choose authentication in this order: gssapi-with-mic, publickey then password. I searched for gssapi-with-mic, it is related to Kerberos. I know nothing about Kerberos, but I guess Kerberos needs domain name to authorize a client.
So I disable gssapi-with-mic authentication in /etc/ssh/sshd_config:
# GSSAPI options GSSAPIAuthentication no #GSSAPIAuthentication yes GSSAPICleanupCredentials no #GSSAPICleanupCredentials yes
It works immediately. Later I just added remote host into /etc/hosts, and bring gssapi-with-mic authentication back. That also works.
11 Comments
Glad to see this.
I was seeing the exact same issues and turned off the GSSAPI… stuff on both the client and the server side and it seems to mostly work fine now.
HOWEVER-> I still get the “No credentials cache found” on some earlier portion of the process. No idea why — wish the defaults would just work without error and constant tweaking–especially since the docs seem to walk you through using ssh-keygen with RSA keys.
Thanks very much for this posting. I was also experiencing this delay and adding the remote hosts to my hosts file fixed the problem.
Good job.
Thanks for the post, but I discover another way to avoid this problem in case you want to leave GSSAPI by default and deactivate it only for some servers. Or in case you don’t have root access to the above mentioned config files
On your file .ssh/config, you can choose the option GSSAPIAuthentication no
For instance, the entry to the server foo with ip 10.0.0.1 would look like this
Host foo
HostName 10.0.0.1
GSSAPIAuthentication no
RSAAuthentication yes
Protocol 2
User hobbes
ForwardX11 yes
I hope it helps,
cheers
Boriss
Thank you very much!
We also could resolve the problem with fixing the host file.
(We get the failure after changing the name server, but turn the nameserver to the old one back didn’t help!)
Thx Axel…
I do not mean to hijack this thread, since we are going in a different direction, we want to use GSSAPI for SSO, and are getting this same error when we run ssh with a -v or -vv after it at the prompt. We have Kerberos working (simply need to create account on the box once first, then it will use our directory server for password following that, it wont let a user who has never seen that box before go straight on, but this is minor enough for us to work-around that). Now that we have “single set of credentials” working, we would like to up the ante, and get SSO working. Any suggestions? Thanks all. Peace. Cheers. (let us know if you need an awesome VoIP or IP PBX)
Thanks so much for this information. It really helped me out since i never use GSSAPI.
My login times are now down in the 5-7 second range now.
I had similar issue and my problem was one of the nameservers was down. so I removed it from /etc/resolv.conf and boom it came back to regular speed.
Thanks.
Thanks for the info
Thank you! I had the same problem and this fixed it.
I found this post looking for a solution to what turned out to be the exact same issue. I don’t have access to my ssh server configuration because it is my web host, what I couldn’t understand at first was why I could connect on one machine and not on another even when I attempted to use the same key. It turns out my pre-built binary version of ssh-client was compiled with the flag for kerberos authentication. The easiest fix is to put `GSSAPIAuthentication no` at the top of my `~/.ssh/config` file. I later recompiled my ssh and didn’t have any issue with or without it any longer.
4 Trackbacks
[…] well. I found this which seemed like it was going to help, but alas, it did […]
[…] I found this article which changed a few other SSH settings and in the end edited the /etc/hosts file. Sherblam. That […]
[…] web until the password prompt is being shown on the command line. After googling a bit I found a post describing my problem which I would like to recommend to the public. Root cause seems to be a missing configuration of […]
[…] Here this topic might prove useful: click me […]