Last week I tried to SSH into my webhost account (on Site5) from work and—forgetting my password—it locked me out after several failed attempts. SSHd would just close the connection without asking my password.

work:~$ ssh user@example.com
Connection closed by xx.xx.xx.xx

I could log in from any other location, so I figured it was an IP ban and after a few days and a support ticket, I’d be in, but things got strange.

1. The Site5 techs could not find any evidence of a block on my account. They were pretty responsive.
2. It couldn’t be an IP block because I could log in from a virtual machine which used my workstation IP as gateway.
3. When connected to VPN (different public IP) it still refused me.
4. It couldn’t be a port 22 block because I could attempt a login to a different account on the same host and it would give me a password prompt.
5. Could it be Snow Leopard? I could log in from another workstation running it.
6. My machine? I could log in to several other hosts, including another account on a different Site5 host.

On the server I had an ~/.ssh/authorized_keys file with an old public key—the file hadn’t been touched for 2 years. I deleted it and—voila—SSHd would again ask for my password and log me in fine.

Why would the presence of authorized_keys cause SSHd to refuse to give a password prompt to one particular client’s connection to one particular account? OSX did give me a default RSA keypair, but even if the public key had been forwarded, SSHd should revert to password auth if it doesn’t find it in authorized_keys.