Klucze SSH DSA nie działają już w przypadku uwierzytelniania bez hasła

25

Po aktualizacji do Fedory 23 uwierzytelnianie bez hasła (oparte na kluczu publicznym) nie działa już w SSH: podczas próby połączenia się z SSH do jakiegoś hosta, monituje o moje hasło na hoście zdalnym. Nie mogę zmusić go do używania mojego prywatnego klucza SSH. Wszystko działało dobrze z Fedorą 22.

Mój klucz publiczny to klucz DSA ( ~/.ssh/id_dsa.pub). Używam OpenSSH 7.1 ( openssh-7.1p1-5.fc23.x86_64).

Jak uzyskać uwierzytelnianie bez hasła, aby znów działało poprawnie?

DW
źródło
1
Dzięki, @ dave_thompson_085. To nie jest duplikat superuser.com/q/962918/93541 . To pytanie dotyczy sposobu użycia ssh -Q. To pytanie, jak rozwiązać problem z SSH. Znalazłem niektóre materiały na stronie superuser.com/q/962918/93541 i gdzie indziej pomocne w identyfikacji tego rozwiązania, ale tam odpowiedź opisuje sposób korzystania ssh -Qi nie odpowiada na to pytanie (np. Nie wyjaśnia, jak to naprawić ten problem), więc moim zdaniem nie jest to duplikat. Ten w Unixie i Linuksie jest bardzo podobny; Chciałbym to wcześniej zobaczyć. Jeszcze raz dziękuję za linki!
DW
Ack, masz rację. Kazałem je dodać do zakładek jako „OpenSSH 7.0 bez DSA”, co w pierwszym przypadku nie jest wystarczająco blisko. Przepraszam.
dave_thompson_085

Odpowiedzi:

40

Jest to wynikiem aktualizacji do OpenSSH 7.0. Jak podają informacje o wydaniu OpenSSH 7.0 , „Obsługa kluczy hosta i użytkownika ssh-dss jest domyślnie wyłączona w czasie wykonywania”.

Rozwiązaniem jest dodanie następującego wiersza ~/.ssh/configna każdym komputerze klienckim (na każdym komputerze, na którym działa klient SSH):

PubkeyAcceptedKeyTypes=+ssh-dss

Jeśli serwer używa OpenSSH 7.0 lub nowszego, musisz również dodać ten wiersz /etc/ssh/sshd_configna każdym serwerze.

Alternatywnie możesz wygenerować całkowicie nowy klucz SSH i dodać go do pliku uprawnionego_kluczy na każdym serwerze, na którym kiedykolwiek chcesz się zalogować. Polecam używać RSA , aby uniknąć problemów z kompatybilnością. Nie polecam ECDSA, ponieważ najwyraźniej gnom- klucz -demon nie odbiera automatycznie kluczy SSH typu ECDSA.


Uwaga redakcyjna: Dlaczego ludzie OpenSSH wyłączyli klucze DSA? Nie wiem O ile jestem w stanie stwierdzić, nie ma nic złego w bezpieczeństwie kluczy DSA (ssh-dss). Strona internetowa OpenSSH twierdzi, że ssh-dss jest słaby, ale o ile mi wiadomo, 1024-bitowy ssh-dss nie jest słabszy niż 1024-bitowy RSA, a 1024-bitowe klucze RSA nie są wyłączone.

DW
źródło
1
Wybór rodzaju klucza jest omawiany przez pewien czas w Security . Bezpieczeństwo kluczy DSA jest od samego początku wątpliwe i mniej bezpieczne, jeśli nie masz dobrego generatora losowego (czego nie możesz mieć pewności). A ponieważ teraz istnieją inne możliwe typy kluczy do użycia, nie ma powodu, aby zachować te wątpliwe.
Jakuje
2
@Jakuje tak, klawisz wyboru typu omówiono na temat bezpieczeństwa informacji tutaj i tutaj . Przeczytałem to wszystko przed napisaniem uwagi redakcyjnej i zastanawiam się, dlaczego klucze DSA zostały wyłączone: nie są słabsze niż klucze RSA o tej samej długości, które nie zostały wyłączone. W żadnym z tych wątków nie ma nic, co wskazywałoby, że DSA jest „wątpliwe”, a jak mówi Thomas Pornin, „nie ma żadnego powodu związanego z bezpieczeństwem, aby preferować jeden typ nad drugim, zakładając, że wystarczająco duże klucze”. (ciąg dalszy)
DW
Zobacz tutaj, aby uzyskać bardziej szczegółową dyskusję.
DW
0

Moje dwa centy

Sugeruję, ponieważ edytowanie .ssh/configpliku, aby to umożliwić, wydaje się niezbyt dobrym pomysłem

  1. Utwórz nowy klucz, używając najnowszego narzędzia.

    Następnie skopiuj nowy klucz publiczny (do schowka)

  2. Zaloguj się ostatni raz , używając starego klucza:

    ssh -i .ssh/id_dsa.pub -o PubkeyAcceptedKeyTypes=+ssh-dss user@host
    

    Następnie uaktualnić @host„s authorized_keysplik, dodając nowe pubkey i wylogowanie

    cat >>.ssh/authorized_keys
    

    paste, a następnie Ctrl+D

  3. Zaloguj się przy użyciu nowego klucza, używając domyślnej składni:

    ssh user@host
    
    1. Następnie uaktualnić @host„s authorized_keysplik, przez usunięcie stary pubkey (używam sed -e 1d -i .ssh/authorized_keyskiedy mój stary pubkey jest na linii 1tego pliku).

    2. Sugeruję uaktualnić serwer ssh, jeśli możesz.

    3. Wyloguj
  4. Sprawdź, czy stary klucz już nie działa.

    ssh -i .ssh/id_dsa.pub -o PubkeyAcceptedKeyTypes=+ssh-dss user@host
    ...
    Permission denied...
    

    To nie musi działać ;-)

  5. Możesz nawet ponownie sprawdzić, czy wszystko jest w porządku:

    ssh user@host uptime
    
F. Hauri
źródło
Nie jest dla mnie oczywiste, dlaczego uważasz, że edycja ~/.ssh/confignie jest tak dobrym pomysłem.
DW,
Ponieważ jest to przestarzałe, a ssh autor poleca nie używać. Patrz openssh.com/legacy.html
F. Hauri
Och, rozumiem. Wygląda na to, że twoja troska nie dotyczy samego edytowania, ~/.ssh/configale raczej zgody na DSA. Dziękuję za wyjaśnienie. To ma sens. (Myślę, że już odpowiedziałem w mojej odpowiedzi i komentarzach, dlaczego uważam to zalecenie za zastanawiające, ale nie będę próbował tutaj o tym dyskutować.)
DW
Edycja .configpozwala na wykonywanie sshprzez długi czas, a nawet mgliste, że używasz słabego algorytmu. Korzystając -o Pubkey...z wiersza poleceń, nie wybaczysz, że jest coś do uaktualnienia .
F. Hauri