Forum Debian Users Gang

Kawałek cytatu z wykładu o szyfrowaniu:

Idea działania SSH jest zbliżona do PGP, tyle że właścicielem klucza nie jest osoba, ale komputer. Każdy z komputerów, na których zainstalowany jest program SSH posiada własną parę kluczy - klucz prywatny, możliwy do odczytania wyłącznie przez administratora systemu (i program demona usługi ssh,), oraz klucz publiczny, który jest ogólnie dostępny dla wszystkich użytkowników, a za pomocą protokołu SSH także dla innych komputerów w sieci.
Działanie
Po nawiązaniu połączenia automatycznie tworzony jest kodowany kanał powodujący przekazywanie połączeń na maszynę, z której nastąpiło połączenie. Ponadto użytkownik może sam tworzyć dowolne bezpieczne (kodowane) kanały pomiędzy dowolnymi (nieużywanymi) portami obu komputerów.
Pierwszymi przesyłanymi danymi jest klucz publiczny serwera. Jeżeli ma to miejsce pierwszy raz (tzn. klient jeszcze nigdy nie łączył się z tym serwerem), to klucz jest po prostu zapamiętywany w pliku użytkownika programu ssh po stronie klienta. Jeżeli nie jest to pierwsze połączenie, to otrzymany klucz jest porównywany z kluczem zapamiętanym wcześniej. Jeżeli klucz jest inny, oznacza to najprawdopodobniej, że w rzeczywistości połączyliśmy się z innym systemem. Zgodność kluczy jeszcze niczego nie dowodzi, bo klucz publiczny jest powszechnie znany i można go "ukraść" bez problemu.
Teraz następuje drugi etap autoryzacji. Klient ssh generuje losowo liczbę 32-bitową, która będzie używana do kodowania całej dalszej transmisji. Liczba ta zostaje zakodowana kluczem prywatnym klienta oraz kluczem publicznym serwera i dopiero w takiej postaci przesłana do serwera. Do odkodowania przesyłki serwer musi dysponować swoim kluczem prywatnym oraz kluczem publicznym klienta. Poprawne rozkodowanie przesłanej liczby pozwala stwierdzić, że obie strony biorące udział w wymianie informacji są rzeczywiście tymi, za które się podają. Po upewnieniu się, co do "tożsamości" hostów następuje autoryzacja użytkownika. Teraz może nastąpić bezpieczna wymiana strumienia danych.
Algorytmem używanym do szyfrowania strumienia danych może być jeden z popularnych szyfrów symetrycznych, np. IDEA, 3DES. Do zaszyfrowania klucza szyfru symetrycznego służy podobnie jak w PGP algorytm RSA lub DH. Użycie SSH zabezpiecza między innymi przed popularnym ostatnio, zwłaszcza w środowiskach akademickich, przechwytywaniem na drodze sniffingu haseł.

ad.1 - tak każdy klient i serwer ma inny klucz prywatny;

ad.2 -  najpierw wstęp: klucz publiczny i prywatny stanową parę, wiadomość zakodowaną kluczem publicznym można odkodować kluczem prywatnym i odwrotnie - zakodowaną kluczem prywatnym można odkodować kluczem publicznym

przebieg połączenia:

1. klient łączy się z serwerem dostaje od niego klucz publiczny
2. kucz ten porównywany jest przez klienta z kluczem otrzymanym w poprzedniej sesji - aby wykryć ew. zmianę klucza - nieistotne ;-)
3. klient wysyła serwerowi swój klucz publiczny, generuje losową liczbę i koduje ją kluczem swoim kluczem prywatnym i publicznym serwera
zwróć uwagę na kolejność kodowania kluczami

liczbę tą można rozkodować wyłącznie w przy pomocy klucza prywatnego serwera (serwer go ma) a następnie klucza publicznego klienta (serwer dostał od klienta) znów odpowiednia kolejność użycia kluczy

nie da się rozkodować liczby przez odwrotne użycie kluczy - najpierw publiczego klienta a potem prywatnego serwera

Czadman, klucze są sprzężone w obie strony. To znaczy że jak coś "zaszyfrujesz" kluczem publiczym, to możesz "odszyfrować" tylko odpowiednim kluczem prywatnym.

Jeśli natomiast coś "zaszyfrujesz" kluczem prywatnym to możesz to "odszyfrować" tylko odpowiednim kluczem publicznym. I właśnie na tym polega podpis cyfrowy. Tylko Ty możesz podpisać dane (bo tylko Ty masz klucz prywatny), a każdy (ściślej mówiąc każdy, kto posiada twój klucz publiczny) może zweryfikować podpis (czyli de-faco odszyfrować). Wskazałeś ssh(1), przeczytaj dokładnie początek. Jest tam o autoryzacji.

nie

jesli chcesz wysłać zaszyfrowanego maila do Basi, to szyfrujesz go jej kluczem publicznym. rozszyfrowac go może tylko ona, za pomocą swojego klucza prywatnego.

Czadman, klucze są sprzężone w obie strony. To znaczy że jak coś "zaszyfrujesz" kluczem publiczym, to możesz "odszyfrować" tylko odpowiednim kluczem prywatnym.

Nie twierdziłem, że klucze nie są sprzężone, wręcz przeciwnie.  Przeczytaj proszę dokładnie moją wypowiedź. Może faktycznie popełniam jakiś błąd?

Jeśli natomiast coś "zaszyfrujesz" kluczem prywatnym to możesz to "odszyfrować" tylko odpowiednim kluczem publicznym. I właśnie na tym polega podpis cyfrowy. Tylko Ty możesz podpisać dane (bo tylko Ty masz klucz prywatny), a każdy (ściślej mówiąc każdy, kto posiada twój klucz publiczny) może zweryfikować podpis (czyli de-faco odszyfrować). Wskazałeś ssh(5), przeczytaj dokładnie początek. Jest tam o autoryzacji.

Nie twierdziłem nic przeciwnego, poza tym, że położyłem nacisk na błędnie rozumowanie "podwójnego szyfrowania". Moc kryptografi asymetrycznej polega na tym, że kluczem publicznym nie da się nic odszyfrować lub się nie odszyfrowywuje. W manie ssh jest napisanie, że autoryzacja jest oparta na asymetrycznym algorytmie szyfrowania RSA, króry wyraźnie mówi, że nie szyfruje się kluczem prywatnym samej wiadomości, co sugerują powyższe wypowiedzi, lecz jej hasz + ustalone bity i ma to kluczowe znaczenie dla bezpieczeństwa algorytmu. Czyli jest to de facto odszyfrowywanie, i tu zwaracam honor, ale de facto spreparowanego przez podpisującego pakietu i porównanie go ze spreparowanym przez weryfikującego.

Dodam jeszcze, że słowo "kodowany" niewiele tu nie znaczy, można coś kodować alfabetem morsa i to nie znaczy, że się szyfruje.

Pozdrawiam.

Czadman jestes MEGA! wszedzie w necie bylo to opisane w dziwny nieprecyzyjny sposób(i myslalem ze te klucze prywatne i publiczne nic do siebie nie maja).
Lecz bez pytania sie nie obejdzie :)

- klient musi umieścić fizycznie swój klucz publiczny w odpowiednim pliku w katalogu domowym na zdalnej maszynie (sposobem innym niż przez ssh)

To jak w takim razie zalogowac sie poraz pierwszy (w sposób bezpieczny)jezeli nie umiesci sie tam tego klucza?

To jak w takim razie zalogowac sie poraz pierwszy (w sposób bezpieczny)jezeli nie umiesci sie tam tego klucza?

Jakkolwiek, przecież klucz publiczny jest tak naprawdę nieważny jeżeli chodzi o bezpieczeństwo, więc możesz go nawet wysłać z życzeniami powodzenia do tego, kto chce Cię odszyfrować :) Przynajmniej ja to tak rozumiem. I przypuszczam, że klient/serwer ssh przesyła ten kod i załatwia sprawę umieszczenia go w odpowiednim pliku.

To jak w takim razie zalogowac sie poraz pierwszy (w sposób bezpieczny)jezeli nie umiesci sie tam tego klucza?

Jakkolwiek, przecież klucz publiczny jest tak naprawdę nieważny jeżeli chodzi o bezpieczeństwo, więc możesz go nawet wysłać z życzeniami powodzenia do tego, kto chce Cię odszyfrować :) Przynajmniej ja to tak rozumiem. I przypuszczam, że klient/serwer ssh przesyła ten kod i załatwia sprawę umieszczenia go w odpowiednim pliku.

Zgadza się, polecenie ssh-copy-id, nie mniej jednak wymaga włączonej autoryzacji hasłem na serwerze.

Przeczytaj proszę dokładnie moją wypowiedź. Może faktycznie popełniam jakiś błąd?

Trochę niejasno napisałem i nie wiesz o co mi chodzi. :) Chodzi mi o to:

W uproszczeniu wygląda to talk:
- klient musi umieścić fizycznie swój klucz publiczny w odpowiednim pliku w katalogu domowym na zdalnej maszynie (sposobem innym niż przez ssh)
- klient wysyła swój klucz publiczny (po sprawdzeniu czy połączył się z właściwym serwerem) i serwer porównuje go z listą tych co znajdują się na serwerze
- jeśli ten klucz jest, czyli użytkownik może się autentykować, to serwer wysyła klientowi "wyzwanie" (ponieważ, każdy może wejść w posiadanie klicza publicznego), szyfruje losową liczbę kliczem publicznym klienta i wysyła ją do klienta
- klient odbiera zakodowaną liczbę, odszyfrowuje ją swoim prywatnym kluczem (udowadniając, że go zna), następnie tę odkodowaną liczbę szyfruje kluczem publicznym serwera, podpisuje swoim prywatnym i odsyła,
- serwer odkodowywuje liczbę swoim kluczem prywatnym i weryfikuje podpis kluczem publicznym klienta, następnie porównuje liczbę z tą wysłaną do klienta, jeśli się zgadza to wpuszcza klienta.

Zwróć uwagę że klient nie ma dwóch par kluczy. Ma ~/.ssh/id_dsa, ~/.ssh/id_dsa.pub, lub w przypadku RSA ~/.ssh/id_rsa i ~/.ssh/id_rsa.pub. Klient podpisuje (a więc szyfruje) kluczem ~/.ssh/id_dsa (~/.ssh/id_rsa), a serwer weryfikuje (a więc odszyfrowuje "wyzwanie") kluczem publicznym.

W którym miejscu piszę o tym, że klient posiada dwie pary kluczy? Albo z jakiego fragmentu to może wynikać? Przekręciłem tylko jedno, powinno być: "najpierw podpisuje potem szyfruje kluczem publicznym serwera".

Zatem:
- Jeśli zaszyfrujesz dane kluczem publicznym - możesz je odszyfrować tylko (odpowiednim temu kluczowi publicznemu) kluczem prywatnym.
- Jeśli zaszyfrujesz dane kluczem prywatnym (nazywamy to właśnie podpisem, i cały czas mówimy o ~/.ssh/id_dsa / ~/.ssh/id_rsa) - to możesz odszyfrować tylko odpowiednim kluczem publicznym.
Jak widzisz można szyfrować kluczem prywatnym i odszyfrować, odpowiadającym mu, kluczem publicznym. I właśnie to nazywamy podpisem. To, który klucz z pary uznamy za prywatny, a który za publiczny, zależy tylko od umowy.

Zwróciłem honor w jednym z postów powyżej, z zastrzeżeniem. :)
W RSA nie podpisuje się wiadomości szyfrując ją, lecz jej hasz + ustalone bity po to aby utrudnić generowania podpisów losowych wiadmości.
Być może openssh nieco inaczej implementuje protokół, ale w manach o tym nie ma.
http://pl.wikipedia.org/wiki/RSA_%28kryptografia%29

Na koniec chciałbym dodać, że cały wątek był dla mnie bardzo pouczający. :)