☰

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

tag-icon • tag-icon ssh sudo forwarding ssh-agent agent
Переадресация ssh-agent и sudo другому пользователю

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

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

Суммируя:

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

решение1

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

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

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

Defaults    env_keep+=SSH_AUTH_SOCK

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

Теперь вы сможете сделать что-то вроде этого (при условии, что user1открытый ключ присутствует в ~/.ssh/authorized_keysи user1@serverA, user2@serverBа serverAфайл /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

решение2

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

Это даст вам root-оболочку с загруженными исходными ключами.

решение3

Позволятьдругойпользовательдля доступа к $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

решение4

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

ssh -A otheruser@localhost

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

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

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