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?

Felix
  • 101
  • 1
  • 6

1 Answers1

0

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

Felix
  • 101
  • 1
  • 6