<<TableOfContents: execution failed „] (zobacz także log)>>
OpenSSH (lub Secure SHell) stał się de facto standardem dla zdalnego dostępu zastępując protokół telnet. SSH sprawił, że protokoły takie jak telnet stały się zbędne, głównie ze względu na fakt, że połączenie jest szyfrowane, a hasła nie są już wysyłane czystym tekstem do wglądu.
Jednakże domyślna instalacja ssh nie jest idealna, a podczas uruchamiania serwera ssh istnieje kilka prostych kroków, które mogą radykalnie wzmocnić instalację.
Używaj silnych haseł/nazwy użytkownika
Jedną z pierwszych rzeczy, które zauważysz jeśli masz uruchomiony ssh i wystawiony na świat zewnętrzny jest to, że prawdopodobnie będziesz logował próby hakerów do odgadnięcia twojej nazwy użytkownika/hasła. Zazwyczaj haker skanuje port 22 (domyślny port, na którym ssh nasłuchuje), aby znaleźć maszyny z uruchomionym ssh, a następnie próbuje ataku brute-force przeciwko niemu. Z silnymi hasłami w miejscu, miejmy nadzieję, że każdy atak zostanie zarejestrowany i zauważony zanim się powiedzie.
Mam nadzieję, że już używasz silnych haseł, ale jeśli nie, to spróbuj wybrać hasła, które zawierają:
- Minimum 8 znaków
- Mieszankę wielkich i małych liter
- Mieszankę liter i cyfr
- Znaki inne niż alfanumeryczne (np. znaki specjalne takie jak ! ” £ $ % ^ itp.)
Korzyści płynące z silnych haseł nie są specyficzne dla ssh, ale mają wpływ na wszystkie aspekty bezpieczeństwa systemów. Więcej informacji na temat haseł można znaleźć w dokumentacji CentOS:
http://www.centos.org/docs/4/html/rhel-sg-en-4/s1-wstation-pass.html
Jeśli absolutnie nie możesz zapobiec wybieraniu przez użytkowników słabych haseł, to rozważ użycie losowo generowanych lub trudnych do odgadnięcia nazw użytkownika dla kont użytkowników. Jeśli źli ludzie nie mogą odgadnąć nazwy użytkownika, wtedy nie będą mogli wymusić hasła metodą brute force. Jednakże, jest to nadal bezpieczeństwo przez zaciemnienie i bądź świadomy wycieku informacji o nazwach użytkowników z takich rzeczy jak wiadomości e-mail wysyłane z kont użytkowników.
Wyłącz logowanie roota
Ustawienia serwera SSH są przechowywane w pliku /etc/ssh/sshd_config. Aby wyłączyć logowanie roota, upewnij się, że masz następujący wpis:
# Prevent root logins:PermitRootLogin no
i zrestartuj usługę sshd:
service sshd restart
Jeśli potrzebujesz dostępu roota, zaloguj się jako zwykły użytkownik i użyj polecenia su.
Ograniczyć logowania użytkowników
Logowania SSH mogą być ograniczone tylko do niektórych użytkowników, którzy potrzebują zdalnego dostępu. Jeśli masz wiele kont użytkowników w systemie to sensowne jest ograniczenie zdalnego dostępu tylko do tych, którzy naprawdę go potrzebują, ograniczając w ten sposób wpływ przypadkowego użytkownika posiadającego słabe hasło. Dodaj linię AllowUsers, a następnie listę nazw użytkowników oddzielonych spacjami do /etc/ssh/sshd_config Na przykład:
AllowUsers alice bob
i zrestartuj usługę sshd.
Wyłącz protokół 1
SSH ma dwa protokoły, których może używać, protokół 1 i protokół 2. Starszy protokół 1 jest mniej bezpieczny i powinien być wyłączony, chyba że wiesz, że go potrzebujesz. Poszukaj następującej linii w pliku /etc/ssh/sshd_config, odkomentuj ją i zmień jak pokazano na rysunku:
# Protocol 2,1Protocol 2
i zrestartuj usługę sshd.
Używaj niestandardowego portu
Domyślnie ssh nasłuchuje połączeń przychodzących na porcie 22. Aby haker mógł stwierdzić, że ssh jest uruchomiony na twoim komputerze, najprawdopodobniej przeskanuje port 22, aby to ustalić. Skuteczną metodą jest uruchomienie ssh na niestandardowym porcie. Wystarczy dowolny nieużywany port, choć preferowany jest ten powyżej 1024. Wiele osób wybiera 2222 jako alternatywny port (ponieważ jest łatwy do zapamiętania), podobnie jak 8080 jest często znany jako alternatywny port HTTP. Z tego właśnie powodu, to prawdopodobnie nie jest najlepszy wybór, jak każdy haker skanowania portu 22 będzie prawdopodobnie również skanowanie portu 2222 tylko dla dobrej miary. Lepiej jest wybrać jakiś losowy wysoki port, który nie jest używany przez żadne znane usługi. Aby dokonać zmiany, dodaj następującą linię do pliku /etc/ssh/sshd_config:
# Run ssh on a non-standard port:Port 2345 #Change me
i zrestartuj usługę sshd. Nie zapomnij następnie dokonać wszelkich niezbędnych zmian w przekierowaniu portów w routerze i wszelkich regułach zapory sieciowej. Na przykład w CentOS 7 (i wyższych) możesz zmienić usługę ssh w firewalld tworząc duplikat pliku usługi w /etc/firewalld/ i zmieniając linię portu:
$ cp /usr/lib/firewalld/services/ssh.xml /etc/firewalld/services/ssh-custom.xml
Następnie zmień linię portu w /etc/firewalld/services/ssh-custom.xml tak, aby port był taki sam jak w pliku konfiguracyjnym ssh:
<port protocol="tcp" port="2345"/>
Na koniec usuń usługę ssh, dodaj usługę ssh-custom i przeładuj firewalld, aby zmiany zaczęły obowiązywać:
$ firewall-cmd --permanent --remove-service='ssh'$ firewall-cmd --permanent --add-service='ssh-custom'$ firewall-cmd --reload
Or on CentOS 6, dodaj regułę iptable, aby otworzyć nowy port ssh:
$ iptables -I INPUT -p tcp --dport 2345 -j ACCEPT
Nie zapomnij również zamknąć starego portu.
Na CentOS 6 i wyżej powinieneś również zaktualizować selinux, oznaczając wybrany port poprawnie, w przeciwnym razie sshd nie będzie miał do niego dostępu. Na przykład:
$ semanage port -a -t ssh_port_t -p tcp 2345 #Change me
Ponieważ ssh nie nasłuchuje już połączeń na standardowym porcie, będziesz musiał powiedzieć swojemu klientowi na jakim porcie ma się łączyć. Używając klienta ssh z linii poleceń, możemy określić port używając przełącznika -p:
$ ssh -p 2345 myserver
lub jeśli korzystamy z protokołu fish w konquerorze, na przykład:
fish://myserver:2345/remote/dir
Jeśli myślisz, że to brzmi jak ból konieczności określania portu za każdym razem, gdy się łączysz, po prostu dodaj wpis określający port w lokalnym pliku ~/.ssh/config:
# Client ~/.ssh/configHost myserverHostName 72.232.194.162 User bob Port 2345
A plik: ~/.ssh/config musi mieć następujące uprawnienia:
$ chmod 600 ~/.ssh/config
Filter SSH at the Firewall
Jeśli potrzebujesz zdalnego dostępu tylko z jednego adresu IP (powiedzmy z pracy do serwera domowego), to rozważ filtrowanie połączeń na zaporze, dodając regułę zapory na routerze lub w iptables, aby ograniczyć dostęp na porcie 22 tylko do tego konkretnego adresu IP. Na przykład w iptables można to osiągnąć za pomocą następującego typu reguły dla iptables (CentOS 6):
$ iptables -A INPUT -p tcp -s 72.232.194.162 --dport 22 -j ACCEPT
lub używając firwalld (CentOS 7) Użyj rich-rules, aby zezwolić na ssh tylko na określonym porcie. Adres źródłowy może być pojedynczym adresem lub adresem bazowym z maską bitową:
SSH również natywnie obsługuje wrappery TCP i dostęp do usługi ssh może być podobnie kontrolowany za pomocą hosts.allow i hosts.deny.
Jeśli nie jesteś w stanie ograniczyć źródłowych adresów IP i musisz otworzyć port ssh globalnie, to iptables może nadal pomóc w zapobieganiu atakom brute-force poprzez rejestrowanie i blokowanie powtarzających się prób logowania z tego samego adresu IP. Na przykład, z iptables
Pierwsza reguła rejestruje adres IP każdej nowej próby dostępu do portu 22 przy użyciu modułu recent. Druga reguła sprawdza, czy ten adres IP próbował się poł±czyć 4 lub więcej razy w ci±gu ostatnich 60 sekund, a je¶li nie, to pakiet jest akceptowany. Zauważ, że ta reguła wymagałaby domyślnej polityki DROP na łańcuchu wejściowym.
Nie zapomnij zmienić odpowiednio portu, jeśli używasz ssh na niestandardowym porcie. Tam gdzie to możliwe, filtrowanie na firewallu jest bardzo skuteczną metodą zabezpieczenia dostępu do serwera ssh.
Dla systemów używających usługi FirewallD (CentOS 7 lub wyższy), użyj firewall-cmd:
Pierwsze polecenie usuwa bardziej permisywną regułę usługi, drugie ustanawia regułę akceptującą tylko 4 połączenia w ciągu minuty i rejestrującą wszystkie połączenia.
Używaj kluczy publicznych/prywatnych do uwierzytelniania
Używanie kluczy szyfrowanych do uwierzytelniania daje dwie główne korzyści. Po pierwsze, jest to wygodne, ponieważ nie musisz już wpisywać hasła (chyba że szyfrujesz klucze z ochroną hasłem), jeśli używasz kluczy publicznych/prywatnych. Po drugie, po skonfigurowaniu uwierzytelniania za pomocą pary kluczy publicznych/prywatnych na serwerze, można całkowicie wyłączyć uwierzytelnianie za pomocą hasła, co oznacza, że bez autoryzowanego klucza nie można uzyskać dostępu – więc koniec z próbami łamania haseł.
To stosunkowo prosty proces, aby utworzyć parę kluczy publicznych/prywatnych i zainstalować je do użytku na serwerze ssh.
Najpierw utwórz parę kluczy publicznych/prywatnych na kliencie, którego będziesz używał do łączenia się z serwerem (będziesz musiał to zrobić z każdej maszyny klienckiej, z której się łączysz):
$ ssh-keygen -t rsa
Jeśli nie chcesz, aby przy każdym połączeniu wciąż pytano Cię o passphrase (czyli w zasadzie hasło odblokowujące dany klucz publiczny), po prostu naciśnij enter, gdy zostaniesz poproszony o passphrase podczas tworzenia pary kluczy. Do Ciebie należy decyzja, czy powinieneś dodać frazę hasła zabezpieczającą szyfrowanie do Twojego klucza podczas jego tworzenia, czy też nie. Jeśli nie zabezpieczysz swojego klucza frazą hasła, wtedy każdy kto uzyska dostęp do Twojego lokalnego komputera będzie miał automatycznie dostęp ssh do zdalnego serwera. Ponadto, root na lokalnym komputerze ma dostęp do twoich kluczy, chociaż można założyć, że jeśli nie możesz zaufać rootowi (lub root jest zagrożony), to masz prawdziwe kłopoty. Szyfrowanie klucza dodaje dodatkowe zabezpieczenie kosztem wyeliminowania potrzeby wpisywania hasła do serwera ssh, które ma być zastąpione wpisaniem hasła do użycia klucza. Może to być dodatkowo uproszczone przez użycie programu ssh_agent
Teraz ustaw uprawnienia na kluczu prywatnym:
$ chmod 700 ~/.ssh$ chmod 600 ~/.ssh/id_rsa
Kopiuj klucz publiczny (id_rsa.pub) na serwer i zainstaluj go na liście authorized_keys:
$ cat id_rsa.pub >> ~/.ssh/authorized_keys
Uwaga: po zaimportowaniu klucza publicznego można go usunąć z serwera.
i w końcu ustawić uprawnienia do plików na serwerze:
$ chmod 700 ~/.ssh$ chmod 600 ~/.ssh/authorized_keys
Powyższe uprawnienia są wymagane, jeśli StrictModes jest ustawione na yes w /etc/ssh/sshd_config (domyślnie).
Upewnij się, że ustawione są poprawne konteksty SELinux:
$ restorecon -Rv ~/.ssh
Teraz, gdy zalogujesz się do serwera, nie zostaniesz poproszony o podanie hasła (chyba że podałeś frazę hasła podczas tworzenia pary kluczy). Domyślnie, ssh najpierw spróbuje uwierzytelnić się przy użyciu kluczy. Jeśli klucze nie zostaną znalezione lub uwierzytelnienie nie powiedzie się, ssh powróci do konwencjonalnego uwierzytelniania za pomocą hasła.
Po sprawdzeniu, że możesz z powodzeniem zalogować się do serwera przy użyciu pary kluczy publicznych/prywatnych, możesz całkowicie wyłączyć uwierzytelnianie za pomocą hasła, dodając następujące ustawienie do pliku /etc/ssh/sshd_config:
# Disable password authentication forcing use of keysPasswordAuthentication no
Często zadawane pytania (FAQ)
Q: CentOS używa wersji X OpenSSH, a najnowszą wersją jest wersja Y. Wersja X zawierała poważną lukę w zabezpieczeniach, czy powinienem ją uaktualnić?
A: Nie. Upstream Vendor stosuje politykę backportu poprawek bezpieczeństwa z najnowszych wydań do aktualnej wersji dystrybucji. Tak długo jak posiadasz najnowsze aktualizacje dla swojej dystrybucji CentOS jesteś w pełni zabezpieczony. Zobacz tutaj, aby uzyskać więcej szczegółów na temat backportu poprawek bezpieczeństwa:
http://www.redhat.com/advice/speaks_backport.html
Q: Jak sprawić, by ssh pozwalał na bezhasłowe uwierzytelnianie oparte na kluczach między maszynami, które współdzielą katalogi domowe użytkowników przez NFS?
A: SElinux domyślnie blokuje dostęp roota do katalogów i plików współdzielonych przez NFS, które nie są dostępne do odczytu światowego, więc sshd nie może odczytać plików kluczy użytkowników w ~/.ssh. Aby umożliwić dostęp, zmień ustawienie use_nfs_home_dirs, wykonując następującą komendę jako superużytkownik:
setsebool -P use_nfs_home_dirs 1
https://www.centos.org/forums/viewtopic.php?t=49194
Links
http://www.centos.org/docs/5/html/Deployment_Guide-en-US/ch-openssh.html
http://www.dragonresearchgroup.org/insight/sshpwauth-tac.html
.