SFTP transfers fail! Debian permissions issue?
Hi everybody,
I'm quite new to Linode. My Debian 10.6 installation is only a couple of days old, but everything that I've setup so far works great (thanks to the superb Linode guides).
As expected of me, I've "hardened" my node and established a new user that isn't root
. However, when I connect via SFTP and try to upload a file to /var/www/my-site
, where the server homepage is located, the transfer fails.
I connect with my new user account that has sudo
privileges, however I haven't messed with the file permissions of any directory in Debian. Is this due to the fact that I, as the new user, have only privileges in the user's home directory?
Furthermore, does anything speak against hosting sites from /var/www/
?
I find it orderly, because the site for now doesn't really have anything to do with any user, but rather the server itself.
If it were the other way around, where in the user home directory would user specific website content usually be placed?
Regards and thanks.
4 Replies
@diff-arch --
You write:
As expected of me, I've "hardened" my node and established a new user that isn't root. However, when I connect via SFTP and try to upload a file to /var/www/my-site, where the server homepage is located, the transfer fails.
This is because the user running sftp(1) doesn't have permission to write to /var/www/my-site…because that user (probably the new user you mention) doesn't own /var/www/my-site and it's permissions disallow writes by any user but the owner (probably root):
stevewi@dave:/var$ ll -a /var/www
total 12
drwxr-xr-x 3 root root 4096 Apr 2 2020 . <<< only 'root' can write here
drwxr-xr-x 12 root root 4096 Apr 2 2020 ..
You also write:
I connect with my new user account that has sudo privileges, however I haven't messed with the file permissions of any directory in Debian. Is this due to the fact that I, as the new user, have only privileges in the user's home directory?
Just because your new user is an sudoer does not mean that your user can walk all over every filesystem restriction that exists whenever you want. Being an sudoer, gives your login the ability to assume superuser privileges at will. That assumption must be specifically invoked and is of finite duration. You can do this by one of two methods:
- Run su(1) to become the superuser:
$ su
Password: *******
n.b., at this point you are running a shell with superuser privileges...
the change in prompt tells you that
# id
uid=0(root) gid=0(root) groups=0(root)
# exit
$ id
uid=1000(stevewi) gid=1000(stevewi) groups=1000(stevewi),27(sudo),33(www-data),100(users)
- Run a single command with superuser privileges with sudo(8):
$ sudo <some-command>
Password: *******
n.b., at this point <some-command> is finished and you are back to
your login shell
$ id
uid=1000(stevewi) gid=1000(stevewi) groups=1000(stevewi),27(sudo),33(www-data),100(users)
You can read more about filesystem permissions and access modes here:
https://www.tutorialspoint.com/unix/unix-file-permission.htm
You can read more about su(1) and sudo(8) here:
To solve your specific problem, you can use sftp(1) (or scp(1)) to upload your site to your home directory. Once that's done, you can login to your Linode with ssh(1) and then sudo mv /home/myname/my-site /var/www
. Easy peasy… It's not really recommended to allow root to login remotely using ssh(1), sftp(1), scp(1) (and, yes, all of these login before they do what they do).
Lastly, you write:
Furthermore, does anything speak against hosting sites from /var/www/?
I find it orderly, because the site for now doesn't really have anything to do with any user, but rather the server itself.
If it were the other way around, where in the user home directory would user specific website content usually be placed?
You can put your sites wherever you want and have (or can assume) the permission to do so. I usually don't put them in /var/www because I usually want them higher up in the filesystem hierarchy but that's just me. You can put your site(s) in your home directory if that's what you want to do. However, if your password gets compromised and someone you don't know logs in as you, you can kiss your sites goodbye.
Also, backups are your friend.
I hope this helps…
-- sw
Hi @stevewi,
Thanks for your great reply! I've read through the two resources you kindly provided, and now feel like I understand a little bit more.
To solve your specific problem, you can use sftp(1) (or scp(1)) to upload your site to your home directory. Once that's done, you can login to your Linode with ssh(1) and then sudo mv /home/myname/my-site /var/www.
Great suggestion! Thanks.
It's not really recommended to allow root to login remotely using ssh(1), sftp(1), scp(1) (and, yes, all of these login before they do what they do).
I've disabled root from using remote login, like specified in the "hardening" guide.
You can put your sites wherever you want and have (or can assume) the permission to do so.
Got it.
I usually don't put them in /var/www because I usually want them higher up in the filesystem hierarchy but that's just me.
OK, what do you call "higher up". I guess /var/www
would be "low", because it's near the root directory /
? Could you maybe kindly provide an example?
Do you for instance add site-specific users, and put the websites in their user-specific home directories?
You can put your site(s) in your home directory if that's what you want to do. However, if your password gets compromised and someone you don't know logs in as you, you can kiss your sites goodbye.
Yes, I've restricted remote user login to SSH keys. If you don't have my local keys, you can't login. You'd have to break into my local machine first (or into my Linode account I guess). ;)
Also, backups are your friend.
Yes, I still do have to set this up. Any pointers for this (if I want to do it "manually" without the Linode backup service)?
Thanks again!
--
Marc
You write:
OK, what do you call "higher up". I guess /var/www would be "low", because it's near the root directory /? Could you maybe kindly provide an example?
In my (probably old-school) understanding, "lower" means "farther away from /"…"higher" is "closer to /". None of that matters…and is probably just a reflection of the difference in our ages ;-) These semantics depend on if you view the filesystem hierarchy as a tree or an inverted tree.
I create a directory called /srv to hold the config for all the services I've created and/or manage. So, /srv looks basically like this:
bin dmarc etc ical ids lib mail netinfo var www
/srv/{bin, etc, lib, var} should be pretty straightforward. The services I have are:
- dmarc (for DMARC analysis tools/databases);
- ical (CalDAV/CardDAV calendar/addressbook services for Macs/iPhones);
- ids (intrusion detection/mitigation);
- mail (email);
- netinfo (network info that feeds ids); and
- www (web sites).
Of course you could point out that /var/www and /srv/www are at the same level in the filesystem hierarchy…and you'd be right. However, /var has a ton of other stuff in it that I didn't want to have to filter through. Also, /var is always owned by root…I wanted the freedom to set the permissions/ownership in /srv as I saw fit…to make it convenient for me (while maintaining security).
Although, technically, /srv/ical is a website because CalDAV/CardDAV are web-based services (I separated it from /srv/www because of it's specialized nature). Also, /srv/dmarc will probably get folded into /srv/mail in the near future…as my next round of pandemic-induced tv-avoidance ramps up. DMARC is an email message authentication thing…
I wouldn't get too hung up on this… It's really your preference. How you set it up should be natural and straightforward for you. If it works for you and it's easy for you to remember, those are the most important things.
Do you for instance add site-specific users, and put the websites in their user-specific home directories?
I do. These personal sites are in $HOME/www for each user and have the url http://my-server.com/~username. I don't manage what's in these at all…just provide the service. They aren't used much.
You write:
Also, backups are your friend.
Yes, I still do have to set this up. Any pointers for this (if I want to do it "manually" without the Linode backup service)?
Sorry, I use the Linode backup service. There's some other threads that address this issue. Do a search…
-- sw