ssh can't use key, but password works

Question

I have an Ubuntu server running for my SCM, and am doing my development on a windows computer. This setup has worked for a long time with out any problems. But now I get a strange problem.

The problem started when I needed to change the access rights on a git repository on the server (don't tell me it was stupid to chmod the entire home directory... I already know). After that, every time I try to access the server via ssh (git inclusive) using my public key. I get the following error:

$ ssh [email protected]
open log failed: Permission denied
Connection to 192.168.0.240 closed.

However, when I try to connect to the server, using only password, everything works as expected:

I have tried running the sshcommand with -vvv. It does not give me any idea where to look for the problem. Maybe you can see something from it.

...
debug2: channel 0: request shell confirm 0
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug2: channel 0: rcvd ext data 35
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug2: channel 0: rcvd close
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug3: channel 0: will not send data after close
debug2: channel 0: obuf_empty delayed efd 6/(35)
open log failed: Permission denied
debug2: channel 0: written 35 to efd 6
debug3: channel 0: will not send data after close
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1)

Any ideas?

Answer 1

Your problem is probably that the permissions of your user key are wrong. Try this on the Ubuntu server:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa ~/.ssh/authorized_keys
chmod 644 ~/.ssh/id_rsa.pub

Answer 2

In addition to terdons's answer, some weired behavior with ssh keys also occurs, if ~ is writeable by others.

Assume, you have successfully set up ssh to use key login:

user@local:~> ssh remote
Last login: Thu Mar  7 17:39:18 2013 from local
user@remote:~>

Now make your home writable by some other user on the remote machine:

user@remote:~> getfacl .
# file: .
# owner: user
# group: users
user::rwx
group::r-x
other::r-x
user@remote:~> setfacl -m u:coauthor:rwx .
user@remote:~> exit
user@local:~>

Ok, now try again to log into remote:

user@local:~> ssh remote
user@remote's password:

ssh prompts for password now! Remove the ACL, and voilà ssh key is working again.

[ My workaround was then to use a subdirectory for collaboration.]

---

Craig Sanders knows the reason, this behavior depends on StrictModes yes in sshd_config. Quoting man 5 sshd_config:

StrictModes Specifies whether sshd(8) should check file modes and ownership of the user's files and home directory before accepting login. This is normally desirable because novices sometimes accidentally leave their directory or files world-writable. The default is “yes”.