1

I've been working through a problem for the past week or so and I am running out of ideas.

I added a new user on my Centos 7 VPS for a git server, and (under the advice of several articles) placed the user's home directory inside /var instead of /home.

Then, I tried using ssh to log into that user, and it worked correctly. However, public key authentication did not work correctly. In the debugging process, I eventually made the git user and the primary user identical in every way -- they were both sudoers, they had the same .ssh directories, with the same authorized_keys files, and I even moved the git user to /home, but to no avail.

To test further, I created two new users: test1 and test2. test1's home directory was in /home, and test2's home directory was in /var. Sure enough, pubkey auth worked for test1 and not test2. I don't think it's a permissions issue, because /var has the same permissions that /home does, and the user directories all have correct permissions. Additionally, I am very perplexed that the original git user did not accept pubkey auth even after moving it to /home.

If I run ssh in verbose mode, I can see that the holdup occurs after sending the key:

debug1: Offering RSA public key: /home/user/.ssh/foo.key
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

When connecting to the primary user, or to test1, it acts differently:

debug1: Offering RSA public key: /home/user/.ssh/foo.key
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279

The only clue I have found: I get an identical response to the first one (waiting for reply, then skipping pubkey auth) when trying to login as a nonexistent user. So, is the machine making the git user invisible to the outside world? Why would it do that?

I can normally work through these things, but I think I'm pretty much stumped this time around. Thanks for any help!

forresthopkinsa
  • 185
  • 1
  • 10
  • Do the file and all its parent directories have correct permissions? – Jakuje Aug 12 '16 at 08:27
  • Yep, all of the permissions from `/` to `authorized_keys` are correct – forresthopkinsa Aug 12 '16 at 08:55
  • 1
    Also the SELinux labels? Post the output of `ls -ldZ / /var /var/user /var/user/.ssh/ /var/user/.ssh/authorized_keys`. – Jakuje Aug 12 '16 at 08:56
  • You cracked it! Thanks! Apparently in Centos, the .ssh directory has to have the `ssh_home_t` type, and I hadn't checked that (I thought `restorecon` would fix any SEL issues, but it was inheriting the type from `/var`). You can add this as an answer if you want the points, or I can do it. I don't know why this information isn't plastered all over the web, this is important. – forresthopkinsa Aug 12 '16 at 17:02

1 Answers1

1

It is SELinux problem. Moving things around filesystem works fine if you don't have this level of security, but SELinux sets labels to each file, by default based on their path.

When you move some special purpose directories, make sure they will have proper labels. In this case, there is chcon with --reference option, which serves well in this case:

chcon --reference /home/user/.ssh/ -R /var/user/.ssh/

Even better way would be to write a custom policy and load it into the kernel, but it is out of the scope of this answer.

Jakuje
  • 9,145
  • 2
  • 40
  • 44
  • 1
    This will only last until the next restorecon etc, you really need to use semanage fcontext to create a new regex based filesystem label e..g. https://serverfault.com/questions/784693/nginx-wordpress-cannot-upload-files-on-centos-6-8/784733#784733 – user9517 Aug 14 '16 at 19:43