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
(Успех)
$ sudo -HE -u otheruser ssh user @ host
Разрешение отклонено (publickey).
 
136 голосов | спросил Florian Schulze 28 Jpm1000000pmThu, 28 Jan 2010 16:52:40 +030010 2010, 16:52:40

10 ответов


160

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

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

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

  По умолчанию env_keep + = SSH_AUTH_SOCK
 

man sudoers для более подробной информации.

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

  user1 @ моя_машина & GT; eval `ssh-agent` # запускает ssh-agent
user1 @ моя_машина & GT; ssh-add # добавить ключ user1 к агенту (требуется pwd)
user1 @ моя_машина & GT; ssh -A serverA # no pwd required + активация агента активирована
user1 @ SERVERA & GT; sudo su - user2 # sudo сохраняет активную передачу агента :-)
пользователь2 @ SERVERA & GT; ssh serverB # goto user2 @ serverB без повторного ввода pwd ...
пользователь2 @ ServerB & GT; # ... потому что пересылка все еще работает
 
ответил MiniQuark 4 MaramThu, 04 Mar 2010 00:24:15 +03002010-03-04T00:24:15+03:0012 2010, 00:24:15
52
  sudo -E -s
 
  • -E сохранит среду
  • -s запускает команду, по умолчанию используется оболочка

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

ответил Joao Costa 1 Jpm1000000pmWed, 01 Jan 2014 19:31:44 +040014 2014, 19:31:44
31

Разрешить 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 @ сервер $
 

Более безопасный и работает для пользователей, не являющихся пользователем root, -)

ответил Viliam Pucik 15 42012vEurope/Moscow11bEurope/MoscowThu, 15 Nov 2012 14:58:20 +0400 2012, 14:58:20
14

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

  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».

ответил phylae 21 MaramWed, 21 Mar 2012 04:01:39 +04002012-03-21T04:01:39+04:0004 2012, 04:01:39
5

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

ответил David Mackintosh 28 Jpm1000000pmThu, 28 Jan 2010 17:08:04 +030010 2010, 17:08:04
3

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

  ssh -A otheruser @ localhost
 

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

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

ответил rednaw 27 32013vEurope/Moscow11bEurope/MoscowWed, 27 Nov 2013 18:56:58 +0400 2013, 18:56:58
2

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

ответил Fahad Sadah 28 Jpm1000000pmThu, 28 Jan 2010 19:51:16 +030010 2010, 19:51:16
1

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

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

ответил voretaq7 28 Jpm1000000pmThu, 28 Jan 2010 19:52:33 +030010 2010, 19:52:33
1

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

  = пользователь приложение
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 ).

ответил warvariuc 10 J0000006Europe/Moscow 2015, 20:39:28
0

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

  sudo su - otheruser
 

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

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

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

  sudo -E su otheruser
 

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

ответил Koala Yeung 5 PMpTue, 05 Apr 2016 13:03:35 +030003Tuesday 2016, 13:03:35

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132