Я использую сервер Debian Stretch x86_64 с OpenSSH_7.4p1 Debian-10 + deb9u3, OpenSSL 1.0.2l 25 мая 2017 года.
Я хочу использовать chroot в сочетании с внутренней системой SFTP сервера OpenSSH. Моя текущая настройка, похоже, работает, к сожалению, за исключением chroot.
Я настроил сервер OpenSSH, аналогичный этот вопрос при сбое сервера на машине Debian Stretch, с адаптацией, описанной в вопрос ответ:
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------
Попытка смонтировать каталог через sshfs
не работает, при использовании следующих настроек (обратите внимание на удаленный путь /
):
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
Однако это работает, когда я комментирую ChrootDirectory
линия в /etc/ssh/sshd_config
и перезагрузите системный сервис sshd
. Впоследствии подключение и доступ к каталогу не вызывает проблем, с фундаментальным недостатком - не использовать chroot, который я хочу, хотя (обратите внимание на удаленный путь /srv/sftp/sftpuser
:
user@client $ sshfs sftpuser@server.com:/srv/sftp/sftpuser /mnt; echo $?
0
Что мне нужно изменить, чтобы chroot заработал?
Проблема заключалась в /srv/sftp/sftpuser
разрешения каталога, как уже объяснялось в этот ответ на serverfault.