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


Если у меня есть сервер 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). 

137
2018-01-28 13:52


Источник




Ответы:


Как вы упомянули, переменные окружения удаляются 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

160
2018-03-03 21:24



Это правильный ответ, он должен быть отмечен. - Xealot
Эта только работает, если user2 выше root! В противном случае, user2 будет правильно настроен SSH_AUTH_SOCK, но user2 не смогут получить доступ, например. / TMP / SSH-GjglIJ9337 /. root имеет этот доступ. Таким образом, это может решить часть проблемы, но не ОП:а также сокет доступен только для моего первоначального пользователя " - Peter V. Mørch
Defaults>root env_keep+=SSH_AUTH_SOCK Должен быть уверен, что только вперед, когда sudoing в корень. Вы не хотите делать это в любом случае другим пользователям по соображениям безопасности. Лучше запустить отдельный ssh-agent для otherother и добавить соответствующие ключи. - Paul Schyska
sudo su - не работает для меня, по-видимому, он не может сохранить окружающую среду, потому что это не sudo во время запуска оболочки. sudo su похоже работа. - Alex Fortuna
Я никогда не понимал, почему люди используют sudo su так или иначе. Если вам нужна корневая оболочка, вот что sudo -s или sudo -i для. - eaj


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

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


52
2018-01-01 15:31



Как и в случае с вышеприведенным комментарием, это касается только вопроса, если вы становитесь root, потому что в этом случае root может обойти обычные разрешения доступа на $ SSH_AUTH_SOCK. - doshea


Позволять otheruser доступа $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 ;-)


31
2017-11-15 10:58



Помните, что при использовании этого метода другие пользователи вошли в систему как otheruser также может использовать вашу аутентификацию ssh. - rednaw
Это работает для меня, кроме того, что мне пришлось изменить «sudo su - otheruser» на «sudo su otheruser» (удаление -). - Charles Finkel
Зачем rwx и не rw (или r вообще)? - anatoly techtonik
@anatolytechtonik От man 7 unix - при подключении Linux к соке требуется разрешение на чтение и запись на этом сокете. Также вам необходимо выполнить поиск (выполнить) и написать разрешение в каталоге, в котором вы создаете сокет или только разрешение на поиск (выполнение) при подключении к этому сокету. Таким образом, в приведенном выше ответе выполнение разрешения на сокет является избыточным. - mixel


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

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, что может быть более безопасным. Однако, когда я попытался изменить группу, я получил «Operation not allowed».


14
2018-03-21 00:01



Это очень рискованно. Предоставление каждому другому пользователю разрешения на использование вашего агента SSH эквивалентно предоставлению им всех ваших учетных данных (и если вы когда-либо используете sudo или su, предоставляя им власть над всеми другими пользователями в системе, а также все другие системы, к которым вы ssh!) , Это НИКОГДА не должно быть сделано! - Matija Nalis
Я не согласен с утверждением, что «это НИКОГДА НИКОГДА не будет сделано!» Существует много случаев, когда этот риск является приемлемым. Например, небольшая команда, где все имеют одинаковые разрешения, и вы доверяете всем другим пользователям. Это никогда не должно быть сделано без понимания рисков, которые он включает. Но как только эти риски понятны, временами риск является приемлемым. - phylae


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


5
2018-01-28 14:08



Он упомянул об этом в нижней части своего вопроса и сказал, что это будет трудно сделать. - Fahad Sadah
Это, вероятно, лучшее решение, но оно становится волосатым, если $ USER является реальным человеком (tm) - они могут удалить ключ SA от authorized_keys или изменить свой пароль ... - voretaq7
Вы можете удалить свой доступ на запись к authorized_keys (хотя, если они действительно настроены на отказ от доступа Florian, они могут удалять и воссоздавать его, находясь в каталоге, которому они принадлежат) - Fahad Sadah


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

ssh -A otheruser@localhost

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

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


3
2017-11-27 14:56





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


2
2018-01-28 16:51



Какая версия sudo у вас есть? Шахта (1.6.7p5, CentOS 4.8) не имеет -i на странице руководства. - David Mackintosh
Sudo version 1.6.9p17 работает на Debian Lenny. Пытаться sudo -s? - Fahad Sadah
Не работает для меня.
На Ubuntu, используя Sudo 1.8.9p5, ни sudo -s ни sudo -i работа для меня ... - Jon L.