Linux ssh: zezwól na uwierzytelnianie za pomocą klucza publicznego bez przyznawania użytkownikowi prawa odczytu klucza prywatnego

Użytkownicy zalogowani na moim serwerze Linux powinni mieć możliwość ssh do określonego zdalnego komputera z domyślnym kontem. Uwierzytelnianie na zdalnym komputerze wykorzystuje klucz publiczny, więc na serwerze dostępny jest odpowiedni klucz prywatny.

Nie chcę, aby użytkownicy serwera mogli odczytać klucz prywatny. Zasadniczo fakt, że mają dostęp do serwera, pozwala im na poprawne połączenie ssh, a usunięcie ich z serwera powinno również uniemożliwić połączenie ze zdalnym komputerem.

Jak mogę pozwolić użytkownikom na otwieranie połączenia ssh, nie dając im dostępu do odczytu klucza prywatnego?

Moje dotychczasowe przemyślenia: oczywiście plik wykonywalny ssh musi być w stanie odczytać klucz prywatny, więc musi działać pod innym użytkownikiem na serwerze, który ma te prawa. Po ustanowieniu połączenia ssh mogę „przekazać” je użytkownikowi, aby mógł wprowadzać polecenia i wchodzić w interakcje ze zdalnym komputerem.

Czy to dobre podejście?
Jak powinienem wdrożyć forward?
W jaki sposób użytkownik może zainicjować połączenie (to znaczy wykonanie ssh przez użytkownika, który ma uprawnienia do odczytu klucza)?
Czy istnieje luka w zabezpieczeniach? - jeśli użytkownicy mogą wykonać ssh jako inny użytkownik, to czy mogą zrobić wszystko, co inny użytkownik może (w tym odczyt klucza prywatnego)?

— Philipp
źródło

Wydaje się być duplikatem stackoverflow.com/questions/9286622/protecting-ssh-keys

— wenzul

Czy skonfigurować zdalny serwer, aby akceptował połączenia z tym kluczem tylko z adresu IP twojego serwera? W ten sposób, nawet jeśli ukradną klucz, nic nie mogą zrobić.

@ AndréDaniel, być może mogliby zalogować się na inny, całkowicie niepowiązany komputer, który jest również skonfigurowany do akceptowania logowania bez hasła z serwera. To jedyny powód, dla którego mogę wymyślić taką konfigurację; jeśli to nie tak, jestem raczej ciekawy, co to jest. (To nie ma znaczenia, naprawdę.)

— David Z

@DavidZ Naprawdę nie rozumiem ... klucza nie należy ufać nigdzie indziej niż na serwerze docelowym, zakładając, że adres IP pasuje do pierwszego serwera (do którego użytkownicy się łączą).

Jeśli musisz to zablokować w ten sposób, zakładam, że podjąłeś środki, aby uniemożliwić użytkownikom dodawanie nowych kluczy publicznych do ~/.ssh/authorized_keyspliku?

— mpontillo

Odpowiedzi:

To jeden z powodów, dla których sudoistnieje. Po prostu zezwól użytkownikom na uruchamianie 1 pojedynczego polecenia z tylko wstępnie zatwierdzonymi opcjami wiersza polecenia, a najbardziej oczywiste obejścia zostaną rozwiązane. na przykład

#/etc/sudoers
%users ALL = (some_uid) NOPASSWD: /usr/bin/ssh -i /home/some_uid/.ssh/remote-host.key username@remotehost

ustawia się sudotak, aby wszyscy członkowie grupy usersmogli uruchomić komendę ssh jako użytkownik some_uid bez podawania własnego hasła (lub hasła do konta some_uid), gdy działają:

sudo -u some_uid /usr/bin/ssh -i /home/some_uid/.ssh/remote-host.key username@remotehost

Usuń NOPASSWD:opcję wymuszania, aby użytkownicy wprowadzali własne hasła przed zalogowaniem się na zdalnym hoście.
Prawdopodobnie skonfiguruj alias lub skrypt otoki dla wygody użytkowników, ponieważ sudojest dość wybredny przy użyciu poprawnych argumentów.

— HBruijn
źródło

Działa jak marzenie. Powinna to być również zalecana odpowiedź dla duplikatu wspomnianego przez wenzul.

— Philipp

Wydaje się, że jest to dobry przypadek użycia dla uwierzytelniania opartego na hoście. Jest to metoda uwierzytelniania, w której SSH nie używa klucza indywidualnego użytkownika na komputerze lokalnym (w tym przypadku na serwerze) do uwierzytelnienia; zamiast tego używa prywatnego klucza hosta , tego, /etc/ssh/który jest przechowywany i który może być odczytany tylko przez root.

Aby to skonfigurować, musisz utworzyć plik o nazwie .shostsna zdalnej maszynie, w katalogu osobistym użytkownika, który ma się logować (nie w ~/.ssh). Plik powinien mieć zawartość

server-hostname +

gdzie server-hostnamejest nazwą twojego serwera i +jest dosłownym znakiem plus, który służy jako symbol wieloznaczny oznaczający „każdy użytkownik”.

Musisz także upewnić się, że komputer zdalny może zweryfikować klucz hosta serwera, co oznacza, że klucz hosta serwera musi być wymieniony na jednym /etc/ssh/ssh_known_hostslub ~/.ssh/known_hostsna komputerze zdalnym. Jeśli tak nie jest, możesz to skonfigurować, logując się na zdalnym komputerze i uruchamiając

ssh-keyscan server-hostname >> /etc/ssh/ssh_known/hosts

Po skonfigurowaniu tych kroków możesz całkowicie usunąć klucz prywatny z serwera, jeśli nie potrzebujesz go do niczego innego. (A jeśli to zrobisz, zawsze możesz ustawić, aby było czytelne tylko dla rootczegoś.)

Możesz także z łatwością robić takie rzeczy, jak zezwalanie lub odmawianie dostępu niektórym użytkownikom na zdalną maszynę. Zobacz strony podręcznika sshi hosts.equivdla szczegółów.

Jednym z problemów związanych z tą konfiguracją jest to, że użytkownicy logujący się na zdalnym komputerze mogą modyfikować .shosts. Nic nie mogą zrobić, co pozwoliłoby im zalogować się na zdalnym komputerze jako inny użytkownik, ale mogliby odciąć dostęp własny lub innych osobom do zdalnego komputera. Jeśli jest to problem, możesz być w stanie uczynić .shoststylko zapisywalnym przez rootcoś lub coś - nie jestem pewien, czy to działa, ale możesz spróbować i zobaczyć. (Inne metody, takie jak ta, sudosą narażone na to samo ryzyko, ponieważ użytkownik zawsze może usunąć~/.ssh/authorized_keys ).

— David Z
źródło

+1; Myślę, że ta opcja zapewnia dobrą elastyczność w przypadku, gdy użytkownik musi korzystać z funkcji SSH innych niż terminal, takich jak przekierowanie portów, bezpieczne kopiowanie itp. Nawet alternatywny klient SSH powinien działać. Ta sudoopcja mogłaby być lepsza dla zamkniętego środowiska, ale ...

— mpontillo