пересылка ssh-agent и sudo другому пользователю

Если у меня есть сервер A, на который я могу войти с помощью своего ключа ssh и у меня есть возможность «sudo su - otheruser», я теряю переадресацию ключей, потому что переменные env удаляются, и сокет доступен для чтения только моему первоначальному пользователю. Есть ли способ, которым я могу соединить переадресацию ключей через "sudo su - otheruser", чтобы я мог делать что-то на сервере B с помощью моего перенаправленного ключа (git clone и rsync в моем случае)?

Единственный способ, которым я могу придумать, - это добавить мой ключ к author_keys of otheruser и ssh otheruser @ localhost, но это сложно сделать для каждой комбинации пользователя и сервера, которую я могу иметь.

Короче говоря:

$ sudo -HE ssh user@host
(success)
$ sudo -HE -u otheruser ssh user@host
Permission denied (publickey). 

Как вы упомянули, переменные окружения удаляются по sudoсоображениям безопасности.

Но, к счастью, sudoэто вполне настраиваемо: вы можете точно сказать, какие переменные среды вы хотите сохранить, благодаря env_keepопции конфигурации /etc/sudoers.

Для переадресации агента необходимо сохранить SSH_AUTH_SOCKпеременную среды. Для этого просто отредактируйте свой /etc/sudoersфайл конфигурации (всегда используя visudo) и установите env_keepопцию для соответствующих пользователей. Если вы хотите, чтобы этот параметр был установлен для всех пользователей, используйте следующую Defaultsстроку:

Defaults    env_keep+=SSH_AUTH_SOCK

man sudoers Больше подробностей.

Теперь вы должны быть в состоянии сделать что - то вроде этого ( при условии user1«s открытого ключа присутствует ~/.ssh/authorized_keysв user1@serverAи user2@serverB, и serverA» s /etc/sudoersфайл установка , как указано выше):

user1@mymachine> eval `ssh-agent`  # starts ssh-agent
user1@mymachine> ssh-add           # add user1's key to agent (requires pwd)
user1@mymachine> ssh -A serverA    # no pwd required + agent forwarding activated
user1@serverA> sudo su - user2     # sudo keeps agent forwarding active :-)
user2@serverA> ssh serverB         # goto user2@serverB w/o typing pwd again...
user2@serverB>                     # ...because forwarding still works

sudo -E -s

• -E сохранит окружающую среду
• -s запускает команду, по умолчанию это оболочка

Это даст вам корневую оболочку с оригинальными ключами, которые все еще загружены.

Разрешить другим пользователям доступ к $SSH_AUTH_SOCKфайлу и его каталогу, например, по правильному списку ACL, прежде чем переключаться на них. В примере предполагается , Defaults:user env_keep += SSH_AUTH_SOCKв /etc/sudoersна хост - машине:

$ ssh -A user@host
user@host$ setfacl -m otheruser:x   $(dirname "$SSH_AUTH_SOCK")
user@host$ setfacl -m otheruser:rwx "$SSH_AUTH_SOCK"
user@host$ sudo su - otheruser
otheruser@host$ ssh server
otheruser@server$

Более безопасный и работает для пользователей без полномочий root ;-)

Я обнаружил, что это тоже работает.

sudo su -l -c "export SSH_AUTH_SOCK=$SSH_AUTH_SOCK; bash"

Как уже отмечали другие, это не сработает, если пользователь, на которого вы переключаетесь, не имеет прав на чтение в $ SSH_AUTH_SOCK (который в значительной степени является любым пользователем, кроме root). Вы можете обойти это, установив $ SSH_AUTH_SOCK и каталог, в котором он находится, чтобы иметь разрешения 777.

chmod 777 -R `dirname $SSH_AUTH_SOCK`
sudo su otheruser -l -c "export SSH_AUTH_SOCK=$SSH_AUTH_SOCK; bash"

Это довольно рискованно, хотя. В основном вы даете каждому другому пользователю в системе разрешение использовать ваш агент SSH (до тех пор, пока вы не выйдете из системы). Вы также можете установить группу и изменить разрешения на 770, что может быть более безопасным. Однако, когда я попытался изменить группу, я получил «Операция не разрешена».

Если вы авторизованы sudo su - $USER, тогда у вас, вероятно, будет хороший аргумент для того, чтобы вам разрешалось делать ssh -AY $USER@localhostвместо него ваш действительный открытый ключ в домашнем каталоге $ USER. Тогда переадресация вашей аутентификации будет проведена с вами.

Вы всегда можете просто использовать ssh для локального хоста с переадресацией агента вместо использования sudo:

ssh -A otheruser@localhost

Недостатком является то, что вам необходимо снова войти в систему, но если вы используете его на вкладке screen / tmux, это всего лишь одноразовое усилие, однако, если вы отключитесь от сервера, сокет (конечно) снова сломается , Так что это не идеально, если вы не можете постоянно держать сеанс screen / tmux открытым (однако вы можете вручную обновить свой SSH_AUTH_SOCKenv var, если вы круты).

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

Не используйте sudo su - USER, а скорее sudo -i -u USER. Работает для меня!

Объединяя информацию из других ответов, я придумал это:

user=app
setfacl -m $user:x $(dirname "$SSH_AUTH_SOCK")
setfacl -m $user:rwx "$SSH_AUTH_SOCK"
sudo SSH_AUTH_SOCK="$SSH_AUTH_SOCK" -u $user -i

Мне это нравится, потому что мне не нужно редактировать sudoersфайл.

Проверено на Ubuntu 14.04 (пришлось установить aclпакет).

Я думаю, что есть проблема с -опцией (тире) после suв вашей команде:

sudo su - otheruser

Если вы прочитаете man-страницу su , вы можете обнаружить, что опция -, -l, --loginзапускает среду оболочки как оболочку входа в систему. Это будет среда для otheruserнезависимо от переменных env, где вы работаете su.

Проще говоря, тире подорвет все, что вы прошли от sudo.

Вместо этого вы должны попробовать эту команду:

sudo -E su otheruser

Как указал @ joao-costa, -Eвсе переменные будут сохранены в среде, в которой вы работали sudo. Тогда без черты, suбудет использовать эту среду напрямую.

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

Метод «ssh -Ay $ {USER} @localhost» немного громоздок (и, как отмечено в моем комментарии к ответу Дэвида, склонному к поломке), но, вероятно, это лучшее, что вы можете сделать.