Creating SFTP users and jailing to chroot on CentOS – user authentication error

centos6.4sftp

I've got a CentOs release 6.4 with Digital Ocean and would like to successfully create SFTP users and jail them to the user's own chroot home directory but I fear I'm making a mess of this.

I've tried a lot of things, far too many to list here really as most is probably incorrect or won't make much sense but what I feel should be the correct process and what I have tried is:-

Create a group for sftp:-

groupadd sftp

Create a user and set their home directory:-

useradd -d /var/www/vhosts/domain.com dummyuser

Set a password for the user:-

passwd dummyuser

Change the user's group to 'sftp':-

usermod -g sftp dummyuser

Set the user's shell to /bin/false:-

usermod -s /bin/false dummyuser

Edit Subsystem in sshd_config (/etc/ssh/):-

#Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem sftp internal-sftp

Add the following to the bottom of the sshd_config file:-

Match group sftp
    X11Forwarding no
    ChrootDirectory %h
    AllowTcpForwarding no
    ForceCommand internal-sftp

I make sure all the following directories are root:root:-

/var
/var/www
/var/www/vhosts
/var/www/vhosts/domain.com

If I then try to log in to the server via SFTP with the user dummyuser (in WinSCP), I get the following:-

Authentication log (see session log for details):
Using username "dummyuser".

Authentication failed.

All I want to achieve is jailing a user to their home directory. I've also got vsftpd set up and configured. Users could log in fine but would have access to the entire server – I just haven't managed to get jailing to work at all.

Edit

Forgot to mention, I then restarted sshd also:-

service sshd restart

When the error is produced in WinSCP, their help page on this is here.

Log Results

/var/log/secure

I replaced the actual server name with server_name.

 Apr 28 14:20:56 server_name sshd[9944]: Accepted password for dummyuser from 80.194.255.4 port 44402 ssh2
 Apr 28 14:20:56 server_name sshd[9944]: pam_unix(sshd:session): session opened for user dummyuser by (uid=0)
 Apr 28 14:20:56 server_name sshd[9946]: fatal: bad ownership or modes for chroot directory component "/var/www/vhosts/"
 Apr 28 14:20:56 server_name sshd[9944]: pam_unix(sshd:session): session closed for user dummyuser

Best Answer

It's a common pitfall:
All folders up to the chroot home must be owned and only writable by root user.
The folders cannot be group writable - even if the group is root.

Related Solutions

Sftp jail user. error in winscp

Chroot sets / to be that directory. The users home directory is apparently set to /var/www/websites/site1 so when WinSCP logs in, it tries to start in the user's home directory which on the actual system would be /vhosts/wild.domain.com/var/www/websites/site1

Presuming this stefanos user only accesses the system through sftp, it would be safe to set the home directory to /. Otherwise, I think the message should probably go away if you set a default Remote Directory in WinSCP's "Directories" tab.

User can’t SFTP after chroot

Your setup definitely looks good, let's see if we can find out where the problem is.

Check that your openSSH version supports ChrootDirectory:

Support for the ChrootDirectory keyword was added to openSSH version 4.8p1 ( http://www.debian-administration.org/articles/590 ). Check that at least that version is installed:
```
dpkg --list openssh-server
```
[This is probably not the cause, according to http://releases.ubuntu.com/lucid/ubuntu-10.04.4-server-amd64.list openssh-server's version is 5.3p1]
Test SFTP locally.

Type in a terminal on your Ubuntu computer:
```
sftp sam@localhost
```
and see whether you can log in (you must type sam's password when asked). If it works there may be a problem with Cyberduck's configuration.

If you can't log in, try SFTP without chroot.
Test SFTP locally without chroot.

Prefix this:
```
Match group users
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no
```
with # to comment it out, restart sshd (sudo service ssh restart) and then type:
```
sftp sam@localhost
```
Type the password when asked and see whether you can log in. If you can log in troubleshoot the chroot configuration as follows: try step 2 again with command sftp -vvv sam@localhost for verbose output. You can also increase sshd's log level by adding LogLevel VERBOSE to /etc/ssh/sshd_config and restarting sshd. Hopefully you see something obvious in the console or in /var/log/auth.log.

If you can't log in, try SSH.
Test SSH locally.

SFTP requires a working SSH, so change sam's shell to /bin/bash:
```
sudo usermod -s /bin/bash sam
```
and try:
```
ssh sam@localhost
```
Type sam's password when asked. If you can log in try increasing verbosity as explained in 3) to find out what's wrong (sftp -vvv sam@localhost and LogLevel VERBOSE in /etc/ssh/sshd_config). Another possibility is that the shell initialization confuses the sftp client ( http://www.openssh.org/faq.html#2.9 ):
2.9 - sftp/scp fails at connection, but ssh is OK.

sftp and/or scp may fail at connection time if you have shell initialization (.profile, .bashrc, .cshrc, etc) which produces output for non-interactive sessions. This output confuses the sftp/scp client. You can verify if your shell is doing this by executing:
```
ssh yourhost /usr/bin/true
```
If the above command produces any output, then you need to modify your shell initialization.
If you can't log in, try ssh root@localhost. If doesn't work either there's something wrong with sshd on the server. Increase verbosity (LogLevel VERBOSE in /etc/ssh/sshd_config), restart sshd and peruse /var/log/auth.log, the answer is probably there.