ssh hangs without password prompt — works in root or other accounts

Question

I had ssh key based login working fine. Then, I changed the hostname on my computer, and the key based login stopped working. Seemed to make sense. the keys probably relied on my old hostname. So, I deleted all of my keys and all the files in ~/.ssh/ and regenerated them (and changed the authorized_keys on the servers I connect to)

Now, any time I try to ssh, it just hangs without the password prompt, no matter where I an trying to ssh to--even servers where I don't have key based login set up. There is nothing in .ssh/config.

Moreover, when I 'su -' to root, ssh works perfectly. no problems at all. This only happens on my user account.

Below is some debugging info from ssh

ssh -vv mylogin@myremoteserver.com
OpenSSH_5.2p1, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /Users/myname/.ssh/config
debug1: Reading configuration data /usr/etc/ssh_config
......
debug1: Host 'myremoteserver.com' is known and matches the RSA host key.
debug1: Found key in /Users/myname/.ssh/known_hosts:1
debug2: bits set: 512/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received

And then it just hangs here.....

Here is the dtruss (like strace but for OSX) output near the end where it hangs: sudo dtruss ssh -vv mylogin@myremoteserver.com

select(0x4, 0x508200, 0x0, 0x0, 0x0)    	 = 1 0
read(0x3, "$\222\351{L\363\261\25063sN\216\300@q7\203\276b\257\354\337\356\260!{\342\017\271=\222,\245\347t\006\225\257\333;\204\020]\242\005z#\0", 0x2000)  = 48 0
write(0x2, "debug2: service_accept: ssh-userauth\r\n\0", 0x26)  	 = 38 0
connect(0x4, 0xBFFFEEA2, 0x6A)  	 = 0 0
write(0x4, "\0", 0x4)   	 = 4 0
write(0x4, "\v5\004\0", 0x1)    	 = 1 0
read(0x4, "\0", 0x4)    	 = -1 Err#4

It seems to be trying ro read something and just hangs on this. If anyone has some suggestions or ideas, I would be very grateful!

Answer 1

Can I interest you in reverse DNS?

Essentially, the client is doing the reverse DNS on the server, or vice versa.

I propose a test:

Disable DNS lookups on the server by editing /etc/ssh/sshd_config and making sure "UseDNS" is set to "no".

Run "service ssh reload" (or whatever causes your ssh daemon to reread the config), then try again.

Incidentially, it doesn't happeen to finally prompt you after a long period of time, does it?

Another thing you might check is looking at the contents of /etc/hosts on the server to make sure that nothing is wrong there.

Answer 2

If it's because of a saved key, you should be able to delete it from your ~/.ssh directory in the known_hosts file. Just find the entry and delete it then it should prompt you again.

On the other hand, it should give a warning when the host doesn't match what's recorded.

I have had problems where on OS X the hostname lookup acts like it fails; the connection just times out from waiting so long, or when the prompt does come up it's been waiting so long it gives about ten seconds for you to enter a password before dropping the connection. I never could trace it despite people suggesting adding the host in question to the host file. I guess it was just a "glitch with OS X's DNS lookups" and it was expected to be tolerated...if someone else had this problem and solved it I'd love to know about it.

Answer 3

Check the permissions on the ~/.ssh directory and files therein. Your default umask might be too permissive & when you recreated the files you might have inadvertently given them the wrong permissions. I have been burned by this a few times myself. None of the ssh clients (or servers) I used ever gave a useful error message about this either...

Answer 4

you have free disk space on your client (and on your server)?

df -h

Answer 5

Check the logs on the server. It's usually in /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RedHat/CentOS). Any problems with connecting usually are logged there.

Answer 6

So I'm posting this solution for other people who might be having this issue.

For me, upgrading to Snow Leopard solved the issue. So I think it was related to a bug in OSX.

Horraaay!