2011-07-05 13 views
7

Zdaję sobie sprawę, że to pytanie jest subiektywne.SSH: Czy podczas logowania hasło to zwykły tekst/sniffable?

Ciekawi mnie zrozumiałość hasła SSH po utworzeniu tunelu SSH. Czy bezpieczna sesja rozpoczyna się po uwierzytelnieniu hasła lub czy samo hasło jest hermetyzowane w tym bezpiecznym połączeniu?

Po interesującej debacie w biurze dziś rano i oprócz możliwości złamania hasła SSH na kliencie z keyloggerem, jestem ciekawy, że hasło SSH może również zostać naruszone za pomocą wąchania pakietów narzędzia w sieci LAN lub zainstalowane na dowolnym proxy między klientem a serwerem. To otworzyło szerszą debatę na temat mądrości logowania do prywatnych usług (takich jak domowy NAS lub e-mail) przez tunel SSH, podczas gdy zalogowano się do klienta działającego za/pośrednim proxy/ami. (np. w pracy), szczególnie z twierdzeniami, że narzędzia takie jak Ettercap są w stanie szpiegować w pakiety SSH.

Zakładam, że te same uwagi można rozważyć w przypadku protokołu SSL/HTTPS, gdy witryna nie analizuje hasła w jednokierunkowy skrót, taki jak MD5?

Twoje rozważania będą najbardziej docenione.

Dzięki.

+3

To nie jest pytanie programistyczne. – Raoul

+1

Jeśli chodzi o HTTPS, są podobne pytania: http://stackoverflow.com/questions/3911906/encrypting-http-post-data/3923617#3923617 i http://stackoverflow.com/questions/3837989/sending-sensitive-data -as-a-zapytanie-string-parametr/3840144 # 3840144. Całe żądanie wysyłane jest za pośrednictwem protokołu SSL/TLS (w tym ścieżka żądania, nagłówki i treść). Transmisja hasła jest chroniona, nawet jeśli jest wysłana w sposób jasny (za pośrednictwem formularza lub HTTP Basic). – Bruno

+0

Powinienem wyjaśnić, co właśnie powiedziałem: "Transmisja hasła jest chroniona, nawet jeśli jest wysłana w jasny sposób", przez to rozumiem, nawet jeśli hasło nie jest szyfrowane w warstwie aplikacji (uwierzytelnianie HTTP Basic jest po prostu kodowanie i hasła wpisane w formularzach są wysyłane w postaci danych formularza). Efektywnie nie jest wysyłany w sposób jasny, właśnie dlatego, że wszystko odbywa się za pośrednictwem protokołu SSL/TLS (jak zwykle, jeśli są używane odpowiednie zestawy algorytmów szyfrowania). – Bruno

Odpowiedz

15

Fragment z podręcznika z OpenSSH:

Wreszcie, jeśli inne metody uwierzytelniania nie, ssh prosi użytkownika o podanie pass słowa. Hasło jest wysyłane do zdalnego hosta w celu sprawdzenia; Jednak ponieważ wszystkie komunikaty są zaszyfrowane, hasła nie będą widoczne dla osób słuchających w sieci.

5

SSH nie ma nazwy "Secure Shell" bez powodu :).

SSH używa kryptografii z kluczem publicznym do uwierzytelniania, która sama w sobie jest dość bezpieczna. Jeśli założymy, że atakujący nie ma prywatnych kluczy użytkownika i demona ssh - hasło nie może zostać zdekodowane jedynie przez słuchanie w sieci.

Ten protokół, podobnie jak większość innych, nie chroni przed atakami z innych stron. Istnieje kilka kombinacji inżynierii społecznej i człowiek w środkowych atakach, takich jak the SSH version downgrading attack i DNS Spoofing attack.

Powiązane problemy