przekazywanie ssh-agent i sudo do innego użytkownika

Jeśli mam serwer A, do którego mogę się zalogować przy użyciu mojego klucza ssh i mam możliwość „sudo su - otheruser”, tracę przekazywanie kluczy, ponieważ zmienne env są usuwane, a gniazdo jest czytelne tylko dla mojego pierwotnego użytkownika. Czy istnieje sposób na zmostkowanie przekazywania kluczy za pomocą „sudo su - otheruser”, dzięki czemu mogę robić rzeczy na serwerze B za pomocą przesłanego klucza (w moim przypadku git clone i rsync)?

Jedyny sposób, jaki mogę wymyślić, to dodanie mojego klucza do uprawnionych kluczy innego użytkownika i „ssh otheruser @ localhost”, ale jest to uciążliwe dla każdej kombinacji użytkowników i serwerów, jaką mogę mieć.

W skrócie:

$ sudo -HE ssh user@host
(success)
$ sudo -HE -u otheruser ssh user@host
Permission denied (publickey). 

Jak wspomniałeś, zmienne środowiskowe są usuwane ze sudowzględów bezpieczeństwa.

Ale na szczęście sudojest dość konfigurowalny: możesz dokładnie powiedzieć, które zmienne środowiskowe chcesz zachować, dzięki env_keepopcji konfiguracyjnej w /etc/sudoers.

W przypadku przekazywania agentów należy zachować SSH_AUTH_SOCKzmienną środowiskową. Aby to zrobić, po prostu edytuj /etc/sudoersplik konfiguracyjny (zawsze za pomocą visudo) i ustaw odpowiednią env_keepopcję dla odpowiednich użytkowników. Jeśli chcesz ustawić tę opcję dla wszystkich użytkowników, użyj następującego Defaultswiersza:

Defaults    env_keep+=SSH_AUTH_SOCK

man sudoers po więcej szczegółów.

Teraz powinno być w stanie zrobić coś takiego (o ile user1jest klucz publiczny jest obecny w ~/.ssh/authorized_keysw user1@serverAi user2@serverB, i serverA's /etc/sudoersplik jest ustawiony jak wskazano powyżej):

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

• -E będzie chronić środowisko
• -s uruchamia polecenie, domyślnie jest to powłoka

To da ci powłokę root z wciąż załadowanymi oryginalnymi kluczami.

Pozwól innemu użytkownikowi uzyskać dostęp do $SSH_AUTH_SOCKpliku i jego katalogu, na przykład przez poprawną listę ACL, przed przełączeniem się na nie. Przykład zakłada Defaults:user env_keep += SSH_AUTH_SOCKsię /etc/sudoersna urządzeniu hosta:

$ 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$

Bardziej bezpieczny i działa również dla użytkowników innych niż root ;-)

Przekonałem się, że to również działa.

sudo su -l -c "export SSH_AUTH_SOCK=$SSH_AUTH_SOCK; bash"

Jak zauważyli inni, nie zadziała to, jeśli użytkownik, do którego się przełączasz, nie ma uprawnień do odczytu na $ SSH_AUTH_SOCK (który jest praktycznie dowolnym użytkownikiem oprócz root). Możesz obejść ten problem, ustawiając $ SSH_AUTH_SOCK i katalog, w którym się znajduje, aby mieć uprawnienia 777.

chmod 777 -R `dirname $SSH_AUTH_SOCK`
sudo su otheruser -l -c "export SSH_AUTH_SOCK=$SSH_AUTH_SOCK; bash"

Jest to jednak dość ryzykowne. Zasadniczo dajesz każdemu użytkownikowi w systemie pozwolenie na używanie agenta SSH (do czasu wylogowania). Możesz także ustawić grupę i zmienić uprawnienia na 770, co może być bezpieczniejsze. Jednak gdy próbowałem zmienić grupę, otrzymałem komunikat „Operacja niedozwolona”.

Jeśli jesteś do tego upoważniony sudo su - $USER, prawdopodobnie będziesz miał dobry argument za tym, że możesz zrobić ssh -AY $USER@localhostzamiast tego, z ważnym kluczem publicznym w katalogu domowym $ USER. Wówczas Twoje przekazywanie uwierzytelnienia zostanie przeprowadzone razem z Tobą.

Zawsze możesz po prostu ssh do localhost z przekazaniem agenta zamiast używać sudo:

ssh -A otheruser@localhost

Wadą jest to, że musisz się ponownie zalogować, ale jeśli używasz go na karcie screen / tmux, to tylko jednorazowy wysiłek, jednak jeśli rozłączysz się z serwerem, gniazdo (oczywiście) zostanie ponownie zepsute . Nie jest to więc idealne, jeśli nie możesz utrzymywać otwartej sesji screen / tmux przez cały czas (możesz jednak ręcznie zaktualizować SSH_AUTH_SOCKenv var, jeśli jesteś fajny).

Pamiętaj również, że podczas korzystania z przekazywania ssh root może zawsze uzyskać dostęp do gniazda i korzystać z uwierzytelniania ssh (o ile jesteś zalogowany przy użyciu przekazywania ssh). Upewnij się więc, że możesz zaufać rootowi.

Nie używaj sudo su - USER, ale raczej sudo -i -u USER. Pracuje dla mnie!

Łącząc informacje z innych odpowiedzi, wpadłem na to:

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

Podoba mi się to, ponieważ nie muszę edytować sudoerspliku.

Testowany na Ubuntu 14.04 (musiał zainstalować aclpakiet).

Myślę, że w twoim poleceniu jest problem z -opcją (myślnik) su:

sudo su - otheruser

Jeśli przeczytasz stronę man su , może się okazać, że opcja -, -l, --loginuruchamia środowisko powłoki jako powłokę logowania. Będzie to środowisko otheruserniezależnie od zmiennych env, w których działasz su.

Mówiąc najprościej, myślnik podważy wszystko, co przeszedłeś sudo.

Zamiast tego powinieneś wypróbować to polecenie:

sudo -E su otheruser

Jak wskazał @ joao-costa, -Ezachowa wszystkie zmienne w środowisku, w którym działałeś sudo. Wtedy bez myślnika suużyje bezpośrednio tego środowiska.

Niestety, gdy poznasz innego użytkownika (lub nawet użyjesz sudo), utracisz możliwość korzystania z przekazanych kluczy. Jest to funkcja bezpieczeństwa: nie chcesz, aby przypadkowi użytkownicy łączyli się z twoim agentem ssh i korzystali z twoich kluczy :)

Metoda „ssh -Ay $ {USER} @localhost” jest nieco uciążliwa (i jak zauważono w moim komentarzu do odpowiedzi Davida podatnej na pękanie), ale prawdopodobnie jest to najlepsza metoda, jaką możesz zrobić.