SSL i SSH zapewniają elementy kryptograficzne do budowy tunelu do transportu poufnych danych ze sprawdzoną integralnością. W tym przypadku używają podobnych technik i mogą cierpieć z powodu tego samego rodzaju ataków, więc powinny zapewniać podobne bezpieczeństwo (tj. Dobre zabezpieczenia), zakładając, że oba są prawidłowo zaimplementowane. To, że oba istnieją, jest rodzajem syndromu NIH: programiści SSH powinni ponownie użyć SSL dla części tunelu (protokół SSL jest wystarczająco elastyczny, aby pomieścić wiele odmian, w tym nie używać certyfikatów).

Różnią się tym, co dzieje się wokół tunelu. SSL tradycyjnie używa certyfikatów X.509 do ogłaszania kluczy publicznych serwera i klienta; SSH ma swój własny format. Ponadto SSH zawiera zestaw protokołów dla tego, co dzieje się wewnątrz tunelu (multipleksowanie kilku transferów, przeprowadzanie uwierzytelniania opartego na hasłach w tunelu, zarządzanie terminalami ...), podczas gdy w SSL nie ma czegoś takiego a dokładniej, gdy takie rzeczy są używane w SSL, nie są uważane za część SSL (na przykład podczas uwierzytelniania HTTP opartego na haśle w tunelu SSL mówimy, że jest to część „HTTPS”, ale to naprawdę działa w sposób podobny do tego, co dzieje się z SSH).

Koncepcyjnie możesz wziąć SSH i zastąpić część tunelu częścią z SSL. Możesz także wziąć HTTPS i zastąpić SSL przez SSH-with-data-transport i hook, aby wyodrębnić klucz publiczny serwera z jego certyfikatu. Nie ma naukowej niemożliwości, a jeśli zostanie wykonana prawidłowo, bezpieczeństwo pozostanie takie samo. Nie ma jednak żadnego powszechnego zestawu konwencji ani istniejących narzędzi do tego.

Więc nie używamy SSL i SSH do tych samych celów, ale to z powodu narzędzi, które historycznie pojawiały się wraz z implementacjami tych protokołów, nie z powodu różnicy związanej z bezpieczeństwem. A kto wdraża SSL lub SSH, powinien przyjrzeć się, jakiego rodzaju ataki próbowano na obu protokołach.

To nie jest rozsądne porównanie. SSL to ogólna metoda ochrony danych przesyłanych w sieci, podczas gdy SSH to aplikacja sieciowa do logowania się i udostępniania danych komputerowi zdalnemu.

Ochrona warstwy transportowej w SSH jest podobna do SSL, więc to, które jest „bezpieczniejsze”, zależy od tego, do czego odwołuje się Twój model zagrożeń i czy implementacje każdego z nich rozwiązują problemy, z którymi próbujesz sobie poradzić.

SSH ma wtedy warstwę uwierzytelniania użytkownika, której brakuje SSL (ponieważ tego nie potrzebuje - SSL musi tylko uwierzytelnić dwa łączące się interfejsy, co może również zrobić SSH). W grafice UTF-8:

  SSL SSH + ------------- + + ----------------- + | Nic | | RFC4254 | Multipleksowanie połączeń + ------------- + + ----------------- + | Nic | | RFC4252 | Uwierzytelnianie użytkownika + ------------- + + ----------------- + | RFC5246 | | RFC4253 | Szyfrowany transport danych + ------------- + + ----------------- +  

Odnośnie problemu których potencjalnych ataków jest więcej, wydaje się jasne, że SSH ma większą powierzchnię ataku. Ale to tylko dlatego, że SSH ma wbudowaną całą aplikację: powierzchnia ataku SSL + dowolnej aplikacji, którą musisz dostarczyć , nie może być porównana, ponieważ nie mamy wystarczających informacji.

Ze ścisłego kryptograficznego punktu widzenia oba zapewniają uwierzytelnione szyfrowanie, ale na dwa różne sposoby.

SSH używa tak zwanego Encrypt-and-MAC, to znaczy zaszyfrowanej wiadomości jest zestawiona z kodem uwierzytelniania wiadomości (MAC) przejrzystej wiadomości w celu dodania integralności. Nie udowodniono, że jest to zawsze w pełni bezpieczne (nawet jeśli w praktycznych przypadkach powinno wystarczyć).

SSL używa MAC-then-Encrypt: adres MAC jest zestawiony z czystym tekstem, a następnie oba są zaszyfrowane . To też nie jest najlepsze, ponieważ w przypadku niektórych trybów szyfru blokowego części MAC można odgadnąć i ujawnić coś na szyfrze. Doprowadziło to do powstania luk w zabezpieczeniach TLS 1.0 (atak BEAST).

Obie mają więc potencjalne teoretyczne słabości. Najsilniejszą metodą jest Encrypt-then-MAC (dodaj MAC zaszyfrowanej wiadomości), która jest zaimplementowana np. W IPsec ESP.

Myślę, że jest jeden aspekt tego porównania, który został przeoczony. user185 był blisko, ale nie do końca tam dotarł. Zgadzam się, że są to jabłka i pomarańcze i czuję, że lepsze jabłka do jabłek to HTTPS i SSH. HTTPS i SSH wykorzystują różne warstwy modelu OSI i dlatego szyfrują dane w różnych momentach transmisji. Wtedy prawdziwe pytania, które należałoby zadać, dotyczyłyby tego, kiedy dane te są szyfrowane i niezaszyfrowane podczas transmisji. To ujawni potencjalne powierzchnie ataku. W przypadku protokołu HTTPS, gdy pakiet zostanie odebrany przez urządzenie w sieci docelowej (serwer WWW, router Border, system równoważenia obciążenia itp.), Jest on niezaszyfrowany, a resztę podróży spędza w postaci zwykłego tekstu. Wielu twierdzi, że nie jest to wielka sprawa, ponieważ ruch jest w tej chwili wewnętrzny, ale jeśli ładunek zawiera poufne dane, jest przechowywany w postaci niezaszyfrowanej w plikach dziennika każdego urządzenia sieciowego, przez które przechodzi, dopóki nie dotrze do ostateczny cel. W przypadku protokołu SSH zwykle określa się urządzenie docelowe, a transmisja jest szyfrowana, dopóki nie dotrze do tego urządzenia. Istnieją sposoby ponownego zaszyfrowania danych HTTPS, ale są to dodatkowe kroki, o których większość zapomina podczas implementacji rozwiązania HTTPS w swoim środowisku.

ssh jest jak klucz (prywatny), a zamek (publiczny)

ssl jest jak drzwi i cegły.

ssl zapewnia bezpieczne połączenie między dwoma serwerami komputerowymi . np. Twój i ten, z którym się łączysz.

ssh to sposób, w jaki łączący się komputer może zweryfikować się i uzyskać dostęp.

SSL to warstwa protokołu wyodrębniona z tunelowanej treści. SSH to bezpieczna wersja powłoki (SH), nie została zaprojektowana do umieszczania pod nią warstwy abstrakcyjnej, została zaprojektowana specjalnie do przenoszenia ruchu powłoki. Więc chociaż operacje kryptograficzne są używane w obu przypadkach, a te operacje kryptograficzne mogą być nawet takie same, cel i ogólny projekt są zupełnie inne.

Należy pamiętać, że istnieją pewne różnice (jak wspomniano powyżej ), ale większość, jeśli nie wszystkie, różnice wynikają z przeznaczenia różnych protokołów.

Problem jest dwojaki, nie chodzi tylko o siłę i słabość szyfrowania. Ale to łatwość i wygoda dostawy. Z punktu widzenia biznesu SSL / TLS jest więc wygodniejszy i łatwiejszy, ponieważ wymaga tylko przeglądarki i publicznego lub prywatnego certyfikatu.

A SSH wymaga zainstalowania aplikacji lub cienkiego klienta, aby z niego korzystać. Jest to większy problem z punktu widzenia i obsługi klienta internetowego użytkownika.

Jeśli naprawdę szukasz połączenia SSH z SSL (TLS), odpowiedzią jest SSH.

Jednym z powodów, dla których SSH wygrywa nad SSL, jest sposób przeprowadzania uwierzytelniania. Z tego powodu podczas korzystania z FTP należy używać protokołu SSH (SFTP) zamiast FTPS (FTP przez SSL).

SSH jest używany w sieciach korporacyjnych do:

• zapewnienie bezpiecznego dostępu dla użytkowników i zautomatyzowanych procesów
• interaktywne i automatyczne przesyłanie plików
• wydawanie poleceń zdalnych

źródło: https://www.ssh.com/ssh/protocol/#sec-Typical-uses-of-the-SSH-protocol