Hi all,

I am fairly new to all of this so bare with me.

Basically I am trying to setup an SFTP jail for a new user on my Linode. However I need the owner of the chroot directory to be a group not a user (running a CMS on the server and it uses the user "www-data" to edit the files in this directory). This bit I have done with some help from Linode support.

However when I try to just chroot my user using sshd_config, I just get this error in Filezilla:
Error: Connection refused
Error:Could not connect to server

Here is my sshd_config file setup:


Subsystem sftp internal-sftp

Match user zanity
ChrootDirectory /srv/www/domains/mydomain.com.au
ForceCommand internal-sftp


Any help would be greatly appreciated !

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.

_________________
Paid support
How to ask for help
1. Give details of your problem
2. Post any errors
3. Post relevant logs.
4. Don't hide details i.e. your domain, it just makes things harder
5. Be polite or you'll be eaten by a grue

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 PuTTY_Local:_Nov_29_2012_23:00:29
Mar 17 08:45:08 localhost sshd[18027]: debug1: no match: PuTTY_Local:_Nov_29_2012_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 PuTTY_Local:_Nov_29_2012_23:00:29
Mar 17 08:45:08 localhost sshd[18027]: debug1: no match: PuTTY_Local:_Nov_29_2012_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: do_pam_account: 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: monitor_child_preauth: 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: server_init_dispatch_20
Mar 17 08:45:11 localhost sshd[18027]: debug1: server_input_channel_open: ctype session rchan 256 win 2147483647 max 16384
Mar 17 08:45:11 localhost sshd[18027]: debug1: input_session_request
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: server_input_channel_open: confirm session
Mar 17 08:45:11 localhost sshd[18027]: debug1: server_input_channel_req: channel 0 request simple@putty.projects.tartarus.org reply 0
Mar 17 08:45:11 localhost sshd[18027]: debug1: session_by_channel: session 0 channel 0
Mar 17 08:45:11 localhost sshd[18027]: debug1: session_input_channel_req: session 0 req simple@putty.projects.tartarus.org
Mar 17 08:45:11 localhost sshd[18027]: debug1: server_input_channel_req: channel 0 request subsystem reply 1
Mar 17 08:45:11 localhost sshd[18027]: debug1: session_by_channel: session 0 channel 0
Mar 17 08:45:11 localhost sshd[18027]: debug1: session_input_channel_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.

_________________
Paid support
How to ask for help
1. Give details of your problem
2. Post any errors
3. Post relevant logs.
4. Don't hide details i.e. your domain, it just makes things harder
5. Be polite or you'll be eaten by a grue

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 PuTTY_Local:_Nov_29_2012_23:00:29
Mar 17 09:48:05 localhost sshd[18713]: debug1: no match: PuTTY_Local:_Nov_29_2012_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: do_pam_account: 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: monitor_child_preauth: 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

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.

_________________
rsk, providing useless advice on the Internet since 2005.

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