17

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!

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

10 Answers 10

Reset to default
14

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.

Improve this answer
2
  • 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, 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
    May 5, 2014 at 18:03
7

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.

Improve this answer
1

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

Improve this answer
1
  • 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, 2009 at 5:40
1

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

df -h

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

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
Improve this answer
1

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

Improve this answer
1

I got the same issue.

ifconfig wlan0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.9  netmask 255.255.255.0  broadcast 192.168.1.255
        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 192.168.1.9  netmask 255.255.255.0  broadcast 192.168.1.255
        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. :)

Improve this answer
2
  • MTU should not be set below 1280, otherwise IPv6 will break.
    – Michael Hampton
    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
    Sep 13, 2020 at 17:34
0

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.

Improve this answer
2
  • 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, 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.
    – Bart Silverstrim
    Aug 23, 2009 at 16:15
0

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.

Improve this answer
0

Make sure /etc/hostname is newline-terminated.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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