Plik known_hosts umożliwia klientowi uwierzytelnienie serwera, aby sprawdzić, czy nie łączy się on z osobą podszywającą się. Plik authorized_keys pozwala serwer uwierzytelnia użytkownika.

Uwierzytelnianie serwera

Jedną z pierwszych rzeczy, które mają miejsce podczas ustanawiania połączenia SSH, jest wysłanie przez serwer klucza publicznego do klienta i udowodnienie (dzięki kryptografii klucza publicznego ) klientowi, że zna powiązany klucz prywatny. To uwierzytelnia serwer: jeśli ta część protokołu się powiedzie, klient wie, że serwer jest tym, za kogo się podaje.

Klient może sprawdzić, czy serwer jest znany, a nie jakiś fałszywy serwer próbując udawać właściwy. SSH zapewnia tylko prosty mechanizm weryfikacji legalności serwera: zapamiętuje serwery, z którymi już się łączyłeś, w pliku ~/.ssh/known_hosts na komputerze klienckim (jest też system -wide file /etc/ssh/known_hosts). Przy pierwszym połączeniu z serwerem należy w inny sposób sprawdzić, czy klucz publiczny przedstawiony przez serwer jest w rzeczywistości kluczem publicznym serwera chcesz się połączyć. Jeśli masz klucz publiczny serwera, z którym zamierzasz się połączyć, możesz ręcznie dodać go do ~/.ssh/known_hosts na kliencie.

Nawiasem mówiąc, known_hosts może zawierać dowolny typ klucza publicznego obsługiwany przez implementację SSH, nie tylko DSA (także RSA i ECDSA).

Uwierzytelnianie serwer musi być zrobiony przed wysłaniem do niego jakichkolwiek poufnych danych. W szczególności, jeśli uwierzytelnianie użytkownika obejmuje hasło, hasło nie może być wysyłane do nieuwierzytelnionego serwera.

Uwierzytelnianie użytkownika

Serwer zezwala na logowanie użytkownika zdalnego tylko wtedy, gdy ten użytkownik może udowodnić, że ma prawo dostępu do tego konta. W zależności od konfiguracji serwera i wyboru użytkownika, użytkownik może przedstawić jedną z kilku form poświadczeń (poniższa lista nie jest wyczerpująca).

• Użytkownik może przedstawić hasło do konto, na które próbuje się zalogować; serwer sprawdza następnie, czy hasło jest prawidłowe.
• Użytkownik może przedstawić klucz publiczny i udowodnić, że posiada klucz prywatny powiązany z tym kluczem publicznym. Jest to dokładnie ta sama metoda, która jest używana do uwierzytelniania serwera, ale teraz użytkownik próbuje udowodnić swoją tożsamość, a serwer ją weryfikuje. Próba logowania jest akceptowana, jeśli użytkownik udowodni, że zna klucz prywatny, a klucz publiczny znajduje się na liście autoryzacji konta (~/.ssh/authorized_keys na serwerze).
• Inny rodzaj metody polega na delegowaniu części pracy związanej z uwierzytelnianiem użytkownika na komputer kliencki. Dzieje się tak w kontrolowanych środowiskach, takich jak przedsiębiorstwa, gdy wiele komputerów ma te same konta. Serwer uwierzytelnia komputer klienta za pomocą tego samego mechanizmu, który jest używany w drugą stronę, a następnie polega na kliencie w celu uwierzytelnienia użytkownika.

Komentarze

• , dziękuję, jest to bardzo pomocne. słusznie powiedzieć, że plik known_hosts jest utrzymywany na kliencie, podczas gdy plik autoryzowanego_klucza jest utrzymywany na serwerze
• @Ankit Tak, tak jest.
• Mam oba pliki na serwerze i ssh do niego, aby go przetestować. Ale te dwa pliki mają inną zawartość. Więc klucze są różne w tych plikach?
• @Timo Klucze są całkowicie unr podniecony. Jeden to klucz maszyny, drugi to klucz użytkownika.
• @Gilles Więc po dodaniu wpisu dla serwera ' klucz publiczny zostanie dodany do pliku znane_hosts na komputerze klienta ', każda kolejna sesja ssh między nimi nie ' t wymagać od serwera udowodnienia, że posiada właściwy klucz prywatny?

Oba te pliki są używane przez SSH , ale do zupełnie innych celów, co może łatwo wyjaśnić twoje zamieszanie.

Autoryzowane klucze

Domyślnie SSH używa kont użytkowników i haseł zarządzanych przez system operacyjny hosta. (Cóż, w rzeczywistości zarządzany przez PAM , ale to rozróżnienie prawdopodobnie nie jest tutaj zbyt przydatne). Oznacza to, że gdy próbujesz połączyć się z SSH przy użyciu nazwy użytkownika „bob” i jakieś hasło, które program serwera SSH zapyta systemowi operacyjnemu „. Mam gościa o imieniu „bob”, który mówi mi, że jego hasło to „wonka”. Czy mogę go wpuścić? ” Jeśli odpowiedź brzmi tak, to SSH umożliwia uwierzytelnienie i możesz iść dalej.

Oprócz haseł SSH pozwoli Ci również na użycie tzw. kryptografii klucza publicznego , aby Cię zidentyfikować. Konkretny algorytm szyfrowania może się różnić, ale zwykle jest to RSA lub DSA lub ostatnio ECDSA . W każdym przypadku, gdy konfigurujesz klucze, za pomocą ssh-keygen , tworzysz dwa pliki. Jeden to twój klucz prywatny, a drugi to twój klucz publiczny. Nazwy są całkiem takie same -wyjaśnienie. Zgodnie z projektem klucz publiczny można rozrzucać na wietrze jak nasiona mniszka lekarskiego, nie narażając Cię na szwank. Klucz prywatny powinien być zawsze przechowywany w ścisłej tajemnicy.

Więc to, co robisz, to umieszczanie swojego publicznego wprowadź plik authorized_keys. Następnie podczas próby połączenia się z SSH z nazwą użytkownika „bob” i Twój klucz prywatny zapyta system operacyjny ” Mam imię tego gościa „bob”, czy może tu być? ” Jeśli odpowiedź brzmi tak, SSH sprawdzi Twój klucz prywatny i sprawdzi, czy klucz publiczny w pliku authorized_keys jest jego parą. Jeśli obie odpowiedzi są twierdzące, możesz wejść.

Znane hosty

Podobnie jak plik authorized_keys jest używany do uwierzytelniania użytkowników plik known_hosts jest używany do uwierzytelniania serwerów. Za każdym razem, gdy SSH jest konfigurowane na nowym serwerze, zawsze generuje klucz publiczny i prywatny dla serwera, tak jak zrobiłeś to dla swojego użytkownika. Za każdym razem, gdy łączysz się z serwerem SSH, pokazuje on swój klucz publiczny wraz z dowodem, że posiada odpowiedni klucz prywatny. Jeśli nie masz jego klucza publicznego, komputer zapyta o niego i doda go do pliku known_hosts. Jeśli masz klucz i pasuje, łączysz się od razu. Jeśli klawisze nie pasują, pojawi się duże nieprzyjemne ostrzeżenie. Tutaj robi się ciekawie. Trzy sytuacje, w których zwykle występuje niezgodność klucza, to:

1. Klucz zmieniony na serwerze. Może to być spowodowane ponownym zainstalowaniem systemu operacyjnego lub w niektórych systemach operacyjnych klucz jest odtwarzany podczas aktualizacji SSH.
2. Nazwa hosta lub adres IP, z którym się łączysz należał do innego serwera. Może to być zmiana przypisania adresu, DHCP lub coś podobnego.
3. Złośliwe man- ma miejsce atak w środku . To największa rzecz, przed którą próbuje Cię chronić sprawdzanie kluczy.

W obu przypadkach known_hosts i authorized_keys, program SSH używa kryptografii klucza publicznego w celu identyfikacji klienta lub serwera.

Komentarze

• ” Za każdym razem, gdy łączysz się z serwerem SSH, przedstawia on swój klucz prywatny w celu potwierdzenia swojej tożsamości. ” Mam nadzieję, że nie! Zakładam, że miałeś na myśli jego klucz publiczny . Gdyby serwer przedstawił mi, klient ze swoim kluczem prywatnym – to (A) nie ' nie działa dla mnie, aby go uwierzytelnić, a (B) oznacza, że serwer jest taki źle skonfigurowany, że powinienem natychmiast przestać z nim robić interesy. Klucze prywatne powinny być dostępne na komputerze pochodzenia tylko dla wyznaczonych użytkowników. To ' o to chodzi. 😉
• Ta odpowiedź pomogła mi bardziej niż zaakceptowana (:
• Jeśli ssh na lokalny serwer (lokalny adres IP), a później z tego samego komputera, ale teraz zdalnie połączyć się z tym samym serwerem (publicznym adresem IP), czy spowoduje to wywołanie niezgodnych kluczy? Jak można temu zaradzić?

Informacje o bezpiecznych plikach zawierających klucze publiczne

Aby pomóc Ci zrozumieć, czym różnią się „znane_hosty” i „autoryzowane_klucze”, oto kontekst wyjaśniający, jak te pliki pasują do „ssh”. Jest to nadmierne uproszczenie ; jest dużo więcej możliwości i komplikacji związanych z „ssh” niż zostało to tutaj wymienione.

Powiązania są w zaufanych źródłach

Chociaż powiedziano, że wartości klucza publicznego „można bezpiecznie rozrzucić jak ziarno na wietrze”, należy pamiętać, że jest to gardner, a nie strąk nasion, który decyduje, które nasiona zostaną zasadzone w ogrodzie. Chociaż klucz publiczny nie jest tajny, wymagana jest silna ochrona, aby zachować zaufane skojarzenie klucza z tym, co uwierzytelnia klucz. któremu powierzono utworzenie tego powiązania, w tym listy „znane_hosty”, „autoryzowane_klucze” i „Urząd certyfikacji”.

Zaufane źródła używane przez „ssh”

Aby klucz publiczny był związany z „ssh”, klucz musi zostać zarejestrowany z wyprzedzeniem i przechowywany w odpowiednim bezpiecznym pliku. (Ta ogólna prawda ma jeden ważny wyjątek, który zostanie omówiony później). Serwer i klient mają własne, bezpiecznie przechowywane lista kluczy publicznych; logowanie powiedzie się tylko wtedy, gdy każda strona jest zarejestrowana razem z drugą.

• „znane_hosty” znajduje się na clie nt
• „Authorized_keys” znajduje się na serwerze

Bezpieczny plik klienta nosi nazwę „znane_hosty”, a bezpieczny plik serwera nosi nazwę „Authorized_keys” . Pliki te są podobne pod tym względem, że każdy zawiera tekst z jednym kluczem publicznym w każdym wierszu, ale różnią się nieznacznie formatem i sposobem użycia.

Pary kluczy są używane do uwierzytelniania

Publiczny -Prywatna para kluczy jest używana do wykonywania „asymetrycznej kryptografii”. Program „ssh” może wykorzystywać kryptografię asymetryczną do uwierzytelniania, gdy jednostka musi odpowiedzieć na wyzwanie, aby udowodnić swoją tożsamość. Wyzwanie jest tworzone przez kodowanie jednym kluczem, a odpowiedź polega na dekodowaniu drugim kluczem. (Zwróć uwagę, że asymetryczna kryptogrofia jest używana tylko podczas fazy logowania; wtedy „ssh” (TSL / SSL) przełącza się na inną formę szyfrowania, aby obsłużyć strumień danych.)

Jedna para kluczy dla serwera, inna dla klienta

W „ssh” obie strony (klient i serwer) są podejrzane wobec drugiej; jest to ulepszenie w stosunku do poprzednika „ssh”, którym był „telnet”. W przypadku „telnetu” klient musiał podać hasło, ale serwer nie został sprawdzony. Brak weryfikacji pozwolił na ataki typu „man-in-the-middle”, które miały katastrofalne skutki dla bezpieczeństwa. Z kolei w procesie „ssh” klient nie przekazuje żadnych informacji, dopóki serwer nie odpowie na wyzwanie.

Kroki w uwierzytelnianiu „ssh”

Przed udostępnieniem jakichkolwiek danych logowania, klient „ssh” najpierw eliminuje możliwość ataku typu „man-in-the-middle”, rzucając serwerowi wyzwanie, aby udowodnić, „Czy naprawdę jesteś tym, za kogo się uważam?” Aby sprostać temu wyzwaniu, klient musi znać klucz publiczny powiązany z serwerem docelowym. Klient musi znaleźć nazwę serwera w pliku „znane_hosty”; skojarzony klucz publiczny znajduje się w tym samym wierszu, po nazwie serwera. Skojarzenie między nazwą serwera i kluczem publicznym musi być nienaruszone; dlatego uprawnienia włączone plik „znane_hosty” musi mieć 600 – nikt inny nie może pisać (ani czytać).

Po uwierzytelnieniu serwer ma szansę zakwestionować klienta. Uwierzytelnienie będzie obejmować jedno z publicznych klucze znalezione w „Authorized_keys”. (Gdy żaden z tych kluczy nie działa, proces „sshd” cofa się przy uwierzytelnianiu za pomocą hasła).

Formaty plików

Więc dla „ ssh ”, tak jak w przypadku każdego procesu logowania, istnieją listy„ przyjaciół ”i tylko ci z listy mogą próbować przejść wyzwanie. Dla klienta plik„ znane_hosts ”to lista znajomych, którzy mogą działać jako serwery (hosty); są one wymienione według nazw. W przypadku serwera równoważną listą znajomych jest plik „Authorized_keys”; ale w tym pliku nie ma nazw, ponieważ publikacja Same klucze c działają jak identyfikatory. (Serwer nie dba o to, skąd pochodzi login, ale tylko dokąd idzie. Klient próbuje uzyskać dostęp do określonego konta, nazwa konta została określona jako parametr przy wywołaniu „ssh”. Pamiętaj, że Plik „allowed_keys” jest specyficzny dla tego konta, ponieważ plik znajduje się w katalogu domowym tego konta.)

Chociaż istnieje wiele możliwości, które można wyrazić we wpisie konfiguracyjnym, podstawowe, najczęściej używane użycie ma następujące parametry. Zwróć uwagę, że parametry są oddzielone spacjami.

Dla „znanych_hostów”:

{server-id} ssh-rsa {public-key-string} {comment} 

Dla „kluczy_autoryzowanych”:

ssh-rsa {public-key-string} {comment} 

Zwróć uwagę, że token ssh-rsa wskazuje, że algorytmem użytym do kodowania jest „rsa”. Inne prawidłowe algorytmy uwzględnij „dsa” i „ecdsa”. Dlatego inny token może zająć miejsce pokazanego tutaj ssh-rsa.

Niech „ssh” automatycznie skonfiguruje Wpis „znane_hosty”

W obu przypadkach, jeśli th Klucz publiczny nie został znaleziony w bezpiecznym pliku, więc szyfrowanie asymetryczne nie występuje. Jak wspomniano wcześniej, jest jeden wyjątek od tej reguły.Użytkownik może świadomie zaryzykować możliwość ataku typu man-in-the-middle, logując się do serwera, który nie jest wymieniony w pliku „known_hosts” użytkownika. Program „ssh” ostrzega użytkownika, ale jeśli użytkownik zdecyduje się przejść dalej, klient „ssh” zezwala na to „tylko raz”. Aby upewnić się, że dzieje się to tylko raz, proces „ssh” automatycznie konfiguruje plik „known_hosts” z wymaganymi informacjami, prosząc serwer o klucz publiczny, a następnie zapisuje go w pliku „znane_hosty”. Ten wyjątek całkowicie podważa bezpieczeństwo, umożliwiając przeciwnikowi skojarzenie nazwy serwera z kluczem publicznym. To zagrożenie bezpieczeństwa jest dozwolone, ponieważ sprawia, że łatwiejsze dla tak wielu ludzi. Oczywiście poprawną i bezpieczną metodą byłoby ręczne wstawienie przez użytkownika wiersza z nazwą serwera i kluczem publicznym do pliku „znane_hosty” przed próbą zalogowania się do serwera. (Ale w sytuacjach niskiego ryzyka dodatkowa praca może być bezcelowa.)

Relacje jeden-do-wielu

Wpis w pliku „znane_hosty” klienta zawiera nazwę serwera i klucz publiczny, który ma zastosowanie do serwera. Serwer ma jeden klucz prywatny, który jest używany do odpowiedzi na wszystkie wyzwania, a wpis klienta „znane_hosty” musi mieć pasujący klucz publiczny. Dlatego wszyscy klienci, którzy kiedykolwiek uzyskają dostęp do określonego serwera, będą mieli identyczny klucz publiczny wpis w pliku „znane_hosty”. Relacja 1: N polega na tym, że klucz publiczny serwera może występować w wielu plikach „znanych_hostów” klienta.

Wpis w pliku „Authorized_keys” identyfikuje że przyjazny klient może uzyskać dostęp do konta. Znajomy może użyć tej samej pary kluczy publiczny-prywatny, aby uzyskać dostęp do wielu różnych serwerów. Dzięki temu jedna para kluczy może uwierzytelnić się na wszystkich serwerach, z którymi kiedykolwiek się kontaktowano. Każde z docelowych kont serwerów miałby identyczny wpis klucza publicznego w swoich plikach „Authorized_keys”. Relacja 1: N polega na tym, że klucz publiczny jednego klienta może pojawić się w plikach „Authorized_keys” dla wielu kont na wielu serwerach.

Czasami użytkownicy pracujący na wielu komputerach klienckich replikują tę samą parę kluczy; zwykle dzieje się tak, gdy użytkownik pracuje na biurku i laptopie. Ponieważ komputery klienckie uwierzytelniają się przy użyciu identycznych kluczy, będą one pasować do tego samego wpisu w „s” autoryzowanych_kluczach serwera.

Lokalizacja kluczy prywatnych

Po stronie serwera proces systemowy lub demon obsługuje wszystkie przychodzące żądania logowania „ssh”. Demon nazywa się „sshd”. Lokalizacja klucza prywatnego zależy od instalacji SSL, na przykład Apple umieszcza go w /System/Library/OpenSSL, ale po zainstalowaniu własnej wersji OpenSSL lokalizacja będzie miała postać /opt/local/etc/openssl.

Po stronie klienta wywołujesz „ssh” (lub „scp” ) w razie potrzeby. W wierszu poleceń będą znajdować się różne parametry, z których jeden może opcjonalnie określać, którego klucza prywatnego należy użyć. Domyślnie para kluczy po stronie klienta jest często nazywana $HOME/.ssh/id_rsa i $HOME/.ssh/id_rsa.pub.

Podsumowanie

Najważniejsze jest to, że zarówno „znane_hosty”, jak i „autoryzowane_klucze” zawierają klucze publiczne, ale …

• znane_hosty – klient sprawdza, czy host jest prawdziwy
• autoryzowane_klucze – host sprawdza, czy logowanie klienta jest dozwolone

Komentarze

• Klienci SSH zwykle nie ' nie mam kluczy. Klucze publiczne wymienione w authorized_keys identyfikują użytkowników, a nie komputery.
• Dziękuję. To jest bardzo jasne i łatwo zrozumiałe wyjaśnienie związków między plikami i kluczami.

Zupełnie nieprawda.

Plik known_hosts zawiera odcisk palca hosta. Nie jest to publiczny ani prywatny klucz zdalnego hosta.

Jest generowany na podstawie ich klucza – ale zdecydowanie NIE jest samym kluczem.

Jeśli przesyłasz SFTP na adres, który może rozwiązać się do kilku (różnych) hostów (zrównoważone obciążenie itp.), musisz dodać odciski palców ze wszystkich możliwych punktów końcowych, albo zadziała początkowo, a następnie zawiedzie, gdy zostanie przekierowany do drugiego (lub kolejnego) hosta.

Komentarze

• erm spójrz na swój plik known_hosts i porównaj go z odciskiem palca hosta po nawiązaniu połączenia… To powinno trochę wyjaśnić. Ponadto Twój przykład byłby dokładnie taki sam, niezależnie od tego, czy są to odciski palców czy klucze publiczne w pliku znane_hosts.