29

EDIT

The issue as exposed here is solved (about files modes of the .ssh folder.

But an other issue persists so I create a new question : > Unable to login with SSH-RSA key

I can no longer connect with ssh-rsa key for a specific user, but it still work for other users.

The git user defined as follow :

# cat /etc/passwd | grep git
git:x:1002:1002:,,,:/var/git:/bin/bash

So you noticed that this is the git user thus its home is /var/git, it's not in /home.

Now, ssh always prompt me for password :

$ ssh git@srv
git@srv's password:

I checked logs :

# tail -n 1 /var/log/auth.log
[...] Authentication refused: bad ownership or modes for file /var/git/.ssh/authorized_keys

So authorized_keys as some ownership or modes missconfiguration. I don't understand because here is the conf for this file :

# ls -l /var/git/.ssh/ | grep auth
-rw-rw-r-- 1 git git 394 mai   22 17:39 authorized_keys

And here is (in case...) the parent .ssh dir:

# ls -al /var/git/ | grep ssh
drwxrwxr-x  2 git  git  4096 mai   22 17:39 .ssh

And the $HOME directory :

# ls -l /var/ | grep git
drwxr-xr-x  7 git  git    4096 mai   27 10:49 git

So owners are always git, like owner groups. And files are readable so where could be the trick ?

Rémi B.
  • 945
  • Does the .ssh directory actually require group-write access and on all of its files as well? –  May 27 '15 at 10:02
  • 1
    @Nasha the exact oppposite - permissions here are too lax - as answered below by Otheus and damienfrancois. – Chris Davies May 27 '15 at 10:12
  • Well, I meant «as per your setup, can you consider restricting rights on the .ssh folder without impeding your installation?» BTW every file (with the exception of public keys) in the .ssh directory must (at least should) be read/write-able by the owner only, no access to group/others. –  May 27 '15 at 11:16

3 Answers3

45

The problem is the fact that file and directory permissions do not meet the requirements of StrictModes, which in OpenSSH is yes by default and should not be changed. Try setting the permissions of authorized_keys to 0600 and the .ssh directory to 0700.

# chmod 0700 .../.ssh/
# chmod 0600 .../.ssh/authorized_keys

Note that the ... will differ based on installation (e.g., in this question it is /var/git/ but for users it will be /home/username/.

Paul
  • 507
damienfrancois
  • 916
  • Nope that's not it. authorized_keys and .ssh may be world-readable and ssh will work. – Otheus May 27 '15 at 09:58
  • 2
    only if owned by root – damienfrancois May 27 '15 at 09:59
  • It applies to any user. At least in v 5.3p1 – Otheus May 27 '15 at 10:00
  • I trust you ; though the manpage on my systems says, about authorized_keys: "This file is not highly sensitive, but the recommended permissions are read/write for the user, and not accessible by others." – damienfrancois May 27 '15 at 10:03
  • You were right. I no longer get this error now. I applyed 600 on both authorized_keys file and .ssh folder (required after getting a new error message in logs, about .ssh folder). But surprisingly, ssh ask me again for password, with no any error in /var/log/auth.log. Any idea? Do you think I have to restart sshd ? – Rémi B. May 27 '15 at 10:06
  • 2
    Connect with ssh -vv. That might provide you a hint why the public/private key authentication is failing. – Otheus May 27 '15 at 10:12
  • 4
    Something useful is to start sshd in debug mode on the target machine with (from my memory so maybe not 100% accurate) /usr/sbin/sshd -d -e -p 1234 so you have a sshd server listening on port 1234 with all info spit out in the console. – damienfrancois May 27 '15 at 10:12
  • (^-- and connect to port 1234 with the client via ssh -p 1234) – Otheus May 27 '15 at 10:13
  • I also had to give 600 permissions to the root's home dir. – Ray Jul 19 '17 at 09:32
  • I had to give the user's home dir 755 permissions, then it worked - seems that it's very fussy about privileges (understandably so) – Rich S Mar 14 '19 at 17:19
  • This didn't work for me at all. I only got mine to work after very carefully copying the permissions from a separate working machine. For me, these were: chmod 755 $HOME, chmod 775 $HOME/.ssh, chmod 664 $HOME/.ssh/authorized_keys. I'm on Ubuntu Server 20.04. – Magnus Sep 02 '20 at 16:38
  • This fixes everything in one go: chmod go-w ~/;chmod 700 ~/.ssh;chmod 600 ~/.ssh/authorized_keys – Christian Nov 05 '20 at 13:48
6

For reasons of paranoia, the .ssh directory and authorized_keys must not be group-writable. I guess the thinking is, the user must be the only one with explicit control over his/her authorization. I believe a work-around for this lies with ACL. The other work around is StrictModes=no setting in sshd's configuration file. But it would be too dangerous to do that for the sake of one user.

P.S. your ls -l /var | grep git is more concisely done as ls -ld /var/git

Toby Speight
  • 8,678
Otheus
  • 6,138
  • 1
    I can change out your entire .ssh directory with mine if group writable would be allowed on HOME, or .ssh. That is not paranoia but a considerable risk. – YoYo Sep 29 '15 at 03:10
  • 1
    Anytime permissions for a user's home dir are set to group-writable, it's a considerable risk. But there are times when we know exactly what we're doing. It pisses me off the SSH team seems to assume the user doesn't. – Otheus Oct 07 '15 at 09:28
5

The $HOME/.ssh directory mode must be 700 and authorized_keys should be readable by the owner only, i.e. mode 600:

chmod u=rwx,g=,o= /var/git/.ssh
chmod u=rw,g=,o= /var/git/.ssh/authorized_keys

As to the private key, it must be read-write-able by the owner only:

chmod u=rw,g=,o= /var/git/.ssh/id_?sa
Community
  • 1
  • What version are you running, Nasha? Have you actually tested this? That is, have you tested that og must not be read-execute? – Otheus May 27 '15 at 10:10
  • I'm using ssh-server-6.2p2 on Mint. Works the same on Gentoo. I've been using this setup for quite some time without a problem. My SSH server runs as root BTW. –  May 27 '15 at 11:03
  • 1
    @Otheus me --> /facepalm/ :-D Sometimes you can't spot the wrong bit looking too closely at it... –  May 27 '15 at 11:22
  • 3
    Actually 700 and 600 are safest way to do. However 660 might work: if the user's group has no other users in it! I learnt it the hard way, the working login was denied after I added another user to the group, lol. – fchen Jan 08 '18 at 04:48
  • 2
    @lol I also saw exactly this and it got me puzzled... I added a new user to the user's group, and suddenly authorized_keys-based authentication stopped working. If someone could locate information about this behaviour in the documentation, it would be great. – Per Lundberg Jul 17 '19 at 08:02