SFTP – Troubleshooting Authentication Failures

fedorasambasftpssh

I am trying to setup sftp access for our customers to download or upload files. While trying to setup the directory permissions and user access I keep getting errors as such.

server1 sshd[21760]: Accepted password for user01 from 192.168.1.118 port 51026 ssh2
server1 sshd[21760]: pam_unix(sshd:session): session opened for user user01 by (uid=0)
server1 sshd[21775]: fatal: bad ownership or modes for chroot directory "/home/user01"
server1 sshd[21760]: pam_unix(sshd:session): session closed for user user01

I have the following setup in the sshd_config file:

Match Group sftp_users
ChrootDirectory %h
ForceCommand internal-sftp

Folder/file permissions show as this:

drwxr-xr-x 4 user01 sftp_users 4096 Mar 28 09:26 /home/user01

I have a mounted drive as such:

//windowserver/ftproot/customers/user01 on /home/user01 type cifs (rw)

What I am failing to understand/determine is if the user "user01" has read/write access to it's own home directory on the local machine, but when using ssh/sftp the error of "bad ownership/modes" is returned. Is it because the session for user01 is opened by uid=0? In this case the uid for user01 is 502, while the uid for root is 0.

If additional information is needed from what I have given here, please let me know and I'll post that info.

Best Answer

Chroot directory should be the parent of the target so in this case /home

ChrootDirectory /home

Related Solutions

Linux – Can’t get Passwordless (SSH provided) SFTP working

First off, the home directories in /etc/passwd should reflect the un-chrooted paths, or you'll run into problems in general. In this case, sshd checks for authorized keys before it chroots, so it needs to find them using an un-chrooted path. That's why your first try doesn't work.

Second thing to note: Under your first setup, when david logs in he starts in /var/chroot-home/david, but he is actually chrooted to /var/chroot-home, meaning if he types cd .. he can see all of the other home dirs (although not their contents, if permissions are correct). This might or might not be a problem for you, but it's a good thing to be aware of.

If the above is fine with you, you can use your first sshd_config, set david's home dir to /var/chroot-home/david in the passwd file, and add the following symlink so that david still starts in his home directory:

cd /var/chroot-home
mkdir var
ln -s .. var/chroot-home

That symbolic link will make sure that you can reach a home directory using the same path whether or not you are in the chroot.

However, if you don't want the clients to see the names of each other's home directories, you need to chroot into the home directory itself, as in your second solution. But as you've seen, sshd doesn't like that (because for various subtle reasons, it's dangerous to give a user write access to the root of a filesystem). Sadly, you're mostly out of luck here. One (kludgy) solution to this is to create a files/ subdirectory in each home directory and give the client write access to that instead.

Another option might be to chroot to /var/chroot-home anyway, and name the home directories differently, e.g. using the user ID number instead of the name.

Linux – Suspicious password login in sshd log

Well, that's a legit sftp-via-ssh connection from your IP address. Either you've been keylogged, or (more likely in my opinion) you forgot that you set up password-based sftp for some application like DreamWeaver which is automatically logging in to your virtual host to keep its file repository up to date.

Related Topic