Как избежать ввода парольной фразы для git pull, выполняемой под www-данными

Question

Я застрял на операции, когда мне нужно выполнить команду Git pull, запущенную из сценария PHP. (пользователь добавлен в группу www-data) без ввода парольной фразы. Я обнаружил, что это можно решить с помощью команды:

eval "$(ssh-agent)"

ssh-add 

Но эта команда работает только под моим собственным пользователем (например, george). Но если я попытаюсь выполнить следующую команду под www-data в репозитории git cloned:

sudo -u george git pull

Я всегда получаю следующее сообщение

Enter passphrase for key '/home/george/.ssh/id_rsa': 

Примечание: я добавляю пользователя в группу www-data, а также в visudo users. Но я не знаю, как решить парольную передачу или избежать ввода парольной фразы.

Большое спасибо за любую помощь.

Answer 1

Есть несколько способов достичь того, что вы хотите:

1. Самый "правильный", на мой взгляд, способ:

   1. Создайте специальный ключ SSH для вашего www-data пользователя, и убедитесь, что этот ключ не зашифрован паролем - потому что именно эта фраза-пароль запрашивается клиентом SSH для расшифровки ключа, который затем используется для аутентификации.
   2. Разверните этот ключ удаленно (в значительной степени зависит от ваших настроек), чтобы его можно было использовать для доступа для чтения.

   3. Затем вы должны сделать этот ключ читаемым www-data пользователь, и только этот пользователь (!), то есть файл ключа должен принадлежать www-data и имеет 0600 (-rw-------) биты разрешений, установленные на нем.

      Есть несколько способов добиться этого:

      • Так как клиент SSH ищет файл ключа под ~/.ssh каталог (то есть .ssh каталог под домашним каталогом пользователя), у вас есть несколько вариантов:
        • Если твой www-data у пользователя есть настоящий домашний каталог в файловой системе (вы можете узнать, запустив getent passwd www-data), вы могли бы создать .ssh каталог там и поместите ключ в нем.
        • В вашем сценарии перетаскивания переопределите HOME переменная среды (и export его новое значение) перед запуском git, так что клиент SSH разрешает домашний каталог в другое место. Остальные должны быть настроены, как описано выше.
      • Клиент SSH поддерживает настройку для каждого пользователя, где можно указать, где искать ключ, и даже указать разные ключи для разных серверов. Обратитесь к ssh_config(5) страница справочника.
      • Клиенты SSH обычно поддерживают указание расположения файла ключа в командной строке. OpenSSH двоичный файл клиента, обычно используемый в обычных ОС на базе Linux и BSD, поддерживает -i опция командной строки (расшифровывается как "идентичность"). Итак, еще один способ - написать скрипт-обертку, который просто вызывает ssh -i /path/to/the/key/file и поместите путь к этому сценарию в (export ред) переменная окружения GIT_SSH так что Git вызывает твой скрипт вместо ssh,

2. С помощью sudo это еще один вариант (хотя мне это не нравится), но, скорее всего, новый процесс, запущенный с измененными учетными данными, не наследует определенные переменные среды, существующие в вашем сеансе, которые сообщают клиенту SSH, как связаться с запущенным экземпляром ssh-agent в котором кэширован ваш дешифрованный ключ (да, существование этого агента является причиной того, что вам нужно вводить вашу фразу-пароль только один раз в сеансе интерактивного входа в систему).

   Так что вы можете прочитать о том, как ssh-agent работает и как сделать sudo сохранить переменные окружения, связанные с ним, при запуске вашего двоичного файла Git с измененными учетными данными.

   Я не совсем уверен, что это будет работать, поскольку все еще может быть проблема с правами доступа к сокету домена Unix (или fifo? - я не могу вспомнить в данный момент), предлагаемый работающим экземпляром ssh-agent для связи с ним, так что вам нужно будет сделать некоторые исследования.

3. Используйте программу как sshpass передать пароль клиенту SSH.

   Это может быть сделано либо напрямую, либо путем обертывания самого клиента SSH (см. Выше).

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

Еще один вариант - предложить доступ к вашему хранилищу, используя неаутентифицируемый протокол только для чтения (git:// или же file:// схема - в зависимости от того, что применимо). Идея заключается в том, что доступ к хранилищу может осуществляться несколькими способами, и даже разные URL-адреса (с разными схемами, то есть протоколами) могут использоваться для извлечения и отправки для одного и того же имени удаленного устройства.