Enabling chroot jail prevents SFTP from working

Submitted by johnp_ on Sun, 04/08/2018 - 13:42

STR:

  1. Got to Virtual-Server -> Edit Owner Limits
  2. Check "Chroot jail domain Unix user?"
  3. Save

Result in FileZilla:

Error: Received unexpected end-of-file from SFTP server
Error: Could not connect to server

Disabling chroot jail again restores SFTP functionality. The domain owner has "Email, FTP and SSH" allowed login type and SSH runs on a non-standard port.

Could it be that sftp is missing here: https://github.com/virtualmin/virtualmin-gpl/blob/adf910c9ff34e9b4dedce2... ?
Though, adding sftp to jail_sects prior to creating the jail unfortunately doesn't help :(

Status: 
Closed (fixed)

Comments

Submitted by JamieCameron on Sun, 04/08/2018 - 16:58

Yes, most likely some needed files aren't in the jail. Which Linux distribution and version are you running ?

Submitted by JamieCameron on Wed, 04/11/2018 - 19:13

I just tested this on a CentOS 7.4 system, and sftp to the jail'd domain worked fine.

What gets logged to /var/log/messages when you try to SFTP in?

Submitted by johnp_ on Fri, 04/13/2018 - 06:48

Apr 12 11:49:35 host systemd: Created slice User Slice of [user].
Apr 12 11:49:35 host systemd: Starting User Slice of [user].
Apr 12 11:49:35 host systemd: Started Session 7161 of user [user].
Apr 12 11:49:35 host systemd: Starting Session 7161 of user [user].
Apr 12 11:49:36 host systemd-logind: New session 7161 of user [user].
Apr 12 11:49:36 host jk_chrootsh[3356]: now entering jail /home/chroot/15229146301946 for user [user] (4032) with arguments -c /usr/libexec/openssh/sftp-server
Apr 12 11:49:36 host jk_chrootsh[3356]: path /bin/sh is a symlink
Apr 12 11:49:36 host jk_chrootsh[3356]: path /bin/sh is group writable
Apr 12 11:49:36 host jk_chrootsh[3356]: path /bin/sh is writable for others
Apr 12 11:49:36 host systemd-logind: Removed session 7161.
Apr 12 11:49:36 host systemd: Removed slice User Slice of [user].
Apr 12 11:49:36 host systemd: Stopping User Slice of [user].
Apr 12 11:49:40 host sshd[3418]: rexec line 47: Deprecated option RSAAuthentication
Apr 12 11:49:40 host sshd[3418]: rexec line 142: Deprecated option KeyRegenerationInterval
Apr 12 11:49:40 host sshd[3418]: rexec line 143: Deprecated option ServerKeyBits

Submitted by JamieCameron on Fri, 04/13/2018 - 00:27

If you su to the jailed user, does /usr/libexec/openssh/sftp-server exist inside the jail?

Submitted by johnp_ on Fri, 04/13/2018 - 05:04

Weirdly enough it does exist. Although I don't have sftp in jail_sects right now and also don't have your recent git commit. Sth else seems to copy it there.

Submitted by JamieCameron on Sat, 04/14/2018 - 00:04

I can't see from the logs why the sftp connection is failing. Is there anything else logged to /var/log/secure or /var/log/authlog ?

Submitted by johnp_ on Sat, 04/14/2018 - 09:24

Nothing in those logs, but I researched the error a bit and tested sftp locally (sftp -vvv -P [port] user@localhost) and that gave me another error (subsystem request failed on channel 0).

I changed the Subsystem sftp /usr/libexec/openssh/sftp-server to Subsystem sftp internal-sftp per some online recommendations, but while the connection now works, the user can browse outside of the chroot in FileZilla. So I reverted that again, without changing anything else and now the sftp fails differently:

debug1: Sending subsystem: sftp
debug2: channel 0: request subsystem confirm 1
debug3: send packet: type 98
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: subsystem request accepted on channel 0
debug3: receive packet: type 96
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug3: receive packet: type 98
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug3: receive packet: type 98
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug2: channel 0: rcvd eow
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug3: receive packet: type 97
debug2: channel 0: rcvd close
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug3: send packet: type 97
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1)
debug3: send packet: type 1
debug1: fd 0 clearing O_NONBLOCK
debug3: fd 1 is not O_NONBLOCK
Transferred: sent 2032, received 2368 bytes, in 0.3 seconds
Bytes per second: sent 7511.3, received 8753.3
debug1: Exit status 1
Connection closed

I collected strace logs via the method described in the "Debugging a user account without shell in a jail (sftp, cvs, etc.)" section in https://olivier.sessink.nl/jailkit/howtos_debug_jails.html , but am not well versed in how to interpret them, but the sftp-server process ends in:

open("/dev/null", O_RDWR)               = -1 EACCES (Permission denied)
write(2, "Couldn't open /dev/null: Permiss"..., 43) = 43
exit_group(1)                           = ?
+++ exited with 1 +++

I su'ed to the user and checked:

sh-4.2$ ls -alh /dev/null
crw-rw-rw-. 1 root root 1, 3 Mar 19 11:20 /dev/null

And with that I'm currently at the end of what I can find out...
As this problem doesn't seem to come from Virtualmin and you can't reproduce it I'm inclined to close this bug.

Also, regarding https://github.com/virtualmin/virtualmin-gpl/commit/72787e67ce8ee510bda4ba367f6c0d6eb8afcdff, turns out that netutils includessection sftp in jk_init.ini already, so that's where it came from.

Submitted by johnp_ on Sat, 04/14/2018 - 10:02

Ok, so removing and recreating the null-file didn't help(mknod -m 666 /home/chroot/.../dev/null 1 3).

I instead removed /dev/* from the chroot and mounted the devtmpfs mount -t devtmpfs devtmpfs /home/chroot/.../dev and now everything works. The only bad side-effect is that now there's a lot of stuff that doesn't need to be in the chroot's dev...

Submitted by johnp_ on Sat, 04/14/2018 - 10:22

And I may have found the underlying problem:

For security purposes I created the server with /home mounted with nodev. Now, that the chroot is created under /home/chroot/... in the same mount, devices don't work there. I haven't tried removing nodev yet, and unfortunately another user says it doesn't help him: https://lists.nongnu.org/archive/html/jailkit-users/2014-02/msg00030.html

I'll try that later. Probably will have to reboot and re-create the chroot...

Submitted by johnp_ on Sat, 04/14/2018 - 10:47

Disabled all domain owners jails, rebooted, rm -rfed /home/chroot/..., re-enabled the jails and now everything works as expected!

Submitted by JamieCameron on Sat, 04/14/2018 - 15:34

Mounting nodev would certainly explain it