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

153

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

Ответы:

182

Как вы упомянули, переменные окружения удаляются по 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
MiniQuark
источник
1
Это правильный ответ, должен быть помечен.
Xealot
41
Это работает только если user2выше root! В противном случае user2SSH_AUTH_SOCK будет настроен правильно, но user2не сможет получить доступ, например, / tmp / ssh-GjglIJ9337 /. rootдействительно имеет такой доступ. Таким образом, это может решить часть проблемы, но не ОП: « и сокет
доступен для
6
Defaults>root env_keep+=SSH_AUTH_SOCKСледует убедиться, что это только вперед, когда sudoing для root. Вы не хотите делать это в любом случае с другими пользователями по соображениям безопасности. Лучше запустить отдельный ssh-агент для другого, и добавить соответствующие ключи.
Павел Щиска
1
sudo su -не работает для меня, по-видимому, это не может сохранить окружающую среду, потому что это не sudoво время запуска оболочки. sudo suпохоже на работу.
Алекс Фортуна
3
Я никогда не понимал, почему люди sudo suвсе равно используют . Если вам нужна корневая оболочка, это то, что sudo -sили sudo -iдля.
августа
68
sudo -E -s
  • -E сохранит окружающую среду
  • -s запускает команду, по умолчанию это оболочка

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

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

Разрешить другим пользователям доступ к $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 ;-)

Вилиам Пучик
источник
6
Помните, что при использовании этого метода другие пользователи, вошедшие в систему, также otheruserмогут использовать вашу ssh-аутентификацию
Гитаарик
Это работает для меня, за исключением того, что я должен был изменить "sudo su - otheruser" на "sudo su otheruser" (удаление -).
Чарльз Финкель
1
Почему rwxи нет rw(или rвообще)?
анатолий техтоник
3
@anatolytechtonik Начиная man 7 unixс Linux для подключения к сокету требуются разрешения на чтение и запись для этого сокета. Также вам нужны права поиска (выполнения) и записи в каталоге, в котором вы создаете сокет, или разрешения поиска (выполнения) только при подключении к этому сокету. Таким образом, в приведенном выше ответе разрешение на выполнение для сокета является избыточным.
mixel
вместо того, чтобы редактировать / и т.д. / sudoers вы можете использоватьsudo -u otheruser --preserve-env=HOME -s
Sec
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, что может быть более безопасным. Однако, когда я попытался изменить группу, я получил «Операция не разрешена».

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

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

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

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

ssh -A otheruser@localhost

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

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

gitaarik
источник
Это не работает, если у вас есть доступ только otheruserчерез sudoSSH, а не через SSH (например, вы хотите использовать SCP как www-data)
Герт ван ден Берг
3

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

Фахад Сада
источник
Какая версия sudo у вас есть? У меня (1.6.7p5, CentOS 4.8) нет страницы -i на его странице руководства.
Дэвид Макинтош
Sudo version 1.6.9p17работает на Debian Lenny. Попробовать sudo -s?
Фахад Сада
6
Не работает для меня
В Ubuntu, используя Sudo 1.8.9p5, у меня нет sudo -sни sudo -iработы, ни работы ...
Джон Л.
2

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

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пакет).

warvariuc
источник
1

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

sudo su - otheruser

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

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

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

sudo -E su otheruser

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

Коала Йунг
источник
0

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

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

voretaq7
источник
1
Хм, но если я сделаю это с ssh, тогда мой агент будет доступен этому пользователю в любом случае, или я ошибаюсь?
Если вы отправите SSH целевому пользователю с агентом, перенаправляющим запросы вашего агента, вы переместитесь вверх по цепочке, где бы ни находился «настоящий» агент. Когда вы удаляете su или sudo от исходного пользователя, ваш сокет агента SSH не будет (или не должен) быть доступным - каталог, в котором он находится, находится в режиме 700 и принадлежит первоначальному пользователю. (Очевидное предостережение: если вы переключаетесь в режим root и переустанавливаете среду SSH_AUTH_SOCK, это может сработать, но я бы на это не полагался)
voretaq7
1
На моем сервере (Ubuntu 12.04, SSH версии OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Мар 2012), SSH имеет -aи -Aаргументы. -aделает прямо противоположное тому, что задумано, он отключает переадресацию агента! Таким образом, в последней (и, возможно, во всех) версиях Ubuntu используйте -Aдля включения переадресации агентов.
Вязание
@ knite Вы правы - это (3 года!) опечатка в моем ответе. Исправлено :-)
voretaq7