Dlaczego uwierzytelnianie za pomocą hasła SSH stanowi zagrożenie bezpieczeństwa?

68

Większość poradników dotyczących konfiguracji OpenSSH zaleca wyłączenie uwierzytelniania hasła na rzecz uwierzytelniania opartego na kluczach. Ale moim zdaniem uwierzytelnianie hasłem ma znaczącą zaletę: możliwość łączenia się z dowolnego miejsca bez klucza. Jeśli jest używane zawsze z silnym hasłem, nie powinno to stanowić zagrożenia bezpieczeństwa. A może powinien?

Septagram
źródło
2
Hasła to jednoetapowe uwierzytelnianie, które można wąchać, zgadywać i odtwarzać ponownie. Klucze są (prawdopodobnie) dwuskładnikowe. Możliwość logowania z dowolnego miejsca za pomocą tylko jednego czynnika jest niedopuszczalna w niektórych systemach.
Alex Holst

Odpowiedzi:

25

Istnieją zalety i wady uwierzytelniania opartego na kluczu lub pw.

W niektórych przypadkach, na przykład, uwierzytelnianie oparte na kluczach jest mniej bezpieczne niż uwierzytelnianie za pomocą hasła. W innych przypadkach jest oparty na PW, co jest mniej bezpieczne. W niektórych przypadkach jeden jest wygodniejszy, w innych mniej.

Wszystko sprowadza się do tego: gdy wykonujesz uwierzytelnianie oparte na kluczach, musisz zabezpieczyć swój klucz hasłem. O ile nie masz uruchomionego ssh-agent (ssh-agent uwalnia cię od wpisywania hasła za każdym razem), nie zyskałeś nic pod względem wygody. Bezpieczeństwo jest dyskusyjne: wektor ataku został teraz przeniesiony z serwera na Ciebie, na twoje konto lub na osobistą maszynę, (...) - te mogą być łatwiejsze do złamania.

Decydując się na to, wyjdź poza pole. To, czy zyskasz, czy stracisz pod względem bezpieczeństwa, zależy od reszty środowiska i innych środków.

edycja: Och, właśnie zobaczyłem, że mówisz o serwerze domowym. Byłem w tej samej sytuacji, „hasło” lub „pamięć USB z kluczem” zawsze ze mną? Poszedłem do tego pierwszego, ale zmieniłem port nasłuchiwania SSH na coś innego niż 22. To powstrzymuje wszystkie te słabe dzieciaki skryptów brutalnie wymuszając całe zakresy sieci.

rzymski
źródło
W wielu przypadkach zmiana portu SSH z 22 może nie być dobrym pomysłem. adayinthelifeof.nl/2012/03/12/…
Tymek
75

Używanie kluczy ssh ma jedną unikalną funkcję w porównaniu do logowania za pomocą hasła: możesz określić dozwolone polecenia. Można to zrobić, modyfikując ~/.ssh/authorized_keysplik na serwerze.

Na przykład,

command="/usr/local/bin/your_backup_script.sh", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

pozwoli tylko komenda `/usr/local/bin/your_backup_script.sh" z tym konkretnym kluczem.

Możesz także określić dozwolone hosty dla klucza:

from="yourclient,yourotherclient", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

Lub połącz dwa:

from="yourbackupserver", command="/usr/local/bin/your_backup_script.sh", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

Za pomocą kluczy możesz także przyznać tymczasowy dostęp do jakiegoś użytkownika (powiedzmy konsultanta) do serwera bez ujawniania hasła do tego konkretnego konta. Po zakończeniu pracy konsultanta klucz tymczasowy można usunąć.

Janne Pikkarainen
źródło
Bardzo, bardzo przydatna wskazówka.
Sachin Divekar
3
Co więcej, używanie Kluczy jest jak posiadanie długiego 2000-znakowego hasła (technicznie jego jeszcze większa siła) w porównaniu z tym, co można wpisać ręcznie w terminalu: D
Abhishek Dujari 24.11.11
3
Dwie bardzo przydatne wskazówki na temat uwierzytelniania SSH, ale tak naprawdę nie odpowiadają mi pytanie ...
MikeMurko,
Jeśli chcesz zmusić użytkownika uwierzytelnionego hasłem do wykonania określonego polecenia, zmień jego powłokę logowania. Również „udzielanie tymczasowego dostępu bez ujawnienia hasła” jest bardzo złym pomysłem. Istnieją setki różnych sposobów na zachowanie dostępu na później.
b0fh
Sam ostatni akapit odpowiada na pytanie IMO - klucze pozwalają na szczegółowe odwołanie, a przy hasłach musisz poinformować wszystkich, że je zmieniasz.
Riking
48

Możesz uzyskać to, co najlepsze z obu światów, zezwalając tylko na uwierzytelnianie za pomocą hasła z sieci. Dodaj następujące na końcu sshd_config:

PasswordAuthentication no
Match Address 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
    PasswordAuthentication yes
MikeyB
źródło
7

Częściowo odpowiedziałeś na swoje pytanie - im więcej miejsc atakujący może się połączyć, tym większe możliwości włamania się na twój serwer przez brutalne wymuszenie (rozważ DDoS).

Porównaj także długość hasła z rozmiarem klucza (zwykle tysiące bitów).

Martin Vejmelka
źródło
4
96-bitowa entropia oznacza 80-znakowe hasło, jeśli jest napisane w języku angielskim; 15 znaków, jeśli jest to przypadkowy bełkot z zestawu znaków do druku. czy jesteś pewien, że twoje hasła ssh są tak długie / silne?
MadHatter
3
Jeśli masz wiele haseł z 96-bitową entropią, które nie będą narażone na ataki słownikowe, prawdopodobnie i tak będziesz musiał użyć jakiegoś oprogramowania do zarządzania hasłami, aby skutecznie utracić dostępny wszędzie element korzystania z haseł .
Nick Downton
5
@SachinDivekar, który ma 96 bitów entropii tylko przy użyciu losowych haseł z zestawu [a-zA-Z], nie jeśli są to angielskie słowa.
Jaap Eldering
16
@NickDownton - Możesz mieć ładne długie hasło bez uciekania się do oprogramowania typu keypass. Coś takiego mywifesnameisangelaandshehasanicebuttjest niezniszczalne dla ataków słownikowych, jest bardzo silne i bardzo łatwe do zapamiętania, ale niemożliwe do odgadnięcia. I to z premią, jeśli punkty brownie, jeśli kiedykolwiek będziesz musiał podać hasło do żony.
Mark Henderson
7
Przepraszam, Mark, ale to źle. Podane hasło składa się z 37 znaków, a zatem z grubsza 44 bitów entropii, co oznacza, że ​​jest on słabszy niż 7 losowych znaków do wydrukowania i można go łatwo zaatakować. Szczegółowe informacje można znaleźć w artykule Wikipedii na temat pracy Claude'a Shannona, ale wynik jest taki, że pisany angielski jest wysoce przewidywalny - np. Po „mywifesname” słowo „jest” jest prawie gwarantowane. W przypadku silnych haseł zawierających słowa cztery losowe słowa połączone ze słownika dają około 10 ** 23 możliwości, czyli około 77 bitów entropii; wciąż nie świetne, ale nie złe.
MadHatter,
7

Gdy logujesz się przy użyciu hasła, przekazujesz je na serwer. Oznacza to, że operator serwera może zmodyfikować dysk SSHD, aby uzyskać dostęp do hasła. Dzięki uwierzytelnianiu za pomocą klucza publicznego nie mogą uzyskać klucza prywatnego, ponieważ tylko klucz publiczny co raz trafia na serwer.

Ramon
źródło
2
Jest to szczególnie istotne, gdy łączysz się z niewłaściwym serwerem z powodu literówki. Na przykład w pewnym momencie plik .cg był symbolem wieloznacznym wskazującym pojedynczą maszynę z włączoną funkcją ssh. Anytime byś błędnie .cg dla .ch, by skończyć się podłączając do tego pudełka i przecieka hasła ...
b0fh
@ b0fh rzeczywiście. O ile wiem, jest to jedyna prawdziwa luka wprowadzona przy użyciu haseł z ssh. Jeśli ktoś jest już właścicielem serwera, z którym się łączysz, lub może sfałszować adresy IP, z którymi się łączysz (MITM), już straciłeś.
płyty grzewcze
6

Klucze ssh zapobiegają atakom typu „man in the middle” na twoje hasło.

podczas próby zalogowania się za pomocą klucza serwer zbuduje wyzwanie na podstawie klucza publicznego i wyśle ​​go do klienta. który go odszyfruje i skonstruuje odpowiednią odpowiedź do wysłania.

Twój klucz prywatny nigdy nie jest wysyłany na serwer, a każdy, kto nasłuchuje, nie może nic zrobić poza przechwyceniem pojedynczej sesji.

z hasłem będą mieli twoje poświadczenia.

Moim rozwiązaniem jest posiadanie przenośnego klucza ssh w odpowiednich formatach na zaszyfrowanej partycji na kluczu USB. pozwala mi to:
łatwo wycofać ten klucz w przypadku jego zagubienia.
Ogranicz, do których serwerów pozwala mi uzyskać dostęp
i nadal go noszę

chociaż instalowanie oprogramowania montowania jest uciążliwe (truecrypt)

Taktyka
źródło
1
To jest źle. Gdy tylko poznasz klucz publiczny serwera (co zrobisz, jeśli dodasz go do pamięci podręcznej i nie uzyskasz MITM przy pierwszym połączeniu), jesteś odporny na ataki MITM. Uwierzytelnianie oparte na kluczu / haśle nie ma z tym nic wspólnego. Hasło nigdy nie jest przesyłane jednoznacznie przez sieć, bezpieczne połączenie przy uwierzytelnianiu na poziomie komputera (jaki jest twój / mój klucz publiczny) jest zawsze konfigurowane przed uwierzytelnieniem na poziomie użytkownika (jakie jest twoje hasło / udowodnij mi, że ten klucz publiczny jest twój) .
Thomas
3
Thomas, w rzeczywistości wiele osób ignoruje ostrzeżenie o zmianie odcisku palca. Autent Pubkey gwarantuje ochronę MITM, nawet jeśli klucz prywatny serwera zostanie w jakiś sposób przejęty lub nieumyślnie „ludzkie” typy ludzkie: atakujący musi wybrać między brakiem dostępu do ruchu a wysłaniem klucza publicznego, który się nie zaloguje, co jest zdobyć.
Score_Under
5
I dla odpowiadającego: Nie musisz używać truecrypt, klucze prywatne openssh są dostarczane z własnym opcjonalnym szyfrowaniem opartym na haśle.
Score_Under
5

Jest to kompromis, jak mówi @MartinVejmelka.

Powodem, dla którego używasz uwierzytelniania opartego na kluczach, jest to, że klucz jest znacznie powyżej obecnego lub w najbliższej przyszłości brutalnego wymuszania, że ​​musisz albo pochodzić z własnego komputera, albo mieć klucz na pamięci USB lub podobnym.

Hasło ma następujące problemy:

  • Jeśli jest krótki, może być brutalnie zmuszony
  • Jeśli jest długi, łatwo go zapomnieć
  • Może to być surfowanie po ramieniu

Klucz jest dłuższy o rząd wielkości i nie jest wyświetlany w żadnym momencie, więc pozwala uniknąć tych trzech problemów.

Rory Alsop
źródło
ale użycie pliku klucza powoduje utratę pendrive'a lub innego używanego miejsca.
João Portela
1
w tym momencie utracony klucz można usunąć i dodać nowy klucz. W przypadku haseł (szczególnie wspólnych haseł) może to być BARDZO Bolesne i wymaga dużo jęku.
SplinterReality
Jeden z moich (niedawno spoczynku) haseł: 08Forging2?seminal*^Rajas-(Posed/|. Jest generowany losowo, ale nie mam problemu z zapamiętaniem go. Powodzenia w surfowaniu po ramionach lub brutalnym zmuszaniu.
finnw
1
@finnw Prawidłowy zszywacz baterii konia :-) security.stackexchange.com/q/6095/485
Rory Alsop
2

Dobre punkty wspomniane już tutaj.

To, co uważam za największe ryzyko, biorąc pod uwagę, że zadbałeś o podstawy za pomocą silnego hasła, to to, że wiele komputerów ma zainstalowane keyloggery bez wiedzy użytkownika. Są nawet ludzie tworzący całe strony przydatnych narzędzi, które zawierają trojany, więc może się to przydarzyć najlepszemu z nas. Keylogger mógłby na przykład wysłać dane logowania do hakera, który następnie mógłby łatwo uzyskać dostęp do serwera.

Niedawno zostałem ostrzeżony przez Nortona o pobraniu instalatora Zombee Mod (nie słoika, instalatora) za dodanie lotu do słoika Minecraft. Spojrzałem na szczegóły i Norton wymienił wiele narzędzi na tej stronie, które zostały oznaczone jako zawierające trojana. Nie wiem, czy to jest poprawne, czy nie, ale było dość specyficzne z nazwami plików. Znany jest również fakt, że trojany są umieszczane w (niektórych) hurtowniach przed ich rozpowszechnieniem.

Tedd Hansen
źródło
2

Jedną z potencjalnych korzyści SSH w porównaniu z hasłami jest to, że jeśli nie określisz hasła SSH, nigdy nie będziesz musiał wpisywać hasła ponownie ... komputer jest wewnętrznie zaufany na serwerze, ponieważ ma on klucz. To powiedziawszy, zwykle zawsze używam hasła SSH, więc wykluczam tę korzyść.

Znajduję najlepszą odpowiedź na pytanie, dlaczego podręczniki użytkownika często zalecają SSH zamiast uwierzytelniania za pomocą hasła, pochodzące z podręcznika Ubuntu dla SSHOpenSSHKeys. Cytuję,

Jeśli uważasz, że to nie jest ważne, spróbuj zarejestrować wszystkie próby złośliwego logowania na następny tydzień. Mój komputer - zupełnie zwyczajny komputer stacjonarny - w ciągu ostatniego tygodnia wykonał ponad 4000 prób odgadnięcia hasła i prawie 2500 prób włamania. Jak myślisz, ile tysięcy przypadkowych domysłów zajmie, zanim atakujący natknie się na twoje hasło?

Zasadniczo, jeśli masz solidne, długie hasło z interpunkcją, dużymi i małymi literami oraz cyframi ... prawdopodobnie będziesz w porządku z uwierzytelnianiem hasła. Także jeśli planujesz monitorować swoje dzienniki i nie robisz „super bezpiecznych” rzeczy w sieci ... to znaczy używasz go do serwera domowego. W takim razie hasło działa dobrze.

MikeMurko
źródło
1

Metoda passwd auth jest naprawdę niepewna (imho). Za pomocą tego mechanizmu hasło zostanie przesłane do serwera sshd (jak już powiedział @ramon). Oznacza to, że niektóre osoby mogą zmodyfikować serwer sshd w celu odzyskania hasła. Z atakiem Man-In-The-Middle jest to bardzo łatwe do przeprowadzenia w sieci lokalnej.

Możesz po prostu załatać serwer sshd, instalując tę ​​łatkę ( https://github.com/jtesta/ssh-mitm ). Użyj arpspoofi, iptablesaby umieścić swój załatany serwer między klientem a autentycznym serwerem sshd.

Wyłącz uwierzytelnianie hasła: otwórz plik konfiguracyjny /etc/ssh/ssh_configi dodaj wiersz PasswordAuthentication no.

Pioz
źródło
Czy klient SSH nie sprawdza serwera pod kątem odcisku palca RSA? Po co najmniej raz wysłuchaniu tego konkretnego serwera jego odcisk palca zostanie zapamiętany, więc w przypadku ewentualnych ataków MITM SSH zapali ostrzeżenie, prawda?
Septagram
1
Tak. Ostrzeżenie pojawia się, ale ponieważ w 99% przypadków jest to spowodowane ponowną instalacją systemu operacyjnego, zmiana konfiguracji ecc, większość użytkowników zignoruje to ostrzeżenie i będzie kontynuować.
Pioz
@Septagram Wielu dostawców kont shellowych nie ma zwyczaju publikowania aktualnego odcisku klucza serwera dla nowych subskrybentów, migracji kont użytkowników na nowe serwery itp.
Damian Yerrick
-2

Możesz ominąć -o StrictHostKeyChecking=noopcję. Jest to bardzo przydatne, gdy używasz ssh w skrypcie powłoki.

ssh -o StrictHostKeyChecking=no -o ConnectTimeout=10 -o PasswordAuthentication=no -o ConnectionAttempts=5 xxUser@xxxHost
arganzheng
źródło