Плохое владение или режимы для компонента каталога chroot

Я создал пользователя MY_USER. Установите его домашний каталог в /var/www/RESTRICTED_DIR, по которому он должен быть ограничен. Затем я отредактировал sshd_config и установил:

Match user MY_USER
  ChrootDirectory /var/www/RESTRICTED_DIR

Затем я перезапустил SSH. Сделал MY_USER владельцем (и владельцем группы) RESTRICTED_DIR и изменил его значение на 755. Я получаю

Accepted password for MY_USER
session opened for user MY_USER by (uid=0)
fatal: bad ownership or modes for chroot directory component "/var/www/RESTRICTED_DIR"
pam_unix(sshd:session): session closed for user MY_USER

Если я удалил 2 строки из sshd_config, пользователь сможет успешно войти в систему. Конечно, он может получить доступ ко всему серверу. В чем проблема? Я даже пытался прикрепить RESTRICTED_DIR к руту (когда я где-то читал, что кто-то решил эту проблему, делая это). Неудачно..

Источник

5 ответов

Решение

Из man страница:

ChrootDirectory
Указывает путь к каталогу для chroot(2) после аутентификации. Все компоненты пути должны быть корневыми каталогами, которые не доступны для записи любому другому пользователю или группе. После chroot sshd(8) меняет рабочий каталог на домашний каталог пользователя.

Я предполагаю, что один или несколько каталогов на пути не соответствуют этим требованиям (мое подозрение www принадлежит или доступен для записи вашему веб-пользователю, а не root).
Вернитесь и следуйте инструкциям, убедившись, что требования, выделенные жирным курсивом, выполнены.

Источник

Каталог ChrootDirectory должен принадлежать пользователю root и иметь режим 755:

sudo chown root:root /var/www/RESTRICTED_DIR
sudo chmod 755 /var/www/RESTRICTED_DIR

Хорошо, теперь все файлы в /var/www/RESTRICTED_DIR должен принадлежать MY_USER который должен принадлежать www-data group и имеют режим 775 для разрешения групповых разрешений, например:

sudo usermod -a -G www-data MY_USER
sudo chown MY_USER:www-data /var/www/RESTRICTED_DIR/*
sudo chmod 775 -R /var/www/RESTRICTED_DIR/*

ПРИМЕЧАНИЕ. Помните, что рекомендуется настраивать доступ только к папке htdocs, если вы настраиваете Apache.

Источник

После некоторого устранения неполадок сегодня я понял, что root также должен иметь возможность записи в каталоги.

Следующее не сработало:

$ ls -ld /mnt/synology03/files/
dr-xr-xr-x 1 root root 156 Oct  8 20:10 /mnt/synology03/files/
$ ls -ld /mnt/synology03
drwxr-xr-x 7 root root 4096 Oct  1 21:26 /mnt/synology03
$ ls -ld /mnt
drwxr-xr-x 6 root root 4096 Feb  8 10:01 /mnt
$ ls -ld /
drwxr-xr-x 24 root root 4096 Jan 14 09:22 /

Как только я это исправил, мой chroot начал работать.

$ sudo chmod 755 /mnt/synology03/files/
$ ls -ld /mnt/synology03/files/
drwxr-xr-x 1 root root 156 Oct  8 20:10 /mnt/synology03/files/
Источник

В моем случае нижеприведенные шаги сработали.

  1. useradd -d /data/ftp/user1 -s /bin/false -g users -G sftponly user1
  2. passwd user1
  3. chown root:root /data/ftp/user1
  4. права для группы и другихchmod go+rx /data/ftp/user1
  5. mkdir /data/ftp/user1/{upload,download}
  6. chown user1:users /data/ftp/user1/{upload,download}
  7. sftp user1@ipaddress_server

Проверьте, может ли пользователь1 писать в /data/ftp/user1/{upload,download}

Лучше, если пользователю 1 разрешен только доступ по sftp, а не по ssh. Также пользователь1 должен иметь chroot для своего домашнего директора. Это поможет https://medium.com/tensult/configure-ftp-on-aws-ec2-85b5b56b9c94 .

Источник

Заставил это работать на/a/b/c/CHROOT/stuffтак:

  • a,b,cиCHROOT-root:root755
  • stuff-root:CHROOTED_USER_GROUP775

Затем пользователь может войти в систему с помощью sftp и загрузить файлы на/stuffкаталог.

Источник
Другие вопросы по тегам