Пользователь не может подключиться через SFTP к /var /www /html /

Question

У меня есть сервер Ubuntu на Amazon, на котором работает LAMP и сайт WordPress. Я создал пользователя с именем ftpuser, который будет подключаться с FTP-клиента по протоколу SFTP к /var/www/html/site/ и иметь права на него.

1. Я создал ключи SSH, и пользователь подключается к своей папке /home/ftpuser/ .

2. Я поставил

   usermod -m -d /var/www/html/site/ ftpuser
   

3. Скопировал /home/ftpuser/.ssh/ в /var/www/html/site . Я установил право собственности на ftpuser.

4. Добавлен ftpuser в группу www-data .

Но это не работает для меня. Пользователь FTP даже не подключается. Пользователь фактически подключается только для начального домашнего каталога пользователя.

Нужно ли менять владельца /var/www/html/site/ на ftpuser , но в этом случае сайт WordPress перестанет работать, потому что www-data настроен для запуска Apache, или я ошибаюсь?

В каком-то руководстве написано:

chmod ug+w /var/www/html/site/
chmod g+s /var/www/html/site/
setfacl -d -m g::rwx /var/www/html/site/

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

Любая помощь, пожалуйста? Вот некоторые сведения о каталогах:

ls -l /var/www/html/
drwxr-xr-x 12 www-data www-data 4096 Jan 29 13:16 site

ls -al /var/www/html/site/
drwx-w----  2 ftpuser  www-data  4096 Jan 29 13:16 .ssh

ls -l /var/www/html/site/.ssh/
-rw-r--r-- 1 ftpuser www-data  407 Jan 29 13:16 authorized_keys
-rw------- 1 ftpuser www-data 1675 Jan 29 13:16 id_rsa
-rw-r--r-- 1 ftpuser www-data  406 Jan 29 13:16 id_rsa.pub

getfacl /var/www/html/site/
getfacl: Removing leading '/' from absolute path names
# file: var/www/html/site/
# owner: www-data
# group: www-data
user::rwx
group::r-x
other::r-x

getfacl /var/www/html/site/.ssh/
getfacl: Removing leading '/' from absolute path names
# file: var/www/html/site/.ssh/
# owner: ftpuser
# group: www-data
user::rwx
group::-w-
other::---

Решаемые. В моем случае я также должен был сделать:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Answer 1

Сначала вы говорите: «Пользователь FTP даже не подключается». Если пользователь получает ошибки, такие как Connection timed out , у вас, скорее всего, есть проблема с брандмауэром /iptables, и вам нужно сначала ее исправить. SFTP использует тот же TCP-порт, что и SSH: по умолчанию это 22.

Во-вторых, по соображениям безопасности домашний каталог обычного пользователя обычно принадлежит самому пользователю (обычный случай) или root (для пользователей специального назначения). Кроме того, чтобы получить доступ к своему домашнему каталогу, пользователь должен иметь как минимум разрешение x (доступ к каталогу) для всех (больших) родительских каталогов своего домашнего каталога, вплоть до корневого. Если эти требования не выполняются, sshd может предположить нечестную игру и запретить вход в систему (shell и SFTP) для этого пользователя. Если клиент SFTP успешно получает ключ хоста сервера, но затем отключается, это может быть тем, что происходит.

sshd также требует, чтобы домашний каталог пользователя, любые (большие) родительские каталоги вплоть до корневого каталога, подкаталог .ssh и файл authorized_keys в нем файлы не были доступны для записи другим пользователям, иначе sshd будет предполагать, что " авторизованные ключи "вставляются другим злоумышленником и не доверяют им. Размещение домашнего каталога пользователя в середине поддерева HTTP-сервера может затруднить выполнение этих требований.

Если в системе действуют SELinux или другие дополнительные меры безопасности, попытка разместить домашний каталог пользователя в нестандартном месте может потребовать дополнительных действий. В целом, будет гораздо проще просто создать символическую ссылку на домашний каталог ftpuser , указывающую на фактическое местоположение сайта. Пользователь должен будет иметь дело с одним подкаталогом, но это обычно допустимо.

Я бы рекомендовал сначала восстановить нормальное местоположение домашнего каталога пользователя:

usermod -d /home/ftpuser ftpuser

Затем создаем символическую ссылку:

ln -s /var/www/html/site /home/ftpuser/site

Тогда начните тестирование. Сначала попытайтесь заставить пользователя FTP хотя бы подключиться: проверьте журналы сервера, чтобы увидеть, установлено ли сетевое соединение. Затем убедитесь, что аутентификация по ключу SSH работает. Только после этого пришло время беспокоиться о правах доступа к файлам. Возможно, вам лучше написать отдельный вопрос о них.

И если вы хотите, чтобы ftpuser видел только содержимое веб-сайта и никаких других частей системы, это особый случай: это привязанная к учетной записи SFTP и у нее есть некоторые дополнительные требования, в зависимости от версии sshd используемой в системе. , Возможно, было бы проще ftpuser в стандартную домашнюю директорию, а затем сделать сайт доступным в тюрьме с помощью привязки:

mkdir /home/ftpuser/site  #empty directory for a mount point
mount -o bind,rw /var/www/html/site /home/ftpuser/site

Подобно символической ссылке, это еще один, совместимый с chroot способ для ftpuser "видеть" каталог сайта как подкаталог своего домашнего каталога: это никак не повлияет на работу сайта.

(Символьные ссылки не могут указывать изнутри тюрьмы chroot на внешний мир, но монтирование привязки может сделать части других файловых систем доступными внутри тюрьмы.)

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

• a) Каталоги и файлы, которые вы хотите, чтобы они были доступны для чтения как веб-сервером, так и сопровождающими, но не могли быть изменены ни одним из них: это может включать в себя привилегированные сценарии CGI или другие подобные части инфраструктуры сайта.
• б) каталоги и файлы, которые вы хотите изменить подконтрольно (ые) для сайта, но которые могут быть прочитаны только веб-сервером: это будет статический контент, который вы хотите защитить от порчи, даже если злоумышленник обнаружит новую уязвимость WordPress или другую вектор атаки.
• c) Каталоги и файлы, которые должны быть модифицированы WordPress и / или другими процессами, работающими как часть веб-сервера, а также сопровождающими (-ями) сайта. Это будет по сути WordPress и весь контент, которым он управляет.
• d) каталоги и файлы, которые видоизменяемые только WordPress. По умолчанию WordPress автоматически обеспечивает защиту файлов своей базы данных следующим образом.

Файлы и каталоги в категориях a) и b) просты: они могут принадлежать любому пользователю / группе, кроме www-data . Единственным требованием является то, что они доступны для чтения пользователю www-data , и биты прав доступа для чтения / доступа будут покрывать это.

Файлы и каталоги в категории а) могут принадлежать пользователю root, root группы и иметь права доступа, например -rw-r--r-- для обычных файлов, -rwxr-xr-x для исполняемых файлов и drwxr-xr-x для каталогов ,

Если на вашем сайте есть файлы в категории b), вы можете создать вторую группу wwwadmin и сделать ftpuser членом этой группы. Для этой группы важно, чтобы пользователь www-data не был участником.

Файлы и каталоги в категории b) будут принадлежать пользователю ftpuser (или кому-либо еще), группе wwwadmin и разрешениям -rw-rw-r-- для обычных файлов, -rwxrwxr-x для исполняемых файлов и drwxrwxr-x для каталогов.

Если Apache работает как пользователь www-data любые новые файлы , созданные с помощью WordPress и / или любых других компонентов сайта будет принадлежать пользователю www-data группы www-data Поскольку ваш ftpuser уже является членом группы www-data , вам нужно только убедиться, что в категории c) все файлы имеют базовые разрешения rw-rw-r-- и все разрешения для каталогов drwxrwxr-x. Это означало бы добавление разрешения на запись в группу для всех файлов, принадлежащих www-data и настройку Apache и / или WordPress для использования umask 002 . Я думаю, что в Ubuntu маску Apache можно установить в /etc/apache2/envvars . WordPress может переопределить umask по умолчанию для веб-сервера, поэтому вам может потребоваться настроить его отдельно.

Чтобы все файлы и каталоги, принадлежащие группе www-data имели необходимые права доступа к группе, выполните следующую команду:

find /var/www/html/site -group www-data -exec chmod g+rwX {} \+

Вы также можете добавить бит разрешения setgid во все каталоги, принадлежащие пользователю www-data , чтобы гарантировать, что все добавленные к ним новые файлы и подкаталоги будут автоматически принадлежать группе www-data даже если это не так. основная группа пользователей, добавляющих файл / каталог:

find /var/www/html/site -type d -group www-data -exec chmod g+s {} \+

Это изменяет групповые разрешения drwxrwxr-x на drwxrwsr-x и устраняет необходимость в ftpuser для ручного использования chgrp www-data после добавления любых новых файлов.

Если вы измените настройку umask по умолчанию для ftpuser на 002 (если это не так), любые новые файлы, которые они создадут, будут по умолчанию иметь доступ для групповой записи. Это помогает при изменении файлов категории c) и не должно мешать работе других файлов в обычной Ubuntu. Конечно, их SFTP-клиент может попытаться сохранить существующие права доступа к файлам при их передаче, что может потребовать некоторой настройки на стороне клиента.

Если вы хотите разрешить ftpuser манипулировать файлами категории d), пользователь должен знать, что до тех пор, пока у него есть доступ на запись в каталог, в котором находится файл, и файл доступен для чтения, он всегда может стать владельцем файла. сделав копию файла, а затем удалив оригинал.