ryzyko użycia kluczy publicznych ssh


10

Mam serwer A i serwer B (kopia zapasowa) i zastanawiałem się, czy ktoś włamie się na serwer A, czy włamanie na serwer B może być niebezpieczne, jeśli skonfigurowałem logowanie bez hasła przy użyciu kluczy publicznych ssh?

Próbuję skonfigurować rsnapshot.

Dzięki

ssh 

Odpowiedzi:


21

Tak, jest to jeden z problemów z kluczami SSH bez hasła. Jeśli przechowujesz klucz prywatny na serwerze A, który pozwala połączyć się z serwerem B, uzyskanie dostępu do serwera A skutecznie uzyskuje dostęp do serwera B. (Nie jest odwrotnie, nie jest prawdą - uzyskanie dostępu do serwera B nie spowoduje natychmiastowy kompromis z serwerem A, zakładając, że nie masz skonfigurowanych kluczy SSH, aby umożliwić logowanie bez hasła w tym kierunku.

Istnieje kilka sposobów na złagodzenie tego:

  • Jeśli proces nie musi być w pełni zautomatyzowany, dodaj hasło do kluczy SSH. (Prawdopodobnie to nie zadziała, ponieważ zauważysz, że jest to kopia zapasowa)
  • W przypadku logowania bez hasła za pomocą własnego konta na wielu komputerach zalecam utworzenie klucza zabezpieczonego hasłem dla każdego komputera, na którym fizycznie wpiszesz, i użycie agenta SSH do przechowywania klucza w pamięci podczas jego używania. Przekazywanie agentów powinno umożliwiać „przeskakiwanie” z hosta na hosta bez tworzenia kluczy na każdym hoście zdalnym.
  • W przypadku zautomatyzowanych kluczy SSH bez hasła, zalecam ograniczenie poleceń, które klawisz może uruchamiać. W swoim authorized_keyspliku poprzedź każdy klucz:
    command="<allowed command line here>",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty

8-9 lat temu pracowałem we wspólnym środowisku użytkowników z setkami lokalnych użytkowników, a logowanie oparte na kluczach SSH zostało wyłączone, ponieważ nie było sposobu na egzekwowanie zasad haseł na kluczach. Tak długo, jak w pełni kontrolujesz scenariusz, obecnie klucze SSH są zdecydowanie lepsze niż zwykłe używanie haseł.


7

Tak, większość przewodników w Internecie zatrzymuje się przed uruchomieniem ssh bez hasła, zamiast bezpiecznie. Ten przewodnik dobrze pokazuje, co można zrobić, aby zmniejszyć ryzyko. Zasadniczo (zacytować artykuł):

  • utwórz konto roli z jednym celem dla zadania: tj. użytkownika dnssyncna każdym komputerze
  • jeśli to możliwe, spraw, aby pliki były zapisywane przez tego użytkownika, zamiast polegać na rootowaniu
  • dla tych bitów, które naprawdę potrzebują uprzywilejowanego dostępu, utwórz skrypt, aby to zrobić, i użyj sudo
  • użyj command=i from=opcje w authorized_keysplikach, aby ograniczyć klucze bez hasła
  • w celu wykonania transferu plików napisz skrypt, aby to zrobić za pomocą rsync na komputerze odbierającym , aby zdalny dostęp mógł być tylko do odczytu
  • jeśli oznacza to, że potrzebny jest dostęp do komputera inicjującego z komputera zdalnego, użyj ssh-agentzamiast tworzyć drugi klucz bez hasła

4

Istnieje kilka problemów z kluczami ssh:

Nie ma scentralizowanego sposobu unieważnienia klucza.

Nie ma sposobu na egzekwowanie zasad haseł na kluczach (czy Twój klucz prywatny jest szyfrowany, a jeśli tak, to czy jest on szyfrowany przy użyciu dobrego hasła?).

Są to problemy, które rozwiązuje Kerberos. Wprowadza jednak inne, mianowicie jest bardziej skomplikowane do wdrożenia i wymaga rzeczywistej infrastruktury zarządzania użytkownikami do wdrożenia i zarządzania.

W każdym razie, chociaż klucze ssh Author_Keys pozwalają na ataki typu Morris-Worm , nadal są lepsze niż usługi .r i Telnet o mile (lata świetlne)


Jeśli korzystasz z LDAP, możesz zapisać klucz publiczny w katalogu, a następnie użyć (łatek OpenSSH-LPK) [ code.google.com/p/openssh-lpk/] - pomaga to rozwiązać pierwszy problem, chociaż teraz trzeba budować i rozpowszechniać nowe pliki binarne SSH, ogólna korzyść może być ujemna.
Zanchey

To ciekawe, ale wygląda na to, że byłoby to prawie tyle samo pracy, co konfigurowanie Kerberos.
Chris

2

W każdym środowisku, które kontrolowałem, zawsze byłem prawdziwym zwolennikiem minimalnego możliwego przywileju dla kont serwisowych.

W takim przypadku sugeruję upewnienie się, że konto użytkownika na zdalnym serwerze może uruchamiać tylko mały, ściśle określony zestaw plików wykonywalnych. Aby to zrobić, możesz użyć wielu kont na stronie zdalnej i sudo.

Nawet w tym przypadku nadal występują lokalne błędy związane z eskalacją przywilejów, więc bądź skrupulatny i dokładnie monitoruj błędy bezpieczeństwa.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.