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

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?

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.

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ąć.

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

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).

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.

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)

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.

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.

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.

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.

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