0

I'm running a Debian Stretch x86_64 server, with OpenSSH_7.4p1 Debian-10+deb9u3, OpenSSL 1.0.2l 25 May 2017.

I want to use chroots in combination with OpenSSH server's internal SFTP system. My current setup seems to work, unfortunately excluding the chroot.

I set up an OpenSSH server analogous to this question on serverfault on a Debian Stretch machine, with the adaptation explained in the question's answer:

root@server # grep _NAME /etc/os-release | cut -d= -f2
"Debian GNU/Linux 9 (stretch)"

root@server # tail -9 /etc/ssh/sshd_config
# Use internal sftp server
Subsystem sftp internal-sftp

Match group sftponly
     AuthorizedKeysFile /etc/ssh/authorized_keys/%u
     ChrootDirectory /srv/sftp/%u
     AllowTcpForwarding no
     PermitTunnel no
     ForceCommand internal-sftp

root@server # stat -c "%a %A" /srv/sftp/sftpuser
700 drwx------

Trying to mount the directory via sshfs fails, when using the following settings (notice remote path /):

user@client $ sshfs sftpuser@server.com:/ /mnt -o ssh_command=ssh\ -vvv,sshfs_debug,debug
[...]
debug1: Authentication succeeded (publickey).
Authenticated to server.com ([1.2.3.4]:22).
debug2: fd 4 setting O_NONBLOCK
debug3: fd 5 is O_NONBLOCK
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: send packet: type 1
packet_write_wait: Connection to 1.2.3.4 port 22: Broken pipe
read: Connection reset by peer

It works however, when I comment out the ChrootDirectory line in /etc/ssh/sshd_config and reload the system service sshd. Afterwards connecting and accessing the directory has no issues, with the fundamental drawback of not using a chroot, which I want though (notice remote path /srv/sftp/sftpuser:

user@client $ sshfs sftpuser@server.com:/srv/sftp/sftpuser /mnt; echo $?
0

What do I have to change to make the chroot work?

0

The problem was the /srv/sftp/sftpuser directory's permissions, as already explained in this answer on serverfault.

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.