Невозможно создавать / редактировать / удалять удаленные файлы после их локального монтирования с помощью SSHFS

Хорошо, несколько основных моментов, поскольку мы столкнулись с недопониманием:

1. Первый уровень разрешений поступает с удаленного сервера: здесь файлы в / var / www принадлежат по www-data и группа установлена ​​на то же самое.

2. По умолчанию только владелец имеет доступ на запись там, в то время как группа только для чтения. Таким образом, установка вашего удаленного пользователя не даст желаемого эффекта, поскольку он является только членом группы, а не сам www-data .

3. Лучше не менять владельца / var / www ] как и вы - это может привести к поломке некоторых вещей. Например. пользователи не смогут загружать файлы на сервер, поскольку nginx работает под управлением www-data , и поэтому запись будет выполняться от имени этого пользователя.

Итак, как решить вашу проблему ?

Я считаю, что наиболее безопасным способом было бы смонтировать его как пользователь www-data . Пойдем по безопасному пути и будем использовать только логины на основе ключей, а также попытаемся ограничить доступ к той самой части, которая нам нужна. Я буду подробно объяснять, чтобы другие пользователи тоже могли получить прибыль.

Определения:

• клиент - ваш домашний компьютер
• сервер - сервер веб-сайта с каталогом, который вы хотите смонтировать
• www-data - www-данные пользователя на сервере
• дан - ваш локальный пользователь на вашем клиенте

Предварительное условие: root -права на сервере

1) Если не существует, создайте пара ключей для дан на вашем клиенте

   ssh-keygen

Просто войдите без пароля. Теперь у вас должны быть файлы id_rsa и id_rsa.pub в ~ / .ssh - Если вы не знакомы с SSH без пароля, там много информации

2) Сделайте так, чтобы www-data принимал открытый ключ dan для входа в систему

www-data имел / var / www в качестве домашнего каталога. В некоторых случаях вы можете захотеть сделать этот каталог доступным для просмотра. В общем, вы не хотели бы помещать туда файл authorized_keys (который представляет собой список принятых открытых ключей для ssh -logins), несмотря на home пользователь является стандартным местоположением. Тогда пойдем в специальное место; лучше всего в / etc .

На сервере: Создайте файл / etc / www / ssh / authorized_keys (плюс родительские каталоги). Измените владельца файла И родительского каталога на www-data , а также измените разрешения. Это необходимо, поскольку ssh принимает только файл authorized_keys с определенными разрешениями на файл и родительский каталог и владельцем соответствующего пользователя:

   chown -R www-data:www-data /etc/www/ssh
   chmod 700 /etc/www/ssh
   chmod 600 /etc/www/ssh/authorized_keys

Оставить право собственности на / etc / www с root

Теперь скопируйте содержимое открытого ключа dan (на клиенте /home/dan/.ssh/id_rsa.pub .. .. pub! , второй - ваш секретный файл и никогда не будет разглашаться) к этому файлу. Убедитесь, что запись находится на одной строке (иногда копирование может вводить новые строки). Должно выглядеть примерно так:

  cat /etc/www/ssh/authorized_keys
  ssh-rsa VERY+long+KEY+from+NUMBERS+and+LETTERS+covering+SEVERAL+lines dan@client

3) Адаптируйте ssh -сервер для этого типа соединения

www-data не имеет оболочки по соображениям безопасности (см. / usr / sbin / nologin из grep www / etc / passwd ). Поэтому нам необходимо адаптировать настройки сервера ssh , чтобы по-прежнему можно было монтировать каталоги. Из соображений безопасности давайте также изменим корневой каталог, чтобы www-data через ssh не могли выходить за пределы / var / www , и принудительно применять аутентификацию с открытым ключом, а также отключена интерактивная отправка команд. В конце концов, веб-сервер видит Интернет - хакерам это нравится.

На сервере: В КОНЦЕ / etc / ssh / sshd_config добавьте эти строки. Обратите внимание, что блоки совпадений никогда не заканчиваются до следующего блока совпадений. Также обратите внимание, что / var / www должен принадлежать root (по умолчанию), чтобы команда ChrootDirectory работала.

Match User www-data
    AuthorizedKeysFile /etc/www/ssh/authorized_keys
    ChrootDirectory /var/www/
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no
    PasswordAuthentication no

(Источники: ] ArchWiki , ssh без оболочки , определение авторизованных ключей )

Перезагрузите конфигурацию через systemctl reload ssh .

4. Все готово

Выполните установку sshfs по желанию на клиенте

sshfs www-data@server:/html /homa/dan/WorkServer

. Обратите внимание, что после изменения корневого каталога / var / www / html становится / hmtl только потому, что / var / www теперь является корневым каталогом.

5. Дополнительная защита

Если применимо: вы делаете это только в локальной сети на рабочем месте? Запретить ssh -доступ к www-data глобально и разрешить его только в сети. Перед блоком соответствия в sshd_config :

 DenyUsers www-data

и поместите рабочую локальную сеть (например, 192.168. Block) в критерии соответствия:

 Match User www-data Address 192.168.