У меня есть настройки только для пользователей sftp:
Match Group sftponly
ChrootDirectory %h
ForceCommand internal-sftp
AllowTcpForwarding no
Я получаю следующее сообщение в моем secure.log:
fatal: bad ownership or modes for chroot directory
С ключевым словом match уходит кое-что с безопасностью ... каталоги должны принадлежать root, а каталоги должны быть chmod 755 (drwxr-xr-x). Таким образом, для пользователя становится невозможным иметь права на запись в папки, если он доступен только для записи пользователю root и установлен как недоступный для записи для групп из-за безопасности ssh.
Кто-то знает о хорошей работе вокруг?
chroot
пользователь edChrootDirectory
? Могут ли они получить к нему доступ?Ответы:
У меня такие же настройки на нашем сервере. Мы используем тот же конфиг SSHD. Домашние директории пользователей принадлежат корню и в них есть папки
documents
иpublic_html
принадлежат соответствующим пользователям. Затем пользователи входят в систему, используя SFTP, и записывают в эти папки (а не прямо в дом). Поскольку SSH для них не разрешен, он отлично работает. Вы можете настроить, какие каталоги будут создаваться для новых пользователей, в / etc / skel / (по крайней мере, в openSUSE, я не очень знаком с другими дистрибутивами).Другой возможностью может быть ACL ( документация openSUSE ) - он может добавить разрешение на запись для соответствующего пользователя для его домашнего каталога.
источник
packet_write_wait: Connection to 10.0.0.42 port 22: Broken pipe
Недавно мы нашли обходной путь, который выглядит так:
/ И т.д. / SSH / sshd_config:
права доступа к каталогу:
Теперь
/home
удовлетворяет требованиямChrootDirectory
и не может быть перечислено ограниченными пользователями, ноsftponly
пользователи не смогут войти в систему, если их домашние каталоги настроены как обычно (/home/$LOGNAME
): в среде chrooted их домашние каталоги находятся не внутри,/home
а непосредственно под root (/
).Обходной путь 1
Установите дома пользователей с ограниченным доступом так, как они выглядят в chroot:
предостережение 1
Если кто-либо из неограниченных пользователей или какой-либо сценарий администрирования использует расширение тильды bash,
~username
оно будет расширяться до/username
сих пор, а это не то, что подразумевается.Также администратор, который создает
sftponly
пользователей, должен помнить, чтобы использовать нестандартный дом. Решается с помощью сценария. Который админ должен помнить, чтобы использовать.Обходной путь 2
Это альтернатива предыдущей, которую мы в итоге использовали:
То есть создайте символическую ссылку внутри
/home
своего собственного dirname. Теперь под chroot/home/username
указывает на тот же каталог, что и без chroot. Для пользователя с ограниченными правами, вошедшего в систему с помощью sftp, это будет выглядеть как/username
. Этот каталог доступен для записи его владельцу (пользователю с ограниченными правами). Пользователь с ограниченными правами не может перечислить свои родительские или домашние каталоги ни одного из братьев по имени.Единственное, что особенного в
sftponly
пользователе - это его участие вsftponly
группе. Нам было легче иметь дело, чем обходной путь 1.пещеры 2
/home/home
/home
иерархию и следуют по символическим ссылкам.источник
Вам необходимо создать структуру внутри домашнего каталога пользователя, например, в директориях in и out. Эти каталоги должны принадлежать пользователю, и там он сможет размещать и получать файлы.
источник
Вы должны создать следующую структуру каталогов:
/ Главная / пользователь
/ home / user / home / user <- реальный каталог, к которому у пользователя будет доступ
По выбору:
/home/user/.ssh/authorized_keys <- если вы хотите пройти аутентификацию с открытым ключом
источник
В ответе на раздел «Права доступа к каталогу» в ответе от @artm (который я только что проверил) .. Я нашел:
Это не позволяет соединению sftp работать в Ubuntu с разрешениями на выполнение только для всего, т.е. 111.
Я нашел это:
Работает с подключением к sftp с разрешениями «Чтение» и «Выполнение», т. Е. 555. Не уверен, отличаются ли Debian от других версий, но это то, что работает на моих установках Ubuntu.
источник
Когда вы создаете пользователя, вы должны установить владельца, используя
chown
для каждого директора для каждого пользователя.Например:
источник