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

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

Dupe z superuser.com/questions/962918/... i (cross) unix.stackexchange.com/questions/247612/…

— dave_thompson_085

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:

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

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

@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

Moje dwa centy

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

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

Następnie skopiuj nowy klucz publiczny (do schowka)
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
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

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ć ;-)

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