Jaka jest różnica między kluczem openssh a kluczem szpachlowym?


48

Odkryłem, że ssh-keygen(pakiet „ssh”) produkuje różne klucze z puttygen(pakiet „putty”).

Jeśli utworzę klucze publiczne i prywatne z ssh-keygenniektórymi serwerami ssh, nie zaakceptuję moich kluczy. Jeśli utworzę klucze z puttygentylko jednym serwerem, zaakceptuje to.

Dlaczego repozytoria linuksowe nie proponują jakiegoś wspólnego rozwiązania (pakietu)? Znalazłem inny pakiet ssh-3.2.9.1, który tworzy klucze działające z kitem. Ale dlaczego nie ma przydatnego rozwiązania w SSH?


1
Na początek PuTTYGen oferuje jawnie konwersję kluczy. Zatem rodzime formaty używane przez OpenSSH i PuTTY do przechowywania kluczy są różne. Jednak obsługiwane algorytmy są kompatybilne. Domyślam się, że wpisałeś jakąś funky wartość w polu, która pozwala podać liczbę bitów (np. DSA wydaje się wymagać 1024 bitów) dla wygenerowanego klucza w PuTTYGen lub alternatywnie wybrałeś coś takiego jak RSA-1 które większość serwerów wyłączy obecnie. Niestety, pytanie tak naprawdę nie określa tego, czego próbowałeś i czego oczekiwałeś.
0xC0000022L

Odpowiedzi:


47

OpenSSH jest de facto standardową implementacją protokołu SSH. Jeśli PuTTY i OpenSSH różnią się, to PuTTY jest tym, który jest niezgodny.

Jeśli wygenerujesz klucz za pomocą OpenSSH przy użyciu ssh-keygendomyślnych opcji, będzie on działać z praktycznie każdym serwerem. Serwer, który nie akceptuje takiego klucza, byłby zabytkowy, wykorzystywałby inną implementację SSH lub skonfigurowany w dziwny, restrykcyjny sposób. Klucze innego typu niż domyślne mogą nie być obsługiwane na niektórych serwerach, w szczególności klucze ECDSA sprawiają, że ustanawianie sesji jest nieco szybsze, ale są obsługiwane tylko przez najnowsze wersje OpenSSH.

PuTTY używa innego formatu pliku klucza. Zawiera narzędzia do konwersji między własnym .ppkformatem a formatem OpenSSH.

Ten ssh-3.2.9.1, który znalazłeś, jest produktem komercyjnym, który ma swój własny inny format klucza prywatnego. Nie ma powodu, aby używać go zamiast OpenSSH, może być tylko mniej kompatybilny, wymaga płacenia i jest około zero samouczka, jak go używać.


24

Większość dystrybucji Linuksa jest puttydostępna dla Linuksa. Możesz zainstalować puttypo stronie Linuksa i użyć puttygendo konwersji plików .ppk do zwykłych plików kluczy w stylu ssh (zwanych plikami PEM - nawet jeśli nie mają nazwy .pem w nazwie pliku).

puttygen id_dsa.ppk -O private-openssh -o id_dsa

UWAGA: Możesz także użyć puttygendo importowania plików PEM w stylu ssh z powrotem do putty.

Autor PuTTY zdecydował się na prostotę, aby klucze publiczne i prywatne, które składają się na podstawowe zabezpieczenia używane przez uwierzytelnianie za pomocą klucza putty / ssh 2, były przechowywane w jednym zastrzeżonym pliku .ppk. Zazwyczaj klucze te są obsługiwane przez ssh jako 2 oddzielne pliki.

W systemie Linux pliki kluczy są zwykle przechowywane w katalogu .ssh.

W tym pytaniu dotyczącym przepełnienia stosu znajduje się dobry przegląd procesu konwersji: Konwertuj PEM na format pliku PPK .

Autor putty również omawia swoje uzasadnienie wykorzystania plików .ppk w puttypodręczniku użytkownika . Możesz przeczytać o tym tutaj w sekcji 8.2.12.


Czy masz na myśli, że mój Linux ma przestarzały i podatny na ataki SSH-1 (jeśli nie używam szpachli)? Czy to jest niedrogie? Luki w zabezpieczeniach SSH-1 opisano w Wikipedii
YarLinux

Nie jestem pewien, skąd to masz. Nie, powinieneś być w porządku. Jakiej wersji systemu Linux używasz? Jakiego Linuxa używasz? Wykonaniu tego polecenia, aby dowiedzieć się wersję systemu Linux: uname -a. Linux distro: lsb_release -a.
slm

Używam Ubuntu 12.04. Czy masz na myśli, że SSH-2 ma różne formaty? Właśnie pomyliłem nazwę pakietu i polecenie, które „ssh”.
YarLinux

Widzę. Narzędzie ssh, o którym mówisz, jest zwykle częścią pakietu o nazwie openssh. Wersja tego oprogramowania nie ma nic wspólnego z SSH-1 i SSH-2, o których mowa. Ta terminologia (SSH-1 i SSH-2) odnosi się do typu pliku klucza, z którym pracujesz. Ten typ pliku nie powinien być dla ciebie problemem, o ile korzystasz z najnowszych wersji openssh.
slm

Czy istnieją trzy różne formaty kluczy? OpenSSH, ssh.com i PuTTY?
YarLinux

12

Oba przechowują „parę kluczy RSA dla wersji 2 protokołu SSH” i można je zamieniać zamiennie; jednak w odniesieniu do faktycznej przechowywanej różnicy formatu:

z https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/key-formats-native.html

Zalety formatu klucza PuTTY to:

  • Publiczna połowa klucza jest przechowywana w postaci zwykłego tekstu . Format klucza prywatnego OpenSSH szyfruje cały plik klucza , więc klient musi poprosić cię o hasło, zanim będzie mógł cokolwiek zrobić z kluczem. W szczególności oznacza to, że musi poprosić o hasło, zanim będzie mógł zaoferować serwerowi klucz publiczny w celu uwierzytelnienia. Format PuTTY przechowuje klucz publiczny w postaci zwykłego tekstu i szyfruje tylko połowę prywatną, co oznacza, że ​​może on automatycznie wysłać klucz publiczny do serwera i ustalić, czy serwer jest skłonny zaakceptować uwierzytelnienia za pomocą tego klucza, i zawsze poprosi tylko o hasło, jeśli to naprawdę konieczne.

    Myślę, że OpenSSH przeczyta.pubplik do tego celu, jeśli pojawia się obok pliku klucza prywatnego, ale jest to źródłem zamieszania tak często, jak dla wygody (widziałem, jak ludzie zastępują plik klucza prywatnego i pozostawiają nieaktualne .pubobok niego, a następnie bardzo mylony przez wynikowy proces uwierzytelniania SSH!).
  • Klucz jest w pełni zabezpieczony przed manipulacją. Formaty kluczy, które przechowują klucz publiczny w postaci zwykłego tekstu, mogą być podatne na atak sabotażowy, w którym publiczna połowa klucza jest modyfikowana w taki sposób, że podpisy wykonane za pomocą udokumentowanych informacji o wycieku klucza o prywatnej połowie. Z tego powodu format klucza PuTTY zawiera kod MAC (Message Authentication Code), wyłączony z hasła i obejmujący publiczne i prywatne połówki klucza.W ten sposób zapewniamy wygodę posiadania klucza publicznego dostępnego w postaci zwykłego tekstu, ale jednocześnie natychmiast wykrywamy każdą próbę ataku sabotażowego, dając połączenie bezpieczeństwa i wygody, które nie uważam za możliwe w jakimkolwiek innym formacie klucza. Dodatkową korzyścią jest to, że MAC obejmuje również komentarz klucza, zapobiegając wszelkim możliwym psotom, które mogłyby wystąpić, gdyby ktoś zamienił dwa klucze i wymienił komentarze.

    Podejście OpenSSH do utrzymywania zaszyfrowanego klucza publicznego możezapewniają również pewne zabezpieczenia przed tego rodzaju atakami, ale nie jest jasne, czy zapewnia odpowiednią ochronę: szyfrowanie zaprojektowane z myślą o poufności często pozostawia sposoby, w jakie zaszyfrowane dane mogą być użytecznie zmodyfikowane przez atakującego. Dla prawdziwej ochrony integralności potrzebujesz prawdziwego dedykowanego MAC, który został zaprojektowany właśnie do tego.

[ podkreślenie dodane]

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.