Jak mogę zwiększyć bezpieczeństwo SSH? Czy mogę wymagać zarówno klucza, jak i hasła?

16

Mam małą sieć serwerów i chciałbym zwiększyć ogólne bezpieczeństwo. Nie mam wystarczająco dużo czasu / pieniędzy / paranoi, aby skonfigurować VPN - jaki jest podstawowy sposób na zwiększenie bezpieczeństwa mojego systemu?

Jedną rzeczą może być wymaganie, aby użytkownicy przesyłali swój klucz i wprowadzali hasło. Jest to trochę trudne do wyszukania w Google, ponieważ wszystko o „haśle klucza ssh” dotyczy sshing bez hasła. :-)

Jednym ze schematów, w których zawsze chciałem się bawić, jest wymaganie, aby połączenia przychodzące pochodziły tylko z białej listy adresów IP dyndns. Wiem, że niektórzy szefowie bezpieczeństwa zwymiotowaliby na samą myśl o tym pomyśle, ale faktem jest, że korzystanie z pudełka bardzo by skomplikowało.

Co myślisz? Co jeszcze tam jest?

security ssh John Bachir
źródło
Możesz także ograniczyć listę użytkowników, którzy mogą się łączyć za pomocą dyrektyw AllowUsers lub DenyUsers. Więcej informacji na temat tego postu .
Fred

Odpowiedzi:

8

Login z hasłem i kluczem jest taki sam jak „tylko z kluczem”. Podczas tworzenia klucza zostaniesz poproszony o wprowadzenie hasła. Jeśli pozostawisz to pole puste, nie zostaniesz poproszony o podanie hasła. Jeśli wypełnisz jakieś hasło, będziesz o nie proszony za każdym razem, gdy chcesz się zalogować.

Jeśli obawiasz się o bezpieczeństwo, weź pod uwagę niektóre z tych porad, które wymieniono biliony razy na tym forum:

  • Wyłącz logowanie ssh dla roota
  • Zezwalaj na dostęp ssh tylko ze zdefiniowanych adresów IP (iptables, hosts.allow, ...)
  • Przenieś port ssh do innego portu (więcej zaciemnienia niż bezpieczeństwa, ale działa)
  • Monitoruj zagraniczne próby logowania i odpowiednio reaguj
  • Aktualizuj swój system

Itd itd.

Aktualizacja: zapoznaj się z odpowiedzią tutaj, aby dowiedzieć się, jak wymagać zarówno klucza publicznego, jak i hasła lokalnego systemu z serwerem OpenSSH.

mkudlacek
źródło
Dzięki za wszystkie Twoje wskazówki, przejrzę je. jeśli zarówno klucz, jak i hasło są wymagane, to jeśli exploit wyszuka hasło (na przykład, jeśli użytkownik użyje go w innym miejscu, które nie jest bezpieczne), nie będzie mógł wejść bez klucza, a jeśli exploit wykradnie klucz z komputera użytkownika , nie mogą wejść bez znajomości hasła… prawda?
John Bachir,
12
To nie to samo. Jeśli potrzebujesz tylko klucza, serwer nie może wymusić żadnej zasady siły hasła na kluczu. Nieostrożny użytkownik może mieć nieszyfrowany klucz prywatny leżący na kliencie, który naraża serwer na niebezpieczeństwo w przypadku kradzieży klucza.
200_success
mkudlacek - wcześniej nie wiedziałem o hosts.allow - googlując się po okolicy, wygląda na to, że mój pomysł na listę białych dyndns wcale nie jest taki głupi, myślę, że spróbuję.
John Bachir,
1
200_success - czy można wymagać zarówno klucza, jak i hasła?
John Bachir,
Korzystam również z aplikacji DenyHosts, aby blokować osoby, które próbują się dostać i nie udają. Miły mały proaktywny zautomatyzowany sposób umieszczania osób na czarnej liście ...
James T Snell
6

Jednym z pomysłów, który uznałem za interesujący, jest pukanie do portów - w zasadzie, aby ustanowić połączenie ssh, musisz najpierw sprawdzić sekwencję innych portów, zanim serwer ssh potwierdzi żądanie połączenia. Jeśli nie jest używana poprawna sekwencja portów, nie ma odpowiedzi, więc wygląda na to, że nie działa serwer ssh. Sekwencja portów jest konfigurowalna i może być udostępniana docelowym użytkownikom; wszyscy inni skutecznie nie mogliby się połączyć.

Sam tego nie próbowałem, ale z tego, co słyszałem (co właściwie nie jest wiele), koszty ogólne są znikome i znacznie obniżają twój profil widoczności.

weiji
źródło
Zrobiłbym to, jeśli chcesz po prostu „zwiększyć ogólne bezpieczeństwo”, ale prawdopodobnie powinieneś raczej spróbować rozwiązać określone problemy z bezpieczeństwem.
Stefan Thyberg,
Używam tego na wszystkich stronach, na których ssh, i jest to bardzo skuteczne imho.
Sirex,
Czy to nie to samo, co hasło dłuższe o 4 znaki?
John Bachir,
nie całkiem. Jest 65536 portów i 26 liter. Ponadto sekwencja pukania ma dowolną długość i można ograniczyć liczbę ponownych prób, używając standardowych technik zapory ogniowej. Nie jest to samo w sobie bezpieczeństwo, ale dobrze jest mieć.
Sirex,
no to 8 lub 12 znaków dłużej :-D
John Bachir
3

Poprawki związane z włączaniem bezpośrednio w SSH i wiele istotnych dyskusji:

Można to również zrobić bez modyfikacji poprzez połączenie skryptu weryfikacji hasła z użyciem ForceCommandopcji konfiguracji.

Wreszcie, chociaż nie istnieje dla niego żaden moduł, jeśli przeniesiesz uwierzytelnianie za pomocą klucza publicznego do PAM, będziesz musiał przejść oba kroki, zanim PAM uzna uwierzytelnienie za udane.

Jeff Ferland
źródło
2

Po prostu użyj 

RequiredAuthentications publickey, password

w sshd_configprzypadku korzystania z ssh.com sshd. Ta funkcja nie jest dostępna w OpenSSH.

Flávio Botelho
źródło
RequiredAuthenticationsjest zdecydowanie niestandardowym rozszerzeniem do OpenSSH
Hubert Kario
Czy wiesz, które implementacje sshd obsługują to?
John Bachir,
Serwer Tectia SSH obsługuje to. BTW: użyj @nameOfUser, odpowiadając na ich komentarze, w ten sposób zostaną powiadomieni o odpowiedzi
Hubert Kario,
Podobna funkcjonalność obsługiwana jest w OpenSSH od wersji 6.2: serverfault.com/a/562899
Søren Løvborg
1

Możesz również użyć haseł jednorazowych, aby zwiększyć bezpieczeństwo. Umożliwiłoby to użytkownikom logowanie się z niepewnego terminala, który może mieć keylogger, jeśli wcześniej wygenerowali następne hasło. Istnieją również generatory haseł, które można zainstalować nawet na starszych telefonach Java MIDP, które zawsze masz przy sobie.

Prof. Moriarty
źródło
Tak, na moim osobistym serwerze używam tokena Yubikey oprócz mojego hasła. Token generuje jednorazowe hasło. Oba są wymagane do uwierzytelnienia. Alternatywnie zezwalam na pomijanie pary hasło / otp, jeśli uwierzytelniasz się za pomocą klucza SSH. Yubikey jest tani i istnieje mnóstwo oprogramowania do jego integracji z Pam, rozszerzalnym systemem uwierzytelniania Linuksa.
Martijn Heemels
1

Polecam, aby nigdy nie uruchamiać sshd, rdp ani takich usług zarządzania bez ograniczeń IP. W rzeczywistości sugerowałbym ograniczenie dostępu do takich usług administratorom łączącym się przez VPN.

3molo
źródło
1

Jeśli chodzi o twoje pierwotne pytanie o wymaganie zarówno klucza, jak i hasła, jeśli używasz RHEL lub CentOS 6.3, jest to teraz możliwe. Te notatki RHEL 6.3 uwolnienia go opisać, to kwestia dodając to do sshd_config

RequiredAuthentications2 publickey,password
Mark McKinstry
źródło
0

Zdecydowanie zgadzam się z 3molo. OpenSSH jest domyślnym serwerem SSH dla systemów Linux i Unix. Nie ma powodu, aby to zmieniać, szczególnie ze względu na bezpieczeństwo. VPN powinno być najlepszym rozwiązaniem, które może szyfrować nasz ruch i zapewniać 2-etapową autoryzację hasła.

mcsrainbow
źródło
0

Nie jestem pewien, dlaczego nikt o tym nie wspominał, ale - upewnij się, że generujesz klucze dłuższe niż domyślne 1024 bity, co nie jest już uważane za bezpieczne.

mnmnc
źródło