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:


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

#Subsystem sftp /usr/lib/openssh/sftp-server
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?



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.

  • It would be best if you put the resolution as an answer and accepted it, to make what happened clear to any future visitors. Oct 9, 2012 at 4:13
  • If that's the prefered way at serverfault, I'll add it.
    – Dauntless
    Oct 9, 2012 at 8:12
  • the problem is sam's home is supposed to be /home/sam, but under the chroot there isn't any /home/sam, so sftp can't put the user into its home upon login and exits (without a good error message).
    – artm
    Oct 10, 2014 at 21:03

5 Answers 5


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.

  • Thanks for this guide. I'm able to log in without chroot, but the -vvv isn't really giving me much. I've put the output on pastebin.com/ . Does anyone else see anything weird? I created a new 'test' user and followed all the steps again, but the result is exactly the same (sftp works, but not with chroot)
    – Dauntless
    Sep 27, 2012 at 11:37
  • Can you post /var/log/auth.log?
    – jaume
    Sep 27, 2012 at 13:07
  • And what is your openssh-server version? (dpkg --list openssh-server)
    – jaume
    Sep 27, 2012 at 13:57
  • My version is 1:5.3p1-3ubuntu7. I've posted /var/log/auth.log here (log level is VERBOSE in ./etc/ssh/sshd_config)
    – Dauntless
    Sep 27, 2012 at 14:56

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

  • 1
    Hello, it wasn't the same issue as OP alerady had "Subsystem sftp internal-sftp" enabled.
    – bgtvfr
    Oct 4, 2018 at 12:06
  • In fact only the internal-sftp allows chroot. The external sftp server has more options, though.
    – wazoox
    Oct 4, 2018 at 15:05
  • Thanks @wazoox - I wasn't aware of the distinction between the two.
    – bryan hunt
    Oct 5, 2018 at 13:05

I had the same issue, resolved by setting the chroot-dir to owner root and group root.

chown root:root chroot-dir

  • This worked for me as well (CentOS), BUT only in conjunction with changing the permissions on the chroot-dir: chmod 555 <chroot-dir> Any other permission combination I tried netted the error and broken connection.
    – Jesse Q
    May 10, 2019 at 16:45

Even though jaume's answer is very nice, it couldn't help me in the end. I tried the OpenSSH mailinglist, but no luck there. I ended up resetting my entire server, which I could still do fortunately. It's working perfectly now.

  • I guess we will never find out where exactly the problem was, I couldn't it figure out despite all your feedback, great you got it running.
    – jaume
    Oct 10, 2012 at 8:21
  • I have the exact same issue now. Trying to find out why its happening. Dont want to give up and reset the server just yet..
    – Neel
    Oct 26, 2014 at 19:34
  • 3
    Well this accepted answer is useless for the SF community.
    – hookenz
    Aug 28, 2018 at 23:03
  1. For "connection refused" error check the "UsePAM yes" setting in sshd_config. It must be BEFORE "Subsystem sftp"

  2. For authentication problems check that EACH directory in chroot-path owned by root and has permissions 755 or less.

Example: ChrootDirectory /var/www/data

You have to check permissions and owner for: /var, /var/www, /var/www/data

  1. For weird problems like "connection is closed after authentication" try to update or change SFTP-server.

apt-get install openssh-server

"Subsystem sftp internal-sftp" <-> "Subsystem sftp /usr/lib/openssh/sftp-server" (switch from the type with your problems to another one)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .