переадресація ssh-агента та sudo іншому користувачеві

Якщо у мене є сервер A, на який я можу ввійти за допомогою свого ключа ssh і маю можливість "sudo su - otheruser", я втрачаю переадресацію ключів, оскільки змінні env видаляються, а сокет читається тільки моїм оригінальним користувачем. Чи є спосіб перемотати переадресацію ключа через "sudo su - otheruser", щоб я міг робити речі на сервері B за допомогою мого перенаправленого ключа (git clone та rsync у моєму випадку)?

Єдиний спосіб, що я можу придумати, - це додати свій ключ до дозволених ключів 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«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

sudo -E -s

• -Е збереже довкілля
• -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$

Більш безпечний і працює і для некоріальних користувачів ;-)

Я виявив, що це також працює.

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

Недоліком є ​​те, що вам потрібно знову увійти в систему, але якщо ви використовуєте його на вкладці екран / tmux, це лише один раз зусилля, однак, якщо ви від'єднаєтесь від сервера, сокет (звичайно) буде зламаний знову . Тому це не ідеально, якщо ви не можете постійно тримати відкритий сеанс екрана / tmux (однак, ви можете вручну оновити SSH_AUTH_SOCKenv var, якщо ви круті).

Також зауважте, що при використанні переадресації ssh, root завжди може отримати доступ до вашого сокету та використовувати вашу аутентифікацію ssh (до тих пір, поки ви ввійшли в систему за допомогою переадресації ssh). Тому переконайтеся, що ви можете довіряти root.

Не використовуйте sudo su - USER, а скоріше sudo -i -u USER. Для мене працює!

Поєднуючи інформацію з інших відповідей, я придумав це:

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

Я думаю, що у вашій команді є проблема з параметром -(тире) su:

sudo su - otheruser

Якщо ви прочитаєте сторінку man від su , ви можете виявити, що параметр -, -l, --loginзапускає середовище оболонки як оболонку для входу. Це створить середовище otheruserнезалежно від змінних env, де ви працюєте su.

Простіше кажучи, тире підірве все, від чого ти перейшов sudo.

Натомість слід спробувати цю команду:

sudo -E su otheruser

Як зазначав @ joao-costa, -Eзбереже всі змінні в середовищі, де ви бігли sudo. Тоді без тире suбуде використовувати це середовище безпосередньо.

На жаль, коли ви подаєте інший користувач (або навіть користуєтеся судо), ви втратите можливість користуватися переадресованими клавішами. Це функція безпеки: Ви не хочете, щоб випадкові користувачі підключалися до вашого ssh-агента та використовували ваші ключі :)

Метод "ssh -Ay $ {USER} @localhost" трохи громіздкий (і як зазначалося в моєму коментарі до відповіді Девіда, схильного до поломки), але це, мабуть, найкраще, що ви можете зробити.