Chroot problem | TurnKey GNU/Linux

Hi,

It has been well over 10 years since I've used a linux server and need a simple SFTP server so I downloaded Core and thought I'd give it a try. Installed in a VMware environment and have the server installed.

I want to have a separate disk as a repository for the users and have successfully created that finally. I called it 'data'.

I created a new user and group of the same name and after some fiddling figured out how to get the home directory on this new data disk. Escentially I created a 'data' mounting point and have a 'user1' directory on it which when I log into the server as 'user1' I am there by default and I can create and modify files.

I edited the /etc/ssh/sshd_config file and added the following:

Subsystem sftp internal-sftp

Match Group user1

ChrootDirectory /data

AllowTCPForwarding no

X11Forwarding no

ForceCommand internal-sftp

This seems to work except when I SFTP into it as user1 I am at the root of /data directory and I cannot send files to it. So I modified the sshd_config file to add /user to the ChrootDirectory statement.

Now I get an error: Using username: user1

Authentication failed.

Any suggestions? What did I miss?

As root I also set chmod 770 /data/user1 thinking it was a user rights issue.

Thanks in advance,

Linn

Replies (3)

Chroot directory in ssh_config must be owned by root

Reply 1 2017-12-15

I know it seems a little unintuitive, but that is expected behaviour. I'll give specific detail below, but FWIW, there is a page in our docs that covers this. FYI the docs are actually a wiki, so please feel free to edit them if there is anything that isn't quite right or could be more clear.

To use your example, /data will need to be owned by root (but readable by your user) and inside you will need a sub dir, owned by your user and named after them. E.g. /data/user1.

To avoid user confusion (dropping into a dir that they can read but not write to), you can (re)set the chrooted user's home as /user1. That works because /data is the root (/) of the chroot, therefore within the chroot, /data/user1 appears as /user1.

Hope that helps. :)

Oops, I forgot to mention, you'll need to change the ssh_config and set the home as /data/%u (which will resolve to /data/user1).

Still not getting it

Reply 2 2017-12-15

Hi,

Thanks for the quick response. Here is where I'm at...

If I look at /etc/passwd I see:

user1:x:2000:2000:user1 User:/data/user1:/bin/bash

I followed the directions in the wiki you referenced as follows:

chown root:root /data/user1

mkdir /data/user1/files

chown user1:user1 /data/user1/files

chmod 700 /data/user1/files user1

usermod -d /files user1

So ls -l /data shows:

drwxrwx--- 5 root root 4096 Dec 15 14:10 user1

ls -l /data/user1

drwx------ 2 user1 user1 4096 Dec 15 14:10 files

And I changed the sshd_config:

ChrootDirectory /data/%u

And restarted the SSH service.

But I still get a network error when connecting via WinSCP Portable, which says:

Network error: Software caused connection abort

Authentication log (see session log for details):

Using username "user1".

Authentication failed.

What am I missing?

Thanks,

Linn

Only SFTP is supported, not SCP!

Reply 3 2017-12-18

Whilst SCP and SFTP are similar, they aren't the same and it seems that SCP is not supported in combo with a chroot jailed user. I'm not sure if WinSCP also supports SFTP, or if you'll need to try a different client?

FWIW I just tested on a v14.2 LAMP that I had handy. I haven't set any of this up previously and here's what I did (copy pasted from the wiki):

root@lamp ~# groupadd sftp_users
root@lamp ~# NEW_USER="user1"
root@lamp ~# useradd -G sftp_users -s /sbin/nologin $NEW_USER
root@lamp ~# passwd $NEW_USER
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
root@lamp ~# mkdir -p /home/$NEW_USER/files
root@lamp ~# chown root:root /home/$NEW_USER
root@lamp ~# chown $NEW_USER:$NEW_USER /home/$NEW_USER/files
root@lamp ~# chmod 700 /home/$NEW_USER/files
root@lamp ~# usermod -d /files $NEW_USER
root@lamp ~# CONF=/etc/ssh/sshd_config
root@lamp ~# SEARCH="Subsystem sftp \/usr\/lib\/openssh\/sftp-server"
root@lamp ~# NEW_LINE="Subsystem sftp internal-sftp"
root@lamp ~#
root@lamp ~# sed -i "/^$SEARCH/ s|^|#|" $CONF
root@lamp ~# sed -i "/$NEW_LINE/d" $CONF
root@lamp ~# sed -i "/$SEARCH/a\\$NEW_LINE" $CONF
root@lamp ~# if ! grep "Match Group sftp_users" $CONF >/dev/null; then
>     cat >> $CONF <<EOF
>
> Match Group sftp_users
>   X11Forwarding no
>   AllowTcpForwarding no
>   ChrootDirectory /home/%u
>   ForceCommand internal-sftp
> EOF
> fi
root@lamp ~# service ssh restart
root@lamp ~# touch /home/$NEW_USER/files/test

Then in another terminal, it "just works"!:

user@ninjux ~$ sftp user1@192.168.1.74
user1@192.168.1.74's password:
Connected to 192.168.1.74.
sftp> ls
test
sftp> exit