Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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 git@
open log failed: Permission denied
Connection to 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?

share|improve this question
Ps. I have also tested this from another computer with same setup, and with the same result. – user49884 Mar 7 '13 at 15:03
2 questions: 1. Does your authorized_keys have some sort of forced command defined? 2. Check auth.log. Does the initial login work? – cpast Mar 7 '13 at 15:22

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/
share|improve this answer
If I remember correctly, ssh also checks the permissions on ~, which does not be writeable by anybody than the owner (also not via ACL). – mpy Mar 7 '13 at 15:57
@mpy are you sure? That seems strange, I shold be able to choose to have my home writeable by other users on my network when collaborating. It seems a bit excessive that ssh should require that. – terdon Mar 7 '13 at 16:01
Quite right, that's common sense. However I learned it the hard way... but as I said, concerning the fine details I wasn't sure anymore. It needed some fiddling, but I could reproduce it again. To benefit from code indention I'll make another answer out of it. – mpy Mar 7 '13 at 16:44

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

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

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

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

share|improve this answer
@terdon: That took me quite some time to identify the reason back then. – mpy Mar 7 '13 at 17:01
Now it's working again. Thanks all. The solution was due to access rights of a library (but the .gitolite library). I changed it to 750. – user49884 Mar 7 '13 at 17:37
@user49884 could you post your solution as an answer please? – terdon Mar 8 '13 at 9:53
@mpy wow, even writeable by one other user breaks it? Good to know. – terdon Mar 8 '13 at 9:55

You must log in to answer this question.

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