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 [email protected]
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
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 [email protected]

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!

  • 1
    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
    Commented Jun 27, 2013 at 1:17

10 Answers 10


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:

ssh [email protected]

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.

  • 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? Commented May 4, 2014 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.
    – Lætitia
    Commented May 5, 2014 at 18:03

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.


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

  • 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
    Commented Sep 16, 2009 at 5:40

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

df -h

  • Thanks. Yes. plenty of space. more than 100 gigs free. Thanks for the tip tho.
    – saveraver
    Commented Sep 16, 2009 at 5:40

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

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


I got the same issue.

ifconfig wlan0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet  netmask  broadcast
        inet6 fe80::d949:d257:c622:3388  prefixlen 64  scopeid 0x20<link>
        ether 18:1d:ea:00:4e:cf  txqueuelen 1000  (Ethernet)
        RX packets 333970  bytes 471184965 (449.3 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 76462  bytes 9787485 (9.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Change mtu value to 1200. (MTU)

ifconfig wlan0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1200
        inet  netmask  broadcast
        ether 18:1d:ea:00:4e:cf  txqueuelen 1000  (Ethernet)
        RX packets 334117  bytes 471271158 (449.4 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 76604  bytes 9808842 (9.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

SSH connected as expected after this. Hope this answer shortens your search for workarounds. :)

  • MTU should not be set below 1280, otherwise IPv6 will break. Commented Sep 12, 2020 at 16:26
  • It was 1500 before, now when I set it to 1200, ssh works fine. Is there any optimal range?
    – Rahul Bali
    Commented Sep 13, 2020 at 17:34

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.

  • 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
    Commented Aug 23, 2009 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. Commented Aug 23, 2009 at 16:15

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.


Make sure /etc/hostname is newline-terminated.

You must log in to answer this question.

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