User can't SFTP after chroot

Ubuntu 10.04.4 LTS

I'm trying to chroot the user 'sam'. According to all the articles out there this should work, but apparently I'm still doing something wrong.

The user:

sam:x:1005:1006::/home/sam:/bin/false

I changed /etc/ssh/sshd_config like this (at the bottom of the file):

#Subsystem sftp /usr/lib/openssh/sftp-server
# CHROOT JAIL
Subsystem sftp internal-sftp
Match group users
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no

I added sam to the users group:

$groups sam
sam : sam users

I changed the permissions for sam's home folder:

$ ls -la /home/sam
drwxr-xr-x 11 root root  4096 Sep 23 16:12 .
drwxr-xr-x  8 root root  4096 Sep 22 16:29 ..
drwxr-xr-x  2 sam  users 4096 Sep 23 16:10 awstats
drwxr-xr-x  3 sam  users 4096 Sep 23 16:10 etc
...
drwxr-xr-x  2 sam  users 4096 Sep 23 16:10 homes
drwxr-x---  3 sam  users 4096 Sep 23 16:10 public_html

I restarted ssh and now sam can't log in with SFTP. The session is created, but also closed immediately:

Sep 24 12:55:15 ... sshd[9917]: Accepted password for sam from  ...
Sep 24 12:55:15 ... sshd[9917]: pam_unix(sshd:session): session opened for user sam  by (uid=0)
Sep 24 12:55:16 ... sshd[9928]: subsystem request for sftp
Sep 24 12:55:17 ... sshd[9917]: pam_unix(sshd:session): session closed for user sam

Cyberduck says Unexpected end of sftp stream. and other clients give similar errors.

What did I forget / what is going wrong?

Thanks!

Edit

I couldn't get it to work, even after contacting the OpenSSH mailinglist, so I decided to reset my entire server (which was a viable option, fortunately). It's working now.

Solution 1:

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

1. 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]

2. 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.

3. 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.

4. 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.

Solution 2:

Centos 7 - I had the same issue - I tried everything under the sun to diagnose it - eventually I changed the sftp subsystem in '/etc/ssh/sshd_conf', restarted sshd (service sshd restart) and the problem was fixed :

From :

#Subsystem      sftp    /usr/libexec/openssh/sftp-server

To :

Subsystem sftp internal-sftp

I've no idea why two implementation are provided