Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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!

share|improve this question
    
I have this same issue on Snow Leopard (10.6.8 with latest patches from Apple). It only happens when trying to connect to servers over a VPN. A reboot fixes the issue temporarily, but it inevitably comes back. Server DNS lookup is not the problem (tested that). It has something to do with the state of SSH on the client. Killing ssh-agent or switching to root does not solve the problem. –  Daniel Jun 27 '13 at 1:17
add comment

8 Answers

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.

share|improve this answer
add comment

The reason your ssh client hangs for your account but not for other accounts (root) is probably because there is something wrong with your ssh-agent. Either that the ssh-agent is not running or that its configuration is wrong in some way.

To have a confirmation of that, you can try the following:

unset SSH_AUTH_SOCK
ssh mylogin@myremoteserver.com

If you're then asked to input the pass phrase to your ssh_key it means you have an issue with your ssh-agent.

See also my post on this related question.

share|improve this answer
    
This did the job for me! However I need to do it each time I've restarted my computer. Do you know a way to fix this permanently? –  Johan Dettmar May 4 at 13:03
    
@JohanDettmar check my linked post and the advices it contains. If it doesn't help you more, it would probably best to ask a new question describing your issue with more details. –  Tonin May 5 at 18:03
add comment

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...

share|improve this answer
    
thanks for the tip. looks like my perms are the same. i can use ssh fine w/ my root account, and I verified that the perms are the same as that one. Weird thing is, it just hangs and doesn't say anything. Thanks for the attempt! –  saveraver Sep 16 '09 at 5:40
add comment

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.

share|improve this answer
    
Thanks Bart! So I've essentially deleted everything inside .ssh (wisely or unwisely) and there is nothing there now. It seems to still freeze up and continue to hang. Since i've also blown away known_hosts, it first asks if i want to continue connecting, puts the key in the known_hosts file and hangs at the same place as before. I'll quickly update my response to clarify this point. I really appreciate your help. –  saveraver Aug 23 '09 at 2:07
1  
It really sounds like the glitch I was running into on a MacBook. It seemed to be related to DNS lookups in some way, eventually I gave up and just lived with a loooong pause before connecting and hoped it would be fixed later. –  Bart Silverstrim Aug 23 '09 at 16:15
add comment

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

df -h

share|improve this answer
    
Thanks. Yes. plenty of space. more than 100 gigs free. Thanks for the tip tho. –  saveraver Sep 16 '09 at 5:40
add comment

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.

share|improve this answer
add comment
up vote 0 down vote accepted

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!

share|improve this answer
add comment

I had a similar problem.

ssh domain.ip:user.name

It seems that I could bypass the issue by forcing a login name like so.

ssh -v domain.ip -l user.name
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.