3

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.

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

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 '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
1

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.

  • 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
  • Well this accepted answer is useless for the SF community. – Matt Aug 28 '18 at 23:03
1

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 at 16:45
0

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 '18 at 12:06
  • In fact only the internal-sftp allows chroot. The external sftp server has more options, though. – wazoox Oct 4 '18 at 15:05
  • Thanks @wazoox - I wasn't aware of the distinction between the two. – bryan hunt Oct 5 '18 at 13:05
-1
  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)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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