Я столкнулся с проблемой, которую я часами бездельничал, не понимая, что происходит. Я прочитал тонны руководств по этому вопросу, что должно быть двухминутной задачей установки в Ubuntu, и я до сих пор не могу заставить ее работать.

Проблема в:

Я настроил правильный sshd_config, по крайней мере, я надеюсь, что сделал все правильно ...

Subsystem sftp internal-sftp

Match Group sftpusers
ChrootDirectory /var/www
AllowTCPForwarding no
X11Forwarding no
ForceCommand internal-sftp

Оба /var /www имеют права доступа 755 root:root. Да, я перезапустил мою службу SSH бесчисленное количество раз. Да, я прочитал около 30 сообщений от stackoverflow о подобных вещах, но никогда не находил ничего, даже тесно связанного с моей проблемой.

Теперь, когда я выполнил предварительные условия, возникает настоящая проблема: когда я пытаюсь подключиться с SFTP, это то, что я вижу в журнале аутентификации:

Nov  8 22:38:07 hidden_server_name sshd[7436]: Accepted password for wordpress_user from imagine_my_hp_address_here port 49508 ssh2
Nov  8 22:38:07 hidden_server_name sshd[7436]: pam_unix(sshd:session): session opened for user wordpress_user by (uid=0)
Nov  8 22:38:07 hidden_server_name systemd: pam_unix(systemd-user:session): session opened for user wordpress_user by (uid=0)
Nov  8 22:38:07 hidden_server_name systemd-logind[1462]: New session 241 of user wordpress_user.
Nov  8 22:38:07 hidden_server_name sshd[7481]: fatal: bad ownership or modes for chroot directory component "/"
Nov  8 22:38:07 hidden_server_name sshd[7436]: pam_unix(sshd:session): session closed for user wordpress_user
Nov  8 22:38:07 hidden_server_name systemd-logind[1462]: Removed session 241.

Естественно, "wordpress_user" является членом группы "sftpusers", проблема в этой строке:

Nov  8 22:38:07 hidden_server_name sshd[7481]: fatal: bad ownership or modes for chroot directory component "/"

Почему он хочет получить доступ к корневому каталогу сервера, когда он явно установлен в /var /www?

Даже несколько раз пытался изменить домашний каталог для всех видов вещей пользователя.

Кто-нибудь, пожалуйста, избавь меня от этой головной боли, это больно! :D

|источник

2 ответа2

0

Это по замыслу.

Строгие разрешения заставят вас заполнить каталог /var/www/ как root с файлами и подкаталогами, выбранными для вашего пользователя или группы. Это не оптимально.

Лучше создать подкаталог в /var/www/ чтобы ваш пользователь мог писать в него, оставив /var/www/ в корневом каталоге.

Если у вас есть только один виртуальный хост на веб-сервере, то это пример того, что вы можете сделать.

sudo chown root:root /var/www/
sudo chmod u=rwx,g=rx,o=rx /var/www/

sudo mkdir /var/www/site1/
sudo chgrp sftponly /var/www/site1
sudo chmod u=rwx,g=rwxs,o=rx /var/www/site1/

В файле конфигурации вашего SSH-сервера добавьте вот так:

Match group sftponly
    ChrootDirectory /var/www/
    X11Forwarding no
    AllowTcpForwarding no
    ForceCommand internal-sftp -d site1

Источник: Перезагрузить страницу плохое владение или режимы для каталога chroot "/var/www".

|источник
0
ChrootDirectory /var/www
...
bad ownership or modes for chroot directory component "/"

Параметр ChrootDirectory требует, чтобы каталог chroot и все его родительские каталоги принадлежали root. Из документации (выделение добавлено):

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

В вашем случае сервер ssh жалуется на корневой каталог системы "/". Видимо, корневой каталог имеет разрешения, которые не соответствуют этим требованиям.

Простейшим решением было бы настроить корневой каталог с разрешениями 0755 и владельцем root. Единственная альтернатива, о которой я знаю, - это создать собственную копию сервера SSH с отключенной проверкой.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .