☰

Как использовать любую команду (например, git) с ключами ssh обычного пользователя, но с правами доступа к файлам sudo

tag-icon • tag-icon files permissions sudo git
Как использовать любую команду (например, git) с ключами ssh обычного пользователя, но с правами доступа к файлам sudo

Я могу клонировать проект следующим образом:

$ git clone [email protected]:root/myproject.git ~/bla

Но теперь я хочу клонировать его в /var/www. Поэтому я пробую

$ git clone [email protected]:root/myproject.git ~/var/www

Но увы, у меня нет разрешения писать /var/www. Sudo спешит на помощь!

$ sudo git clone [email protected]:root/myproject.git ~/var/www
Cloning into 'www'...
[email protected]'s password:

Что это? У меня просят пароль? Нам не нужны эти вонючие пароли!

Я, очевидно, отправляю ssh-ключи пользователя root с запросом, и поскольку они не были импортированы в репозиторий git, мне отказывают. Раньше я временно менял разрешения папки или сначала клонировал ее куда-то, к чему у меня есть доступ, а затем перемещал ее с помощью sudo, но хотел бы узнать, как это сделать правильно.

Итак... Как мне использовать git с ключами ssh обычного пользователя, но с правами доступа к файлам sudo?

решение1

Если у вас sshзапущен агент, выполните следующие действия:

sudo SSH_AUTH_SOCK="$SSH_AUTH_SOCK" git clone...

По сути, это говорит gitкоманде, запущенной root(или sshкоманде, запущенной этой gitкомандой), использовать вашего sshагента (как подключиться к нему, который rootдолжен иметь такую ​​возможность, поскольку имеет на это все права).

Если у вас не запущен ssh-агент, вы можете запустить его заранее с помощью:

eval "$(ssh-agent)"

(и добавляйте к нему ключи по мере необходимости с помощью ssh-add).

В качестве альтернативы вы можете использовать

sudo -E git clone...

Пройтикаждыйпеременная окружения во всем sudo, а не только $SSH_AUTH_SOCK.

Я бынетполучил предложение @NgOon-Ee в комментарии добавить $SSH_AUTH_SOCKв env_keepсписок. В общем, вы не хотите загрязнять rootсреду , так как это пользователь, от имени которого вы запускаете службы. Например, sudo sshdзапуск sshdслужбы будет означать, что все sshсеансы, запущенные через эту службу, унаследуют вашу $SSH_AUTH_SOCK, загрязняя среду пользователей чем-то, что они не могут и не должны использовать. Даже для других целевых пользователей, чем root, передача этой переменной не будет иметь смысла, так как целевой пользователь не сможет использовать этот агент аутентификации.

Теперь, это касается только аутентификации ключей. Если вы также хотите rootунаследовать свои настройки в вашем ~/.ssh/config, вы не можете сделать это с помощью sshпеременных окружения, но вы можете сделать это с помощью gitпеременных окружения. Например, определение sugitфункции как:

sugit() {
  sudo "GIT_SSH_COMMAND=
    exec ssh -o IdentityAgent='$SSH_AUTH_SOCK' \
             -o User=$LOGNAME \
             -F ~$LOGNAME/.ssh/config" git "$@"
}

То есть, укажите gitиспользовать sshкоманду, которая использует ваш файл конфигурации SSH, агента и имя пользователя вместо root.

Или, может быть, даже лучше, укажите gitзапуск sshот имени исходного пользователя:

sugit() {
  sudo "GIT_SSH_COMMAND=
    exec sudo -Hu $LOGNAME SSH_AUTH_SOCK='$SSH_AUTH_SOCK' ssh" git "$@"
}

решение2

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

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

$ sudo chown apache:www /var/www/html
$ sudo chmod g+s /var/www/html
$ sudo setfacl -m g:webedit:rwx /var/www/html
$ groups
jdoe webedit
$ ls -ld /var/www/html
drwxrwsr-x+ 4 apache www 25 Nov 21 19:42 /var/www/html
$

но у webeditгруппы есть разрешения благодаряsetfacl

$ git clone ~/repo /var/www/html
Cloning into '/var/www/html'...
done.
$ ls -al /var/www/html
total 0
drwxrwsr-x+ 4 apache www   25 Nov 21 19:42 .
drwxr-xr-x  4 root   root  31 Oct 19 20:39 ..
drwxrwsr-x  3 jdoe   www   14 Nov 21 19:42 a
drwxrwsr-x  8 jdoe   www  152 Nov 21 19:42 .git
$

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

Связанный контент