Выполните команду SSH с пользователем www-данных Apache2


1

Я работаю над проектом виртуальной машины, где я использую два сервера, назовем их сервером A и сервером B, оба с установленной Ubuntu 14.04 LTS.

На сервере A работает веб-сервер Apache2 с веб-сайтом, на котором пользователи могут заказать виртуальные частные серверы. Как только процесс заказа пользователя завершен, пользователь нажимает кнопку, которая создает следующую команду с помощью функции PHP exec ().

ssh -p 22 john@serverB.com fallocate -l 2048M /home/john/images/guest.img 2>&1

Это должно создать образ на сервере B, где в конечном итоге создается виртуальный частный сервер пользователя. Выполнение предыдущей команды с пользователем john прекрасно работает, но поскольку команда запускается через PHP, www-data является пользователем, выполняющим ее.

Как и ожидалось, я получаю следующие ошибки:

array(3) {
  [0]=>
  string(36) "Permission denied, please try again."
  [1]=>
  string(36) "Permission denied, please try again."
  [2]=>
  string(39) "Permission denied (publickey,password)."
}

Я знаю о рисках безопасности, связанных с предоставлением этому пользователю прав sudo для того, чтобы стать другим пользователем и выполнить команду как «john». Поэтому мой вопрос для этого: есть ли другой способ выполнить эту операцию без изменения разрешений www-данных? Я считаю, что SSH - это единственный способ создать что-то на удаленном сервере, или я ошибаюсь?

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

Стоит ли пытаться ответить на этот сценарий этого пользователя? https://superuser.com/a/547577/514523


Еще один вопрос об этой ошибке разрешения - вы уверены, что вы вошли на сервер? Видите ли вы в журнале, что вошел пользователь john? Как вы аутентифицируетесь?
СПРБРН

Что ж, поскольку команда выполняется www-data, именно этот пользователь пытается подключиться к ssh к серверу B. Я получаю ошибки об отказе в разрешении, потому что www-data не имеет пароля. Если я вхожу в систему с пользователем john и выполняю эту команду, все работает нормально.
Beeelze

Таким образом, www-данные не могут войти на сервер B? Но скрипт входа в систему использует «john», а не «www-data».
SPRBRN

Я решил создать cronjob, который позволил бы пользователю 'john' ssh на сервер B. Я еще не разработал его, но он будет работать наверняка.
Beeelze

Вы могли бы дать www-data на сервере B пароль для входа в систему, но я бы не советовал его, учитывая безопасность. Так что лучше использовать «Джон».
SPRBRN

Ответы:


0

Вы должны сделать владельца www-данных / home / john / images, или добавить его в группу john, предоставляя ему надлежащие права на запись, или изменить эту папку на 777.


Попробуй это:

chmod 777 /home/john/images/

Затем вы даете кому-либо права на эту папку, в том числе www-data.

Это может быть слишком много, поэтому, если это работает, вы можете ограничить права. Вы можете добавить www-данные в группу john:

groups www-data
groups john
usermod -aG john www-data

Сначала вы видите, к каким группам относятся www-data и john. Затем вы добавляете www-данные в john-group.

Теперь вы должны ограничить права на эту папку:

chmod 775 /home/john/images/
ls -al /home/john/images/

Теперь пользователь 'john' и все члены группы 'john' имеют права на запись.


Это ничего не делает, потому что мне все еще нужно SSH к серверу B.
Beeelze

смотрите мой обновленный ответ
SPRBRN

Кстати: это гораздо проще, если вы не используете «пользователь» в качестве имени пользователя. Используйте «Джон» или что-то еще, так что ясно, что это имя человека. Слово «пользователь» здесь имеет два значения, и это сбивает с толку.
СПРБРН

Извините, я не хотел использовать там свое собственное имя, но, думаю, это не имеет большого значения, хе-хе. Я попробую то, что вы предлагаете.
Beeelze

Я добавил www-данные в группу 'john' и изменил права на папку / home / john / images /, но это не имеет никакого эффекта. Я думаю, что проблема заключается в том, что www-данные не могут отправиться по ssh на сервер B так же, как это делает john.
Beeelze
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.