Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
It would be best if you put the resolution as an answer and accepted it, to make what happened clear to any future visitors. – HopelessN00b Oct 9 '12 at 4:13
If that's the prefered way at serverfault, I'll add it. – Dauntless Oct 9 '12 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 '14 at 21:03

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 ( ). Check that at least that version is installed:

    dpkg --list openssh-server

    [This is probably not the cause, according to 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 ( ):

    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.

share|improve this answer
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 . 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 '12 at 11:37
Can you post /var/log/auth.log? – jaume Sep 27 '12 at 13:07
And what is your openssh-server version? (dpkg --list openssh-server) – jaume Sep 27 '12 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 '12 at 14:56
up vote 1 down vote accepted

Even though jaume's answer is verry 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 fortunatelly. It's working perfectly now.

share|improve this answer
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 '12 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 '14 at 19:34

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.