asked on
SFTP can either login or write files - not both
I have an Ubuntu server running 10.04.6 LTS. It is providing web services. I have setup sftp and given permission to an 'sftp' group to login but have set their root directory to be /var/www/html. They are able to connect to the server but cannot write to the folder. I use setfacl to give the group write permission. If they are already logged in, they can now create folders and files. However, once they logout, they can no longer login. If I remove the acl, the condition reverses again. It is not limited to acls though. I even tried just giving 'other' write-access. Same thing happened.
sshd_config snippet:
Match group sftp
ChrootDirectory /var/www/html
X11Forwarding no
ForceCOmmand internal-sftp
Error when trying to write:
Permission denied.
Error code: 3
Error message from server: Permission denied
Error when trying to login (from session log):
! 2019-12-11 08:23:42.538 Using username "ddinkin".
. 2019-12-11 08:23:42.569 Server offered these authentication methods: publickey,password
. 2019-12-11 08:23:42.569 Prompt (password, "SSH password", <no instructions>, "&Password: ")
. 2019-12-11 08:23:44.955 Sent password
. 2019-12-11 08:23:44.963 Access granted
. 2019-12-11 08:23:44.963 Opening session as main channel
. 2019-12-11 08:23:45.127 Network error: Software caused connection abort
* 2019-12-11 08:23:45.181 (EFatal) Network error: Software caused connection abort
* 2019-12-11 08:23:45.181 Authentication log (see session log for details):
* 2019-12-11 08:23:45.182 Using username "ddinkin".
* 2019-12-11 08:23:45.182
* 2019-12-11 08:23:45.182 Authentication failed.
What am I missing? I am not a linux guru so please be gentle. I even asked some local SMEs and they don't know either.
Thanks,
Dan
sshd_config snippet:
Match group sftp
ChrootDirectory /var/www/html
X11Forwarding no
ForceCOmmand internal-sftp
Error when trying to write:
Permission denied.
Error code: 3
Error message from server: Permission denied
Error when trying to login (from session log):
! 2019-12-11 08:23:42.538 Using username "ddinkin".
. 2019-12-11 08:23:42.569 Server offered these authentication methods: publickey,password
. 2019-12-11 08:23:42.569 Prompt (password, "SSH password", <no instructions>, "&Password: ")
. 2019-12-11 08:23:44.955 Sent password
. 2019-12-11 08:23:44.963 Access granted
. 2019-12-11 08:23:44.963 Opening session as main channel
. 2019-12-11 08:23:45.127 Network error: Software caused connection abort
* 2019-12-11 08:23:45.181 (EFatal) Network error: Software caused connection abort
* 2019-12-11 08:23:45.181 Authentication log (see session log for details):
* 2019-12-11 08:23:45.182 Using username "ddinkin".
* 2019-12-11 08:23:45.182
* 2019-12-11 08:23:45.182 Authentication failed.
What am I missing? I am not a linux guru so please be gentle. I even asked some local SMEs and they don't know either.
Thanks,
Dan
Web ServicesSSH / Telnet SoftwareUbuntuLinuxLinux OS Dev
Last Comment
David Favor
ASKER
Thanks for the info, David. However, my setup already matched this pretty closely. I did change my facls to include the www-data user. The symptoms of my problem remain - see original post.
The sftp server I used is https://linuxconfig.org/how-to-setup-sftp-server-on-ubuntu-18-04-bionic-beaver-with-vsftpd
Thanks,
Dan
The sftp server I used is https://linuxconfig.org/how-to-setup-sftp-server-on-ubuntu-18-04-bionic-beaver-with-vsftpd
Thanks,
Dan
Tip: VSFTPD will likely drive you crazy. I gave up on using this years ago, as this product... along with most SFTP servers... requires... deeply understanding the crazy permission management system.
It's been so many years since I abandoned all SFTP servers requiring management... as best I recall, with VSFTPD, there's some sort of special ownership + permission enforcement of upstream parent directories.
Again, as I recall, the only way I could ever get VSFTPD to work sensibly was to do this...
1) Setup a completely separate user system like /sftp/$user/... directory hierarchy.
2) Associate default www-data:www-data (or your Webserver user/group) with #1.
3) Then symlink each Website DocumentRoot into #1.
Again, as I recall, this was very fragile + seemed to work.
Tip: Or you can just install MySecureShell + everything will just work.
It's been so many years since I abandoned all SFTP servers requiring management... as best I recall, with VSFTPD, there's some sort of special ownership + permission enforcement of upstream parent directories.
Again, as I recall, the only way I could ever get VSFTPD to work sensibly was to do this...
1) Setup a completely separate user system like /sftp/$user/... directory hierarchy.
2) Associate default www-data:www-data (or your Webserver user/group) with #1.
3) Then symlink each Website DocumentRoot into #1.
Again, as I recall, this was very fragile + seemed to work.
Tip: Or you can just install MySecureShell + everything will just work.
About your specific config.
Just glancing at what you provided, this will never work, because you're trying to have SFTP users access your Apache directory hierarchy... in a way which seems incorrect...
Tip: Testing all this inside SFTP will drain away many hours, unless you use MySecureShell (no debugging).
Better to test this outside SFTP, by using su to change users to your SFTP users to test permissions first.
I believe your thinking is reversed about ACLs.
1) Your default ownership/permissions better remain as www-data:www-data by default or you'll be in a world of hurt.
2) Then you must add an ACL to add www-data:www-data to any new files/directories created by SFTP users, which will be...
At this point Apache will be able to serve existing files + any new dirs/files created by any SFTP user.
Note: Without this ACL, any newly created dir/file will throw a 403 error in Apache.
3) At this point, you must add a new ACL for every SFTP user, which will allow any SFTP user to see all Apache owned dirs/files... as in...
4) You must execute #3 for each new $sftpuser you add to your system.
5) This (or some similar approach) will likely clear up the "Error message from server: Permission denied" error you're seeing.
Just glancing at what you provided, this will never work, because you're trying to have SFTP users access your Apache directory hierarchy... in a way which seems incorrect...
Tip: Testing all this inside SFTP will drain away many hours, unless you use MySecureShell (no debugging).
Better to test this outside SFTP, by using su to change users to your SFTP users to test permissions first.
I believe your thinking is reversed about ACLs.
1) Your default ownership/permissions better remain as www-data:www-data by default or you'll be in a world of hurt.
2) Then you must add an ACL to add www-data:www-data to any new files/directories created by SFTP users, which will be...
setfacl -Rm d:u:www-data:rwX,u:www-data:rwX /var/www/html 2>/dev/null
At this point Apache will be able to serve existing files + any new dirs/files created by any SFTP user.
Note: Without this ACL, any newly created dir/file will throw a 403 error in Apache.
3) At this point, you must add a new ACL for every SFTP user, which will allow any SFTP user to see all Apache owned dirs/files... as in...
setfacl -Rm d:u:$sftpuser:rwX,u:$sftpuser:rwX /var/www/html
4) You must execute #3 for each new $sftpuser you add to your system.
5) This (or some similar approach) will likely clear up the "Error message from server: Permission denied" error you're seeing.
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
The approach in the URL you posted will work in simple cases... in a way (very slack security, with no way to debug hacked systems)... for single user systems...
If high security is required across many users, refer to the setfacl approach.
If high security is required across many users, refer to the setfacl approach.
Most ways produce massive complexities, as very few sftp servers work as expected (simple + zero config + chroot logins).
https://www.experts-exchange.com/questions/29133071/Safe-and-productive-ownership-settings-for-a-Wordpress-installation.html provides one approach to using SFTP with HTTPS, so file ownership works with both.
Tip: Ensure you can install setfacl first + verify setfacl actually works (requires a modern OS with acl option set on mount point of file system).
It will be near impossible to produce a secure system without setfacl working, where files are shared between Apache + SFTP, especially if you have more than on SFTP user.