Uwierzytelnianie oparte na kluczach SSH: znane_hosty vs autoryzowane

Czytam o konfigurowaniu kluczy ssh w Linuksie i mam kilka pytań. Popraw mnie, jeśli się mylę…

Powiedzmy, że host tr-lgto chce połączyć się z hostem tr-mdm za pomocą ssh. Jeśli chcemy mieć pewność, że to prawdziwy tr-mdm, generujemy parę kluczy na tr-mdm i dodajemy klucz publiczny do known_hostsna tr-lgto. Jeśli tr-mdm chce sprawdzić, czy to jest prawdziwe tr-lgto, to tr-lgto musi wygenerować parę kluczy i dodać klucz publiczny do authorized_keystr-mdm.

Pytanie 1 : W pliku znane_hosty nie ma pola użytkownika , tylko adresy IP i nazwy hostów. tr-mdm może mieć wielu użytkowników, każdy z własnym .sshfolderem. Czy powinniśmy dodać klucz publiczny do każdego z known_hostsplików?

Pytanie 2 : Odkryłem, że ssh-keyscan -t rsa tr-mdmzwróci klucz publiczny tr-mdm. Skąd mam wiedzieć, do którego użytkownika należy ten klucz? Ponadto klucz publiczny w /root/.ssh/różni się od tego, co zwraca to polecenie. Jak to może być?

ssh security openssh key-authentication damluar
źródło

Podobne pytanie dotyczące bezpieczeństwa informacji : Jaka jest różnica między plikiem autoryzowany_klucz i znany_host dla SSH?

Gilles „SO- przestań być zły”

Dodałem trochę kontekstu dla „ssh” w odpowiedzi „O bezpiecznych plikach zawierających klucze publiczne” na pytanie wspomniane przez @Gilles: < security.stackexchange.com/questions/20706/… >

IAM_AL_X

Mieszasz uwierzytelnianie komputera serwera z komputerem klienta i uwierzytelnianie użytkownika na komputerze serwera.

Uwierzytelnianie serwera

Jedną z pierwszych rzeczy, które mają miejsce podczas nawiązywania połączenia SSH, jest to, że serwer wysyła swój klucz publiczny do klienta i udowadnia (dzięki kryptografii klucza publicznego ) klientowi, że zna powiązany klucz prywatny. Uwierzytelnia to 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ś nieuczciwy serwer próbujący podać go jako właściwy. SSH zapewnia jedynie prosty mechanizm weryfikacji legalności serwera: zapamiętuje serwery, z którymi już się łączyłeś, w ~/.ssh/known_hostspliku na komputerze klienta (istnieje również plik ogólnosystemowy /etc/ssh/known_hosts). Przy pierwszym połączeniu z serwerem musisz sprawdzić w inny sposób, czy klucz publiczny przedstawiony przez serwer jest tak naprawdę kluczem publicznym serwera, z którym chcesz się połączyć. Jeśli masz klucz publiczny serwera, z którym chcesz się połączyć, możesz ~/.ssh/known_hostsręcznie dodać go do klienta.

Uwierzytelnienie serwera należy wykonać przed wysłaniem do niego poufnych danych. W szczególności, jeśli uwierzytelnienie użytkownika wymaga hasła, hasła nie można przesyłać do nieuwierzytelnionego serwera.

Uwierzytelnianie użytkownika

Serwer pozwala zdalnemu użytkownikowi zalogować się 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 konta, na które próbuje się zalogować; serwer następnie sprawdza, 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 uwierzytelnienia serwera, ale teraz użytkownik próbuje udowodnić swoją tożsamość, a serwer je 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_keysna serwerze).
Inny rodzaj metody polega na delegowaniu części pracy związanej z uwierzytelnianiem użytkownika na maszynie klienta. Dzieje się tak w kontrolowanych środowiskach, takich jak przedsiębiorstwa, gdy wiele komputerów ma te same konta. Serwer uwierzytelnia komputer kliencki za pomocą tego samego mechanizmu, który jest używany odwrotnie, a następnie polega na kliencie w celu uwierzytelnienia użytkownika.

Gilles „SO- przestań być zły”
źródło

Dobra odpowiedź Gilles, ale moje pytanie brzmi: każdy serwer może wysłać losowy klucz publiczny i udowodnić, że ma powiązany klucz publiczny. W jaki sposób dowodzi to, że serwer jest autentyczny?

Alex

@spartacus Myślę, że miałeś na myśli „i udowodnić, że ma on powiązany klucz prywatny”, prawda? Chodzi o to, że klient wysyła losowo wygenerowaną wartość ( wyzwanie ) do serwera, a serwer dokonuje pewnych obliczeń na podstawie klucza prywatnego, który zależy od wyzwania (więc serwer nie może wykonać obliczeń, dopóki nie otrzyma tego wyzwanie) i można tego dokonać tylko ze znajomością klucza prywatnego.

Gilles „SO- przestań być zły”

Myślę, że Alex odnosi się do pierwszego połączenia klienta z serwerem. Myślę, że klient po raz pierwszy zaufa serwerowi. Następnie serwer wyśle swój klucz publiczny, a klient będzie mógł uwierzytelnić serwer dla następujących połączeń.

synack

@synack Ah, po raz pierwszy? Zamiast tego klient decyduje użytkownik („Czy na pewno chcesz kontynuować łączenie (tak / nie)?”). Serwer w tym momencie niczego nie dowodzi.

Gilles „SO- przestań być zły”

masz rację, to użytkownik podejmuje decyzję.

synack

Uwierzytelnianie oparte na kluczach SSH: znane_hosty vs autoryzowane_klucze

Odpowiedzi:

Uwierzytelnianie serwera

Uwierzytelnianie użytkownika