SFTP Jail Chroot Causing Errors

Set loglevel to debug in your sshd config file on the server, restart ssh then connect again, it'll output details of why it failed into your ssh logs (probably /var/log/auth.log) then post the errors.

Hi obs,

Thanks for replying, here is the log when I try to connect with the problematic account.

Mar 17 08:45:08 localhost sshd[18027]: Connection from #######[MY IP] port ####

Mar 17 08:45:08 localhost sshd[18026]: debug1: Client protocol version 2.0; client software version libssh-0.1

Mar 17 08:45:08 localhost sshd[18026]: debug1: no match: libssh-0.1

Mar 17 08:45:08 localhost sshd[18026]: debug1: Enabling compatibility mode for protocol 2.0

Mar 17 08:45:08 localhost sshd[18026]: debug1: Local version string SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu7

Mar 17 08:45:08 localhost sshd[18027]: debug1: Client protocol version 2.0; client software version PuTTYLocal:Nov292012_23:00:29

Mar 17 08:45:08 localhost sshd[18027]: debug1: no match: PuTTYLocal:Nov292012_23:00:29

Mar 17 08:45:08 localhost sshd[18027]: debug1: Enabling compatibility mode for protocol 2.0

Mar 17 08:45:08 localhost sshd[18027]: debug1: Local version string SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu7

I did do some more research today and I think it may be a permissions problem (i.e. root has to own all directories above and below??), so if you have a solution for me where my CMS user (www-data) and root can both be owners and allow an SFTP jail to work please help me out… :)

Any other solutions other than a chroot and jail??? Maybe I am looking at this the wrong way…

Sorry, I realised that each request has an ID (am i right??) so here is the log of all sshd[18027] requests:

Mar 17 08:45:08 localhost sshd[18027]: debug1: rexec start in 5 out 5 newsock 5 pipe 8 sock 9

Mar 17 08:45:08 localhost sshd[18027]: debug1: inetd sockets after dupping: 3, 3

Mar 17 08:45:08 localhost sshd[18027]: Connection from ###[MY IP]### port ###

Mar 17 08:45:08 localhost sshd[18027]: debug1: Client protocol version 2.0; client software version PuTTYLocal:Nov292012_23:00:29

Mar 17 08:45:08 localhost sshd[18027]: debug1: no match: PuTTYLocal:Nov292012_23:00:29

Mar 17 08:45:08 localhost sshd[18027]: debug1: Enabling compatibility mode for protocol 2.0

Mar 17 08:45:08 localhost sshd[18027]: debug1: Local version string SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu7

Mar 17 08:45:10 localhost sshd[18027]: debug1: PAM: initializing for "root"

Mar 17 08:45:10 localhost sshd[18027]: debug1: PAM: setting PAM_RHOST to "####.com.au"

Mar 17 08:45:10 localhost sshd[18027]: debug1: PAM: setting PAM_TTY to "ssh"

Mar 17 08:45:10 localhost sshd[18027]: Failed none for root from ###[MY IP]### port 49355 ssh2

Mar 17 08:45:10 localhost sshd[18027]: debug1: PAM: password authentication accepted for root

Mar 17 08:45:10 localhost sshd[18027]: debug1: dopamaccount: called

Mar 17 08:45:10 localhost sshd[18027]: Accepted password for root from ###[MY IP]### ###[MY PORT]### ssh2

Mar 17 08:45:10 localhost sshd[18027]: debug1: monitorchildpreauth: root has been authenticated by privileged process

Mar 17 08:45:10 localhost sshd[18027]: debug1: PAM: establishing credentials

Mar 17 08:45:10 localhost sshd[18027]: pam_unix(sshd:session): session opened for user root by (uid=0)

Mar 17 08:45:10 localhost sshd[18027]: debug1: Entering interactive session for SSH2.

Mar 17 08:45:10 localhost sshd[18027]: debug1: serverinitdispatch_20

Mar 17 08:45:11 localhost sshd[18027]: debug1: serverinputchannel_open: ctype session rchan 256 win 2147483647 max 16384

Mar 17 08:45:11 localhost sshd[18027]: debug1: inputsessionrequest

Mar 17 08:45:11 localhost sshd[18027]: debug1: channel 0: new [server-session]

Mar 17 08:45:11 localhost sshd[18027]: debug1: session_new: session 0

Mar 17 08:45:11 localhost sshd[18027]: debug1: session_open: channel 0

Mar 17 08:45:11 localhost sshd[18027]: debug1: session_open: session 0: link with channel 0

Mar 17 08:45:11 localhost sshd[18027]: debug1: serverinputchannel_open: confirm session

Mar 17 08:45:11 localhost sshd[18027]: debug1: serverinputchannel_req: channel 0 request simple@putty.projects.tartarus.org reply 0

Mar 17 08:45:11 localhost sshd[18027]: debug1: sessionbychannel: session 0 channel 0

Mar 17 08:45:11 localhost sshd[18027]: debug1: sessioninputchannel_req: session 0 req simple@putty.projects.tartarus.org

Mar 17 08:45:11 localhost sshd[18027]: debug1: serverinputchannel_req: channel 0 request subsystem reply 1

Mar 17 08:45:11 localhost sshd[18027]: debug1: sessionbychannel: session 0 channel 0

Mar 17 08:45:11 localhost sshd[18027]: debug1: sessioninputchannel_req: session 0 req subsystem

Mar 17 08:45:11 localhost sshd[18027]: subsystem request for sftp

Mar 17 08:45:11 localhost sshd[18027]: debug1: subsystem: exec() internal-sftp

18027 is the pid of the sshd process.

That log shows you're logging in as root, I assume you're not trying to jail the root user?

Root has to own the chrooted directory so say you had the structure

/srv/chroots/fred/webstuff

Fred's web files would be in web stuff and /srv/chroot/fred would be owned by root and you'd jail them to that path, they can write to the webstuff directory but not the fred directory.

Sorry here is the log for the user I am trying to chroot, I think it basically says what I think it says - that my ownership settings are incorrect…

Mar 17 09:48:05 localhost sshd[18713]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8

Mar 17 09:48:05 localhost sshd[18713]: debug1: inetd sockets after dupping: 3, 3

Mar 17 09:48:05 localhost sshd[18713]: Connection from ###[MY IP]### port ###[MY PORT]###

Mar 17 09:48:05 localhost sshd[18713]: debug1: Client protocol version 2.0; client software version PuTTYLocal:Nov292012_23:00:29

Mar 17 09:48:05 localhost sshd[18713]: debug1: no match: PuTTYLocal:Nov292012_23:00:29

Mar 17 09:48:05 localhost sshd[18713]: debug1: Enabling compatibility mode for protocol 2.0

Mar 17 09:48:05 localhost sshd[18713]: debug1: Local version string SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu7

Mar 17 09:48:07 localhost sshd[18713]: debug1: user zanity matched 'User zanity' at line 89

Mar 17 09:48:07 localhost sshd[18713]: debug1: PAM: initializing for "zanity"

Mar 17 09:48:07 localhost sshd[18713]: debug1: PAM: setting PAM_RHOST to "###ME###"

Mar 17 09:48:07 localhost sshd[18713]: debug1: PAM: setting PAM_TTY to "ssh"

Mar 17 09:48:07 localhost sshd[18713]: Failed none for zanity from ###[MY IP]### port ###[MY PORT]### ssh2

Mar 17 09:48:07 localhost sshd[18713]: debug1: PAM: password authentication accepted for zanity

Mar 17 09:48:07 localhost sshd[18713]: debug1: dopamaccount: called

Mar 17 09:48:07 localhost sshd[18713]: Accepted password for zanity from ###[MY IP]### port ###[MY PORT]### ssh2

Mar 17 09:48:07 localhost sshd[18713]: debug1: monitorchildpreauth: zanity has been authenticated by privileged process

Mar 17 09:48:07 localhost sshd[18713]: debug1: PAM: establishing credentials

Mar 17 09:48:07 localhost sshd[18713]: pam_unix(sshd:session): session opened for user zanity by (uid=0)

Mar 17 09:48:07 localhost sshd[18713]: User child is on pid 18771

Mar 17 09:48:07 localhost sshd[18771]: debug1: SELinux support disabled

Mar 17 09:48:07 localhost sshd[18771]: debug1: PAM: establishing credentials

Mar 17 09:48:07 localhost sshd[18771]: fatal: bad ownership or modes for chroot directory "###DIRECTORY###"

Mar 17 09:48:07 localhost sshd[18771]: debug1: do_cleanup

Mar 17 09:48:07 localhost sshd[18713]: debug1: do_cleanup

Mar 17 09:48:07 localhost sshd[18713]: debug1: PAM: cleanup

Mar 17 09:48:07 localhost sshd[18713]: debug1: PAM: closing session

Mar 17 09:48:07 localhost sshd[18713]: pam_unix(sshd:session): session closed for user zanity

Mar 17 09:48:07 localhost sshd[18713]: debug1: PAM: deleting credentials

> However I need the owner of the chroot directory to be a group not a user

This is simply not possible.

The owner of the chroot top directory MUST be root, and the permissions MUST be restrictive. Otherwise SSH will refuse to work with it, as you can see.

What you should do is to make the chroot top directory to be owned by root and 755 or 750 by permissions, and INSIDE it make a directory writeable by the group you want.

When a restricted user connects via sftp it enters the top directory (to which it cannot write), and sees a subdirectory in it, to which it can write, with all website files inside.

I usually name these subdirectories after website names, as a single sftp user may be hosting more than one site.

So, for example

/srv/user01 <- this is the sftp chroot for user "user01", owned by root, not writeable by user01

/srv/user01/example.com <- this is directory with files for example.com, writeable by user01

/srv/user01/example.net <- this is directory with files for example.net, writeable by user01

and so on.

Of course you can use same chroot directory for multiple SFTP users - but they still will be able to write only to subdirectories.

Also, in that case, you may look into ACLs so there won't be weird permission issues when different users create files in the shared directory.

I do the same, but sometimes if docroot is in, say, /var/www, i use bind mount (symlinks won't work)

mkdir -p /srv/user1/www

add to /etc/fstab

/var/www /srv/user1/www bind bind 0 0

then

mount /srv/user1/www

and

chown -R user1: /srv/user1/www