Если у меня есть сервер A, на который я могу войти с помощью моего ключа ssh, и у меня есть возможность «sudo su - otheruser», я теряю перенаправление ключей, потому что переменные env удаляются и сокет доступен для чтения только моему первоначальному пользователю. Есть ли способ связать переадресацию ключей через «sudo su - otheruser», чтобы я мог делать что-то на сервере B с моим перенаправленным ключом (git clone и rsync в моем случае)?
Единственный способ, который я могу придумать, - это добавить свой ключ в authorized_keys 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открытый ключ присутствует в ~/.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
sudo -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 на localhost с перенаправлением агента вместо использования sudo:
ssh -A otheruser@localhost
Недостатком является то, что вам нужно снова войти в систему, но если вы используете его на вкладке screen / tmux, это всего лишь одно действие, однако, если вы отключитесь от сервера, сокет (конечно) снова сломается . Так что это не идеально, если вы не можете постоянно держать сеанс screen / tmux открытым (однако вы можете вручную обновить SSH_AUTH_SOCK env var, если ты крут).
Также обратите внимание, что при использовании пересылки ssh root всегда может получить доступ к вашему сокету и использовать вашу проверку подлинности ssh (если вы вошли в систему с пересылкой ssh). Поэтому убедитесь, что вы можете доверять root.
Объединив информацию из других ответов, я пришел к следующему:
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 пакет).
Не использовать sudo su - USER, скорее sudo -i -u USER. Работает для меня!
Я думаю, что проблема в - (тире) вариант после su в вашей команде:
sudo su - otheruser
Если вы прочитали справочную страницу вс, вы можете обнаружить, что опция -, -l, --login запускает среду оболочки как оболочку входа в систему. Это будет среда для otheruser независимо от переменных env, в которых вы запускаете su.
Проще говоря, тире подорвет все, что вы прошли. sudo.
Вместо этого вы должны попробовать эту команду:
sudo -E su otheruser
Как отметил @ joao-costa, -E сохранит все переменные в среде, в которой вы запустили sudo. Тогда без тире, su будет использовать эту среду напрямую.
К сожалению, когда вы отправляете su другому пользователю (или даже используете sudo), вы теряете возможность использовать свои перенаправленные ключи. Это функция безопасности: вы не хотите, чтобы случайные пользователи подключались к вашему ssh-агенту и использовали ваши ключи :)
Метод «ssh -Ay $ {USER} @localhost» немного громоздок (и, как отмечалось в моем комментарии к ответу Дэвида, часто ломается), но, вероятно, это лучшее, что вы можете сделать.