Ssh – Setting up a chroot sftp on debian server

chrootdebiansftpssh

I'm trying to allow a user "user" to access my server by either sftp or ssh. I want to jail them into a directory with chroot. I read the instructions here however it does not work.
I did the following:

useradd user
modify /etc/ssh/sshd_config and added

Match User user

ForceCommand internal-sftp

ChrootDirectory /home/duke/aa/smart
to the bottom of the file
changed the subsystem line to Subsystem sftp internal-sftp
restarted sshd with /etc/init.d/ssh restart
logged in with ssh as user "user" with PuTTY

Putty says "Server unexpectly closed the connection".

Why is this and how can it be fixed?

EDIT

Following the suggestions below, I've made the bottom of sshd_config look like:

Match User user
   ChrootDirectory /tmp

yet no change. I do get a password OK but I cannot connect via ssh nor sftp. What gives?

Best Answer

The directory that you set as your chroot must be owned by root and have 755 permissions.

This is what I use for my setup

Match user sftpuser
 ChrootDirectory /home/sftpuser
    AllowTCPForwarding no
    X11Forwarding no
    ForceCommand internal-sftp

in /home

drwxr-xr-x   5 root    users 4096 Jan 29 10:31 sftpuser

in /home/sftpuser

drwx------ 2 sftpuser users 4096 Jan 29 10:52 sftpuser

This chroot's them to the /home/sftpuser directory, but since they have no permission to write into it I create the second sftpuser directory for them to write to.

Related Solutions

Ssh – SFTP to chroot and SSH to manage system in one config

You could use Match in a reverse way. Chroot by default and then negate the directive if connecting from the internal network.

ChrootDirectory /chroot/somedir
Match Address 10.0.0.0/24
    ChrootDirectory none

However you should consider the implications of placing security decisions upon the networks. Including the possibility of an authenticated user creating a new session over loopback, to bypass such policies. Generally it would be safer to define User and Group if possible.

(edit: typed before reading properly)

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.

Best Answer

Related Solutions

Ssh – SFTP to chroot and SSH to manage system in one config

User can’t SFTP after chroot

Related Topic