bad ownership or modes for chroot directory component
Solution 1
From the man
page:
ChrootDirectory
Specifies the pathname of a directory to chroot(2) to after authentication. All components of the pathname must be root-owned directories that are not writable by any other user or group. After the chroot, sshd(8) changes the working directory to the user's home directory.
My guess is one or more of the directories on the path do not meet those requirements (my suspicion is www
is owned or writable by your web user, not root).
Go back and follow the directions, ensuring that the requirements above in bold italics are met.
Solution 2
ChrootDirectory directory must be owned by root and have 755 mode:
sudo chown root:root /var/www/RESTRICTED_DIR
sudo chmod 755 /var/www/RESTRICTED_DIR
Ok, now all files into /var/www/RESTRICTED_DIR
must be owned by MY_USER
, which must belong to www-data
group, and have 775 mode to allow group permissions, like this:
sudo usermod -a -G www-data MY_USER
sudo chown MY_USER:www-data /var/www/RESTRICTED_DIR/*
sudo chmod 775 -R /var/www/RESTRICTED_DIR/*
NOTE: Remember is a good practice allow access only to an htdocs folder if you are configuring apache.
Solution 3
After some troubleshooting today, I realized that root must also be able to write to the directories.
The following did not work:
$ ls -ld /mnt/synology03/files/
dr-xr-xr-x 1 root root 156 Oct 8 20:10 /mnt/synology03/files/
$ ls -ld /mnt/synology03
drwxr-xr-x 7 root root 4096 Oct 1 21:26 /mnt/synology03
$ ls -ld /mnt
drwxr-xr-x 6 root root 4096 Feb 8 10:01 /mnt
$ ls -ld /
drwxr-xr-x 24 root root 4096 Jan 14 09:22 /
As soon as I fixed this, my chroot started working.
$ sudo chmod 755 /mnt/synology03/files/
$ ls -ld /mnt/synology03/files/
drwxr-xr-x 1 root root 156 Oct 8 20:10 /mnt/synology03/files/
Solution 4
In my case below steps worked.
useradd -d /data/ftp/user1 -s /bin/false -g users -G sftponly user1
passwd user1
chown root:root /data/ftp/user1
- rights for group & others
chmod go+rx /data/ftp/user1
mkdir /data/ftp/user1/{upload,download}
chown user1:users /data/ftp/user1/{upload,download}
sftp user1@ipaddress_server
Check if user1 can write to /data/ftp/user1/{upload,download}
Better if user1 is only allowed sftp and not ssh access. Also the user1 should be chroot to his home director. This will help https://medium.com/tensult/configure-ftp-on-aws-ec2-85b5b56b9c94
Related videos on Youtube
MultiformeIngegno
Updated on September 18, 2022Comments
-
MultiformeIngegno almost 2 years
I created the user MY_USER. Set his home dir to /var/www/RESTRICTED_DIR, which is the path he should be restricted to. Then I edited sshd_config and set:
Match user MY_USER ChrootDirectory /var/www/RESTRICTED_DIR
Then I restarted ssh. Made MY_USER owner (and group owner) of RESTRICTED_DIR, and chmodded it to 755. I get
Accepted password for MY_USER session opened for user MY_USER by (uid=0) fatal: bad ownership or modes for chroot directory component "/var/www/RESTRICTED_DIR" pam_unix(sshd:session): session closed for user MY_USER
If I removed the 2 lines from sshd_config the user can login successfully. Of course it can access all the server though. What's the problem? I even tried to chown RESTRICTED_DIR to root (as I read somewhere that someone solved this same problem doing it). No luck..
-
MultiformeIngegno over 10 yearsThis is driving me mad. I did "chown root:root -R /var/www" ; "chmod 775 -R /var/www/" ; "usermod -a -G root www-data". But I still can't login with MY_USER
-
MultiformeIngegno over 10 yearsDoes the requirements include SUPPLEMENTARY groups (the one I added with usermod)?? If yes it's unusable.. :(
-
voretaq7 over 10 yearsThe requirement is on the Path Components (
/
,/var
,/var/www
, and/var/www/RESTRICTED_DIR
must all meet the security requirements above). It is a true chroot (review the man page) - your user's home directory needs to exist within the chroot, as must/bin
& all the other things your user will need... -
MultiformeIngegno over 10 yearsSome updates: the problem was
/var/www/RESTRICTED_DIR
had chmod0775
. I set0755
and all errors went away. Problem is it didn't login. I solved changingSubsystem
insshd_config
toSubsystem sftp internal-sftp
. Now: last problem: chrooted user doesn't have write access inRESTRICTED_DIR
..!! -
MultiformeIngegno over 10 yearsOk! Solved. I set the chrooted dir a level up. Then I gave 777 perms to the original chrooted_dir. It's working :)
-
Devy almost 10 yearsUsually, there will be hints in sshd's log.
/var/log/auth.log
in Ubuntu or/var/log/secure
in RHEL. -
mmell over 9 yearsDespite what the manpage says, and even with the group set to 'root', I had to set g-w permission before it would work (Ubuntu 14.04). The manpage should say All components of the pathname must be root-owned directories that are not writable by any other user or any group at all
sudo chown root:root -R /path/to/home; sudo chmod 755 -R /path/to/home
-
voretaq7 over 9 years@mmell um... that's what the manpage says: "root-owned directories that are not writable by any other user or group" means the "write" bit for Group and Other must be zero. (If you find the manpage unclear however you should submit a documentation patch to the OpenBSD/OpenSSH project to improve it. Complaining about it here won't get the docs changed.)
-
Daniel almost 8 yearsI know this is quite old, but instead of modifying the permissions for the
/var/www
path directly, which might break apache, you'd be far better off putting your sftp directory in another path, then using URL mapping in Apache to point to the other directory. Check the documentation here httpd.apache.org/docs/2.4/urlmapping.html underFiles Outside DocumentRoot
-
Felipe Alcacibar almost 8 yearsYou can still give permission to another user using acl
setfacl -Rd -m 'u:MY_USER:rwx' /var/www/RESTRICTED_DIR && setfacl -R -m 'u:MY_USER:rwx' /var/www/RESTRICTED_DIR
-
sMyles over 7 yearsPretty sure it should be
sudo usermod -a -G www-data MY_USER
as the group should come after-G
-
jlh about 6 yearsThis drives me crazy... If nobody excepted root has write access to it, how is the user logging in supposed to upload new files? It defeats the entire purpose why I set up sftp in the first place.
-
dlopezgonzalez over 5 yearsThis works but I cannot upload new files to the directory, I only can modify files created before with root account and with the user ownership.
-
rinogo over 4 years@dlopezgonzalez The same thing happens for me. The best solution I can come up with is to create another directory (e.g.
/var/www/RESTRICTED_DIR/uploads
) that is owned by the user. If this isn't ideal for you, you could relocated the ChrootDirectory and use a symlink (e.g./var/www/RESTRICTED_DIR
is a symlink that points to/sftp/uploads
(where/sftp
is owned by root and/sftp/uploads
is owned by the user) -
leonheess about 4 years@jlh That's what I'm thinking - did you solve this dilemma?
-
Holger Böhnke about 2 years@jlh Just create a dir owned by your user with write perms below your chroot dir:
/var/www/RESTRICTED_DIR/<youruser>
-
John Greene about 2 yearsWhat about the passwd of user1? Lock it??
-
W R about 2 yearsYes. Need to set a password for the user1. Missed that step which I have added to the answer now.
-
John Greene about 2 yearsJust don’t lock the root account or you’ll get a cryptic error when trying sudo from within a root account. Caveat.