Ssh – Chrooted SFTP user write permissions

centoslinuxsftpssh

I have a setup with sftp only users:

Match Group sftponly
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no

I get the following message in my secure.log:

fatal: bad ownership or modes for chroot directory

With the match keyword there comes some security stuff with it… the directories need to be owned by root, and the directories need to be chmod 755 (drwxr-xr-x). So it makes it impossible for a user to have write permissions to the folders, if it is only writable to the user root and set to ben non-writable for groups due to ssh's security.

Someone know about a good work around?

Best Answer

I have same settings on our server. We use same config of SSHD. Users' home directories are owned by root and within them there are folders documents and public_html owned by respective users. Users then login using SFTP and write into those folders (not directly into home). As SSH is not allowed for them, it perfectly works. You can adjust which directories will be created for new users in /etc/skel/ (at least in openSUSE, I'm not so familiar with other distros).

Another possibility would be ACL (openSUSE documentation) - it can add write permission for respective user for his home directory.

Related Solutions

SSH with chroot and only working “sftp”, “rsync” (both)

First of all ChrootDirectory must be owned by root and not writable by other users. Thus /var/shared in your case cannot be ChrootDirectory value.

I would recommend to create a directory which would be writable by root only and make /var/shared accessible inside this dir either via Linux bind-mounting or some kind of symlinks workarounds.

If you need restrict sftp or rsync, you need to check SSH_ORIGINAL_COMMAND environment variable on the server with help of a "wrapper" enforced either via ForceCommand or via command in ssh public key, this variable is populated after user is authenticated and contains info what kind of connection clients is going to establish. For sftp it would have sftp-server inside, for rsync it would have rsync, for just ssh session it would have, IIRC, the variable empty, for ssh date it would be date. SSH_ORIGINAL_COMMAND is run under authenticated user on the server!

This could be your start of the wrapper:

#!/usr/bin/env bash

set -eu
set -o pipefail

[[ -z "${SSH_ORIGINAL_COMMAND:-}" ]] && exit 1

case "${SSH_ORIGINAL_COMMAND}" in
    "/usr/libexec/openssh/sftp-server")
        exec /usr/libexec/openssh/sftp-server
        ;;
    "rsync --server"*)
        exec ${SSH_ORIGINAL_COMMAND}
        ;;
    *)
        exit 1
        ;;
esac

As you can see, ssh -v gives you info about what command would be executed by the server. Thus you can change /tmp to something else in your wrapper as well.

$ rsync -a -e "ssh -v" bin localhost:/tmp/ 2>&1 | grep '^debug.*Sending command:'
debug1: Sending command: rsync --server -logDtpre.iLsfxC . /tmp/

Best Answer

Related Solutions

SSH with chroot and only working “sftp”, “rsync” (both)

Related Question