Stuck on SSH public key authentication for www-data
 

I have a web server and a desktop. I would like to be able to mount /var/www/html/ from the webserver to a directory on my desktop using sshfs.

I have a user 'anthony' on both the server and the desktop. I can SSH between the desktop and server with public key authentication (password login is disabled).
From there, I can 'su' to www-data (I have set a password for the www-data user).

As you can see, public key authentication is working properly.

I thought that I could just copy my id_rsa.pub from my desktop into /var/www/.ssh/authorized_keys on the server. But it's not working like I thought it would:
Here's the verbose output:
When that didn't work, I tried copying /home/anthony/.ssh/authorized_keys to /var/www/.ssh/authorized_keys (in case I had somehow incorrectly copied my public key) but that still didn't work.

I've checked, and I'm using the correct home directory for www-data:
I do not have "AllowUsers" set in my /etc/ssh/sshd_config

I didn't know if I needed a keypair for www-data, so I generated that, and that didn't fix it either.

I checked that the permissions for authorized_keys is the same as the user 'anthony':
So what I'm not understanding is why it's not allowing me to log in? I have my desktop's public key in www-data's authorized_keys on the server. It's not a problem with SSH, I can ssh from anthony@maples-desktop to anthony@poweredge1950 without any problem.

/var/www/.ssh/authorized_keys permissions should be set to owner rw (chmod 600 /var/www/.ssh/authorized_keys)

That didn't work either. I changed the permissions, but even after I restarted the SSH server, "ssh www-data@192.168.0.100" still gave me "Permission denied (publickey)."

authorized_keys file contains anthony@maples-desktop's id_rsa.pub content?

Yes. Right now, that's all it contains:

Same content ;)

At this point, you don't see differences comparing ~/.ssh directories for both www-data and anthony users ? Not using authorized_keys2 in anthony's .ssh for example?

Nope, nothing like that:

Nothing in logs (as root) tail /var/log/messages
Or grep ssh /var/log/*

What are the permissions of /var/www ?

Nothing shows up in either of the commands you suggested for the logs:
The other command only came up with a lot of "Accepted pubkey for anthony from 192.168.0.101...", dpkg logs from when I installed it, and popcon logs.

However, I checked the end of auth.log, which contained something worth mentioning (immediately after I tried SSHing to www-data@192.168.0.100):
I'm not sure what this means, though; I don't see anything unusual with the permissions (as listed above).

I think it's the culprit, permissions too permissive :/

Try chmod 755 /var/www

www-data has a nologin shell, I'll bet is jamming you up.
Also, if you have keys, then why allow "ssh www-data@server" without one?

That did it! I can now SSH as www-data, and sshfs is now working as expected.

I wonder why it refuses to let you login when group has write permission?

Thanks for all the help! :D

That was something that I had done long ago (otherwise I wouldn't have been able to give the output from www-data in the replies above):
And yes, I am using SSH keys. /etc/ssh/sshd_config has "PasswordAuthentication" set to "no"; it's been that way since the day I set it up.

It's so the key used for authentication cannot be overwritten by others.

Also, the user and group www-data are for privilege separation and should not have write access to anything in the web server's document root, except for special exceptions regarding individual files in certain CMSs. Adding write permission for www-data, as shown in #10 above, breaks the security model and is likely end up costing you in the medium to long term.

What problem were you trying to solve? If it was shared access to the web server's document root or other files, then a special group should be made for that and write access given to that new group instead of www-data.

We can look at the OpenSSH source code to answer this question. I'm on Arch.

which gives us this

Ok, that makes sense.

It's my home server running in my basement. I wanted a way to be able to edit files in the /var/www/html/ folder (to edit the web pages) and that seemed like a solution. It's a single-user environment and I don't think that's going to ever change.

So if www-data shouldn't have write access, then who should? I don't want to give it to just root, for several reasons. (The biggest one being that I don't think I should have to log in as root just to edit HTML.) Should I give it to my user, or should I create a separate user just for that purpose?

You're right about not logging in as root for that. You should just give the files and directories to your user.

If you are the only user and only ever going to be the only user then it is enough to just chown it to your account and group. Then you can make as many changes as you want and www-data cannot write. Just make sure that the directories have o=rx and that files have o=r so that the web server can still read them.

If you would be moving to a simple multi-user environment, where more than one account would need to edit the web files, then you would just make a new group and apply that, along with the SetGID bit to the directories.

How would I go about doing that? I had tried to do something like that earlier by making /var/www/html 775 ww-data:www-data and adding my user to the www-data group, but that didn't work (and caused the problems that led to this thread...)

I think you're saying that it should be a new group, not the www-data group.

I've heard very little about setuid, and never heard of setgid, so I'm going to head over to Google. But what would I need to do to implement what you suggested above?

Just pick a name for the new group and apply it. It could go something like this:

That leaves any other directories under /var/www/ alone such as maybe /var/www/cgi-bin/
The two 'find' instance show the difference settings for files and directories.

(Numerically that would be 2775 in octal instead of u=rwx,g=rwxs,o=rx in symbolic mode. The symbolic mode works to unset the setgid bit also but the octal mode does not.)

The owner of the directories and files is not important as long as it is not www-data. You could leave that as maples, as long as the group is set to the shared group.

Then add users to the shared group.

On most systems your 'umask' defaults to 0002, so that means files you create in the affected directories will be group writable by the group 'webmeisters'. Your account will be in the new group the next time you log in.

mod_userdir could be simpler to use in an home config (and will not be affected by system upgrade, in case upgrade replaces all the /var/www config)

Server dir would be in anthony@poweredge1950:public_html, url would be http://poweredge1950/~anthony

So from what I found last night, the setGID bit will ensure that files created in that directory will have the same group as the parent directory. So any file that I create (with any user that has sufficient privileges to write) will have webmeisters as the group, right?


I've never looked very closely at my umask before, but most of my files in ~/ (on several systems) are -rw-r--r--. On this Debian server, my umask is 0022:
Is there a way to set the umask only for a directory? (so any file I create in /var/www/html/ has umask 0002, but everywhere else is still 0022)
EDIT: Google informs me that you can't do that. So since I have a group for my user and all files I create in my home directory are anthony:anthony, is it any security risk to set umask to 0002?

ACLs
 

Yes.

I was hoping not to have to think about ACLs, but they can do that and it's not possible any other way with the EXT file systems. :( The part that I find confusing, aside from the ACLs themselves, is that umask is for the processes (e.g. your shell) not the file system.

The -b clears any previous ACL for that directory before making the settings specified by -m, otherwise it can get cluttered when experimenting.

You can see what you have set with 'getfacl'

If you have a large business or organization with many users in your basement then you can consider OpenAFS, which has much easier way, but is harder to install.

I think I'm going to stick with umasks for now, though ACLs look like something I should look into some day.

Theoretically, if this was a multi-user environment, would /etc/profile be an appropriate place to put the umask?

Yes, but a separate file in /etc/profile.d/ is better. If they are using bash, ksh, or zsh, then put a file in /etc/profile.d/ with a name you will recognize and have that contain the 'umask' setting. It will set umask for everyone with the main shells: bash, zsh, and ksh. The default is bash. It is always possible for the user to modify their own umask if even only for their current session.

Awesome. I just made /etc/profile.d/my_umask.sh with "umask 0002" and that seemed to take care of it.

And the sshfs still works like I originally intended :D

Thank you!

You really should stick this in your blog so I can find it readily. ;)
I look for it a lot.

I'll see what I can do to polish it and make a blog entry of it. I'm not sure how slow or fast I can get to it though. Which terms or phrases would be most useful in helping find it again?

You're welcome.

As per your suggestion, I've posted an entry: https://www.linuxquestions.org/quest...e-users-37043/

Let me know if there are any phrases or terms that you normally use when searching for it and I can add them.