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).
user2
powyżej jestroot
! W przeciwnym razieuser2
SSH_AUTH_SOCK będzie poprawnie skonfigurowany, aleuser2
nie będzie mógł uzyskać dostępu np. / Tmp / ssh-GjglIJ9337 /.root
ma ten dostęp. Może to rozwiązać część problemu, ale nie OP: „ a gniazdo jest czytelne tylko dla mojego oryginalnego użytkownika”Defaults>root env_keep+=SSH_AUTH_SOCK
Powinieneś upewnić się, że przesuwa się tylko podczas sudo do rootowania . I tak nie chcesz tego robić innym użytkownikom ze względów bezpieczeństwa. Lepiej uruchom osobny agent ssh dla innych i dodaj odpowiednie klucze.sudo su -
nie działa dla mnie, prawdopodobnie nie może chronić środowiska, ponieważ nie jest tosudo
czas uruchamiania powłoki.sudo su
wydaje się działać.sudo su
. Jeśli potrzebujesz powłoki roota, po to jestsudo -s
lubsudo -i
jest.To da ci powłokę root z wciąż załadowanymi oryginalnymi kluczami.
źródło
Pozwól innemu użytkownikowi uzyskać dostęp do
$SSH_AUTH_SOCK
pliku i jego katalogu, na przykład przez poprawną listę ACL, przed przełączeniem się na nie. Przykład zakładaDefaults:user env_keep += SSH_AUTH_SOCK
się/etc/sudoers
na urządzeniu hosta:Bardziej bezpieczny i działa również dla użytkowników innych niż root ;-)
źródło
otheruser
mogą również korzystać z uwierzytelnienia ssh.rwx
i nierw
(lubr
wcale)?man 7 unix
- w Linuksie połączenie z gniazdem wymaga uprawnień do odczytu i zapisu w tym gnieździe. Potrzebne są także uprawnienia do wyszukiwania (wykonywania) i zapisu w katalogu, w którym utworzono gniazdo, lub uprawnienia tylko do wyszukiwania (wykonywania) po podłączeniu do tego gniazda. Tak więc w powyższej odpowiedzi wykonanie uprawnienia na gnieździe jest zbędne.sudo -u otheruser --preserve-env=HOME -s
Przekonałem się, że to również działa.
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.
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”.
źródło
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@localhost
zamiast tego, z ważnym kluczem publicznym w katalogu domowym $ USER. Wówczas Twoje przekazywanie uwierzytelnienia zostanie przeprowadzone razem z Tobą.źródło
Zawsze możesz po prostu ssh do localhost z przekazaniem agenta zamiast używać sudo:
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_SOCK
env 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.
źródło
otheruser
przez viasudo
zamiast przez SSH (np. Chcesz SCP jako aswww-data
)Nie używaj
sudo su - USER
, ale raczejsudo -i -u USER
. Pracuje dla mnie!źródło
Sudo version 1.6.9p17
działa na Debianie Lennym. Spróbowaćsudo -s
?sudo -s
niesudo -i
pracuj dla mnie ...Łącząc informacje z innych odpowiedzi, wpadłem na to:
Podoba mi się to, ponieważ nie muszę edytować
sudoers
pliku.Testowany na Ubuntu 14.04 (musiał zainstalować
acl
pakiet).źródło
Myślę, że w twoim poleceniu jest problem z
-
opcją (myślnik)su
:Jeśli przeczytasz stronę man su , może się okazać, że opcja
-, -l, --login
uruchamia środowisko powłoki jako powłokę logowania. Będzie to środowiskootheruser
niezależnie od zmiennych env, w których działaszsu
.Mówiąc najprościej, myślnik podważy wszystko, co przeszedłeś
sudo
.Zamiast tego powinieneś wypróbować to polecenie:
Jak wskazał @ joao-costa,
-E
zachowa wszystkie zmienne w środowisku, w którym działałeśsudo
. Wtedy bez myślnikasu
użyje bezpośrednio tego środowiska.źródło
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ć.
źródło
-a
i-A
argumenty.-a
robi dokładnie odwrotność tego, co jest zamierzone, wyłącza przekazywanie agentów! Tak więc w najnowszej (i prawdopodobnie całej) wersji Ubuntu użyj,-A
aby włączyć przekazywanie agentów.