Ten artykuł jest oznaczony jako skrót. Zobacz notatkę na końcu artykułu.
Ten artykuł skupia się na bezpiecznym kliencie i serwerze terminalowym (secure shell) w Ubuntu, ich konfiguracji i użytkowaniu. SSH to specjalny protokół sieciowy, który umożliwia zdalny dostęp do komputera o wysokim stopniu bezpieczeństwa połączenia. Możesz przeczytać więcej o protokole ssh.
Opis zasad działania i stosowanych aplikacji
Zasadniczo SSH jest zaimplementowany jako dwie aplikacje - serwer SSH i klient SSH.Ubuntu wykorzystuje darmową implementację klienta i serwera SSH, OpenSSH. Podczas nawiązywania połączenia klient przechodzi procedurę autoryzacji na serwerze i pomiędzy nimi nawiązywane jest szyfrowane połączenie. Serwer OpenSSH może pracować zarówno z protokołem ssh1 jak i ssh2. Protokół ssh1 jest obecnie uważany za niepewny i dlatego jest zdecydowanie odradzany. Celowo pomijam różne szczegóły techniczne dotyczące działania protokołu, ponieważ głównym celem tego przewodnika jest opisanie jego konfiguracji i użytkowania. W Internecie jest wiele artykułów na temat samego protokołu, zasad jego działania, algorytmów szyfrowania itp., na przykład można o tym szczegółowo przeczytać.
Instalacja
zainstalować OpenSSH Możesz użyć polecenia z terminala:
sudo apt-get zainstaluj sshMetapakiet ssh zawiera zarówno klienta, jak i serwer, ale najprawdopodobniej zainstaluje to tylko serwer, ponieważ klient jest już domyślnie zawarty w Ubuntu.
Dostrajanie serwera
Podczas instalacji SSH serwer jest automatycznie dodawany do uruchamiania. Możesz sterować jego uruchomieniem, zatrzymaniem lub ponownym uruchomieniem za pomocą poleceń:
sudo usługa ssh stop| start | uruchom ponownieGłównym plikiem konfiguracyjnym serwera SSH jest plik /etc/ssh/sshd_config, który może być odczytywany lub edytowany tylko przez administratora. Po każdej zmianie w tym pliku musisz zrestartować serwer ssh, aby zmiany odniosły skutek.
Przykładowa domyślna konfiguracja serwera SSH w Ubuntu:
# Przykład otwartej konfiguracji serwery ssh z rosyjskimi komentarzami # #..2010. # # # # # # Konwencje: # # Przez "domyślnie" rozumie się zachowanie sshd, gdy # # nie określono wyraźnie dyrektywy. Warto zauważyć, że w Ubuntu # # plik sshd_config zawiera już kilka ustawień, # # które są domyślne dla Ubuntu. # # Takie ustawienia są określone w tym pliku. #### ############################################### ############## ################ Ustawienia adresu/portu itp. ########### ####################################### ##################### # # ## Port ######################## ############################ # # # Port do użycia. Możesz określić więcej niż jeden, na przykład: ## Port 22 ## Port 23 ## Port 24 # # Zalecany do użycia port niestandardowy, dlatego # # standardowa jest często skanowana przez boty pod kątem # # potencjalnych dziur. Można pominąć, jeśli podano # # za pośrednictwem adresu. Zobacz także parametr ListenAddress. # # # Port 22 # # ## ListenAddress ##################################### # ## # # # Adres sieciowy, na którym nasłuchuje serwer. Adres można # # zapisać w ten sposób: # # ListenAddress host|IPv4_addr|IPv6_addr ## ListenAddress host|IPv4_addr:port # # ListenAddress :port # # Jeśli nie określono portu, sshd będzie nasłuchiwał na tym adresie, a # # na port określony w opcji port. Jeśli używasz # # ListenAddress bez określania portu, opcja # # Port musi znajdować się przed opcją ListenAddress. Jeśli zostanie pominięty, # # domyślnie nasłuchuje na wszystkich # # adresach lokalnych. Możesz podać wiele adresów. ###################################################### # # # Określa, która rodzina adresów IP # # powinna być używana przez sshd. Możliwe opcje : # # „dowolny” - dowolny # # „inet” (tylko IPv4) # # „inet6” (tylko IPv6) # # Domyślnym ustawieniem jest „dowolny”. # AdresRodzina inet ## ## Użyty DNS ######################################### # ####### # # # Określa, czy sshd powinien sprawdzać nazwę hosta i ## używać tej nazwy do sprawdzania adresu IP podanego przez klienta z ## otrzymanym z DNS. # # Wartość domyślna to „tak”. #### ############################################### # ############# ############# Ustawienia dostępu użytkownika ############## ###### ################################################## ## ### # # # Zezwolenie/odmowa dostępu użytkownika jest definiowane przez dyrektywy ## DenyUsers, AllowUsers, DenyGroups i AllowGroups. # # w tym samym czasie czek przechodzi od góry do dołu wzdłuż łańcucha: # # ## OdmówUżytkownikom ## # # || ## ## Zezwól Użytkownikom ## # # || # # ## OdmowaGrupy ## # # || ## ## AllowGroups ## # # Akceptowane są tylko nazwy użytkowników i grup, numeryczne ## identyfikatory (UserID) nie są rozpoznawane. Popraw # # wpis wielu użytkowników/grup po kolei, oddzielonych # # spacją. Jeśli zostanie zapisany jako użytkownik@host, to # # użytkownik i host są sprawdzane oddzielnie, # # pozwala to na ograniczenie dostępu do niektórych użytkowników z # # określonych hostów. Warto pamiętać, że dyrektywy # # DenyUsers i AllowUsers przyjmują # # nazwę użytkownika jako parametr, natomiast DenyGroups i AllowGroups # # przyjmują nazwę grupy. Zobacz PATTERNS w man ssh_config, aby uzyskać więcej # # informacji o konwencji nazw użytkowników i nazw grup. # # # ## Odmów użytkownikom ######################################### # ## # # # Lista UŻYTKOWNIKÓW, KTÓRE NIE POWINNY być używane przez sshd. # # Domyślnie - nie określono = nikt nie jest zbanowany. Tych. # # jeśli użytkownik jest tutaj określony, # # będzie mu zabroniony dostęp do serwera ssh. # # # ## Zezwól Użytkownikom ######################################### # # # # # Lista UŻYTKOWNIKÓW, KTÓRE POWINNY być używane przez sshd, # # Domyślnie - nie określono = każdy jest dozwolony. Tych. # # jeśli określono przynajmniej jednego użytkownika, dostęp ssh do serwera # # jest dostępny tylko dla niego. # # # ## Odmów grupy ######################################### # # # # # Lista GRUPY, KTÓRA NIE POWINNA być używana przez sshd. # # Domyślnie - nie określono = żadne grupy nie są zbanowane. # # Tj. jeśli określono co najmniej jedną grupę, # # użytkownikom z tej grupy zostanie odmówiony dostęp do # # serwera ssh. # # # ## Grupy Zezwól ######################################### # # # # Lista GRUPY, których sshd MOŻE używać. # # Domyślnie - nie określono = dozwolone dla wszystkich. Tych. jeśli ## zostanie określona co najmniej jedna grupa, wtedy tylko użytkownicy# # należący do niej będą mieli dostęp do serwera ssh.################## ## ###################################### ######## # Opcje określające stan połączenia ########### ################################## ## ######################## # # ## TCPKeepAlive ################### ## ####################### # # # Określa, czy system powinien wysyłać komunikaty TCP do klienta ## w celu utrzymania połączenia. Jeśli wyślesz te pakiety,# # możesz wykryć rozłączenie. Jednak # # oznacza to również, że połączenie może zostać przerwane, # # jeśli wystąpi chwilowa przerwa w routingu, # # co jest bardzo denerwujące dla niektórych. Z drugiej strony, jeśli # # te wiadomości nie zostaną wysłane, sesje na serwerze # # mogą działać w nieskończoność, # # wywołując użytkowników "ducha" i pożerając zasoby serwera. Wartość domyślna to „tak”, # # tj. wysyłać takie wiadomości. Aby wyłączyć wysyłanie # # takich wiadomości, ustaw wartość na „nie”. Poprzednio ta # # opcja nazywała się KeepAlive. Warto zauważyć, że istnieją # # bezpieczniejsze sposoby sprawdzania stanu połączenia # # (patrz poniżej). # # # TCPKeepAlive tak # # ## ClientAliveCountMax ###################################### # # # Określa liczba wiadomości do klientów # #, które sshd wysyła z rzędu, nie otrzymując # # żadnej odpowiedzi od klienta. Jeśli próg zostanie osiągnięty, a # # klient nadal nie odpowiada, sshd rozłączy klienta, # # kończąc sesję ssh. Warto zauważyć, że użycie tych komunikatów # # zasadniczo różni się od dyrektywy TCPKeepAlive. # # Wiadomości do/od klientów są wysyłane przez # # zaszyfrowany kanał i dlatego nie są podatne na fałszowanie. # # Wiadomości TCPKeepAlive są podatne na fałszowanie. Mechanizm # # ożywienia klienta jest szczególnie cenny w przypadkach, gdy # # serwer i klient muszą wiedzieć, kiedy połączenie stało się nieaktywne. # # wartość domyślna to 3. Jeśli ClientAliveInterval # # jest ustawiony na 15, a ClientAliveCountMax ma # # wartość domyślną, nieodpowiadający klienci zostaną rozłączeni po około # # 45 sekundach. Ta dyrektywa działa tylko # # dla protokołu ssh2. # # # ## ClientAliveInterval ################################## # # # Ustawia interwał czasowy w sekundy. Jeśli w tym czasie nie było # # komunikacji z klientem, sshd # # wysyła wiadomość przez zaszyfrowany kanał # # żądając odpowiedzi od klienta. Wartość domyślna to 0, tj. # # nie wysyłaj takich wiadomości. Ta dyrektywa działa # # tylko dla protokołu ssh2. #### ############################################### # ############# ################ Ogólne opcje uwierzytelniania ################ # ################################################## ## ######## ## ## AuthorizedKeysFile ################################### ## # # # # Określa plik, który zawiera klucze publiczne ## używane do uwierzytelniania użytkowników. Dyrektywa # # może zawierać tokeny w postaci %M, które są podstawiane podczas # # procesu nawiązywania połączenia. # # Zdefiniowane są następujące znaczniki: # # %% — zastępowane przez dosłowne „%” # # %h — zastępowane katalogiem domowym # # użytkownika uwierzytelniającego # # %u — zastępowane nazwą użytkownika uwierzytelniającego # # W ten sposób plik klucza można określić jako # # ścieżkę bezwzględną (tj. jeden wspólny plik z kluczami) i # # dynamicznie - w zależności od użytkownika (tzn. # # plik na użytkownika). # # Wartość domyślna to „.ssh/authorized_keys”. # # Przykład pliku klucza w folderze domowym użytkownika: # # AuthorizedKeysFile %h/.ssh/authorized_key # # Przykład pliku ogólnego: # # AuthorizedKeysFile /etc/ssh/authorized_keys # # Więcej informacji znajdziesz w opisie pliku Authorized_keys # # # Informacja. # # # ## ChallengeResponseAuthentication ######################## # # # Określa, czy zezwolić na uwierzytelnianie typu wyzwanie-odpowiedź # # (uwierzytelnianie typu wyzwanie-odpowiedź). # # Obsługiwane są wszystkie typy uwierzytelniania z login.conf Domyślnie „tak”, # # tj. dopuszczać. # # W Ubuntu wyłączone ze względów bezpieczeństwa. # # # ChallengeResponseAuthentication no # # ## HostbasedUsesNameFromPacketOnly ######################### # # # Określa, jak serwer powinien pobrać nazwę hosta klienta # #, kiedy schemat uwierzytelniania oparty na hoście. # # Jeśli ustawione na "yes", sshd # # użyje nazwy hosta dostarczonej przez klienta podczas sprawdzania zgodności w # # ~/.shosts, ~/.rhosts lub /etc/hosts.equiv. # # (wykonywanie odwrotnego rozwiązywania DNS) Jeśli ustawione na "no"# # - sshd rozwiąże nazwę z samego połączenia TCP. # # Wartość domyślna to "nie". # # # ## IgnorujRhosty ######################################### # # # Wyłącza używanie plików .rhosts i .shosts # # w uwierzytelnianiu na hoście. # # (RhostsRSAAuthentication lub HostbasedAuthentication). # # Pliki /etc/hosts.equiv i /etc/ssh/shosts.equiv są # # nadal używane. # # Wartość domyślna to „tak”. # # # IgnoreRhosts tak # # ## IgnoreUserKnownHosts #################################### # # # Wskazuje powinno sshd zignorować plik # # użytkownika "znane hosty" ~/.ssh/known_hosts podczas # # uwierzytelniania opartego na hoście (RhostsRSAAuthentication lub HostbasedAuthentication). # # Wartość domyślna to „nie”. # # # ## PermitBlacklistedKeys ################################## # # # Określa, czy akceptować klucze sshd umieszczone na czarnej liście # # jako skompromitowane (znane-skompromitowane klucze # # (zobacz ssh-vulnkey)). Jeśli ustawione na „tak”, # # próby uwierzytelnienia z tymi kluczami będą rejestrowane # # i akceptowane, jeśli ustawione na „nie”, # # próby uwierzytelnienia będą odrzucane. # # Wartość domyślna to „nie”. # # # ## PermitEmptyPasswords #################################### # # # W przypadku dozwolonego uwierzytelnienia z hasło, # # określa, czy możliwe jest logowanie za pomocą pustego hasła. # # Wartość domyślna to „nie”. # # # PermitEmptyPasswords no # # ## PermitRootLogin #################################### # # # # Wskazuje, czy logowanie ssh jako superużytkownik # # (root) jest dozwolone. Może przyjmować następujące wartości: # # "tak" - superużytkownik może się zalogować. # # Używany jest aktualny globalny schemat uwierzytelniania. # # # # "bez hasła" - superużytkownik może się zalogować. # # Uwierzytelnianie hasłem zostanie dla niego wyłączone. # # # # „tylko polecenia wymuszone” - superużytkownik będzie mógł się zalogować # # przy użyciu uwierzytelniania klucza publicznego i # # tylko wtedy, gdy przekaże wymagane polecenie do wykonania. # # Jest wygodny do ćwiczeń Zarezerwuj kopię , # # nawet wtedy, gdy normalnie (tzn. nie przez ssh) # # logowanie root jest zabronione. Wszystkie inne # # metody uwierzytelniania dla superużytkownika zostaną wyłączone.# # # # „nie” – superużytkownik nie może # # użyć ssh do zalogowania się do systemu. # # # # Wartość domyślna to „tak”. # # # PermitRootLogin tak # # ## Protokół ######################################## ######## # # # Określa, którego protokołu ma używać sshd. # # Możliwe wartości '1' i '2' to odpowiednio ssh1 i ssh2 # #. Możliwe jest jednoczesne pisanie, w którym # # wartości muszą być oddzielone przecinkami. # # Wartość domyślna to „2,1”. # # Warto zauważyć, że kolejność protokołów w # # wpisie nie określa priorytetu, ponieważ klient wybiera, który # # z kilku protokołów oferowanych przez serwer ma # # użyć.Wpis „2,1” jest dokładnie # # identyczny z wpisem „1,2”. # # # Protokół 2 ## ## UsePAM ####################################### # ######### # # # Włącza interfejs PAM (Pluggable Authentication Module ##) Jeśli ustawione na "tak" - dla wszystkich typów uwierzytelniania # # oprócz przetwarzania modułu sesji i konta # # PAM uwierzytelnianie będzie używane na podstawie # # challenge-response (ChallengeResponseAuthentication i ## PasswordAuthentication) challenge-response # # uwierzytelnianie w PAM zwykle pełni tę samą rolę # # co uwierzytelnianie hasłem, należy # # wyłączyć albo PasswordAuthentication albo # # ChallengeResponseAuthentication. Warto zauważyć, że # # jeśli dyrektywa UsePAM jest włączona, nie będziesz mógł # # uruchomić sshd jako użytkownik inny niż root. # # Wartość domyślna to „nie”. # # # UsePAM tak # # ## PasswordAuthentication ################################## # # # Określa, czy uwierzytelnianie za pomocą hasła # #. # # Wartość domyślna to „tak”. # # # ## HostKey ######################################### # #### # # # Określa plik zawierający klucz prywatny hosta ## używany przez SSH. Domyślnie jest to /etc/ssh/ssh_host_key # # dla protokołu ssh1 i /etc/ssh/ssh_host_rsa_key i # # /etc/ssh/ssh_host_dsa_key dla protokołu ssh2. # # Warto zauważyć, że sshd nie użyje pliku # # udostępnionego komukolwiek poza użytkownikiem. Możesz # # użyć wielu plików kluczy, klucze to „rsa1” # # dla protokołu ssh1 i „dsa”/„rsa” dla protokołu ssh2. # # # HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key ## ############################### ############################# ########## Opcje protokołu SSH w wersji 1 (ssh1) ### ########## ######################################## #################### # Zdecydowanie NIE ZALECA SIĘ używania protokołu ssh1. # # Protokół ssh2 jest znacznie bezpieczniejszy niż ssh1 # ######################################## ##################### # # ## Interwał regeneracji klucza ####################### # ######## # # # Dla protokołu ssh1 - jednorazowo o określonej godzinie # # nowy tymczasowy klucz serwera ## jest generowany automatycznie (jeśli był używany). Odbywa się to # # aby uniemożliwić odszyfrowanie porwanych sesji, aby # # później zalogować się do maszyny z parametrami tych sesji i # # ukraść klucze. Ten klucz nie jest nigdzie przechowywany (przechowywany w # # pamięć o dostępie swobodnym). Ta dyrektywa określa # # okres istnienia klucza w sekundach, po którym # # zostanie on ponownie wygenerowany. Jeśli wartość jest ustawiona na 0 - # # klucz nie zostanie wygenerowany ponownie. # # Wartość domyślna to 3600 (sekund). # # # KeyRegenerationInterval 3600 # # ## RhostsRSAAuthentication ################################# # # # Wskazuje, czy na # # plikach rhosts lub /etc/hosts.equiv, wraz z udanym # # uwierzytelnieniem hosta przez RSA. # # Dotyczy tylko protokołu ssh1. # # Wartość domyślna to „nie”. # # # RhostsRSAAuthentication nr # # ## RSAAuthentication #################################### # # # Wskazuje, czy dozwolone jest „czyste” uwierzytelnianie RSA. # # Dotyczy tylko protokołu ssh1. # # Wartość domyślna to „tak”. # # # RSAAuthentication tak # # ## ServerKeyBits ######################################## ### # # # Określa liczbę bitów w tymczasowym kluczu serwera dla # # protokołu ssh1. Minimalna wartość to 512. # # Wartość domyślna to 1024. # ServerKeyBits 768 ## ################################ ########################### ########### Opcje protokołu SSH w wersji 2 (ssh2) #### ######## ########################################## ################## # # ## Szyfry ########################### ###################### # # # Określa algorytmy szyfrowania dozwolone dla # # protokołu ssh2. Wiele algorytmów powinno być # # oddzielonych przecinkami. Obsługiwane algorytmy: # # „3des-cbc”, „aes128-cbc”, „aes192-cbc”, „aes256-cbc”, # # „aes128-ctr”, „aes192-ctr”, „aes256-ctr”, „ arcfour128”, # # „arcfour256”, „arcfour”, „blowfish-cbc”, „cast128-cbc”. # # Wartości domyślne to: # # aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128, # # arcfour256,arcfour,aes192-cbc,aes256-cbc,aes128-ctr, # # aes192-ctr, aes256 -ctr # # # ## HostbasedAuthentication ################################ # # # Określa, czy uwierzytelnianie jest dozwolone na podstawie na # # sprawdzaniu hosta. Sprawdź rhosts lub /etc/hosts.equiv, # # i jeśli się powiedzie, w połączeniu z pomyślnym sprawdzeniem # # klucza publicznego, dostęp jest przyznany. Ta dyrektywa jest # # taka sama jak dyrektywa RhostsRSAAuthentication i # # dotyczy tylko protokołu ssh2. # # Wartość domyślna to "nie". # # # Hostbased Authentication nie # # ## MAC ######################################## ############ # # # Wskazuje poprawny algorytm MAC (komunikat ## kod uwierzytelniający). Algorytm MAC używany # # przez protokół ssh2 do ochrony integralności danych. Wiele algorytmów # # musi być oddzielonych przecinkami. # # Wartości domyślne to: # # hmac-md5,hmac-sha1, [e-mail chroniony] ,hmac-ripemd160, # # hmac-sha1-96,hmac-md5-96 # # # ## PubkeyAuthentication ########################## ########## # # # Wskazuje, czy uwierzytelnianie kluczem publicznym ## jest dozwolone. Dotyczy tylko protokołu ssh2. # # Wartość domyślna to „tak”. # # # PubkeyAuthentication tak ########################################### ############### #################### Opcje GSSAPI ############# ############# ##################################### ####################### # # ############ Dotyczy tylko protokołu ssh2 ######## ### # # ## GSSAPIAuthentication #################################### # # # Określa, czy Uwierzytelnianie użytkowników # # opiera się na GSSAPI. Wartość domyślna to „nie”, tj. zakazana. # # # ## GSSAPIKeyExchange #################################### # # # Wskazuje, czy klucz wymiana oparta na # # GSSAPI jest dozwolona. Wymiana kluczy GSSAPI nie polega na # # kluczach ssh do weryfikacji tożsamości hosta. # # Domyślnie jest to "nie" - tj. wymiana jest zabroniona. # # # ## GSSAPICleanupCredentials ############################### # # # Określa, czy automatycznie niszczyć # # uwierzytelnianie użytkownika pamięć podręczna poświadczeń po # # zakończeniu sesji. # # Domyślnie jest to "tak" - tj. muszą zostać zniszczone. # # # ## GSSAPIStrictAcceptorCheck ############################## # # # Określa, jak rygorystyczne powinno być sprawdzanie tożsamości # # klient podczas uwierzytelniania przez GSSAPI. # # Wartość „yes” powoduje, że klient # # uwierzytelnia się w usłudze hosta odbierającego na bieżącym hoście. Wartość „no” # # umożliwia klientowi uwierzytelnienie za pomocą dowolnego # # klucza usługi. # # Domyślna wartość to "tak". # # Zauważ, że ustawienie go na "nie" może działać # # tylko z rzadkimi bibliotekami Kerberos GSSAPI. #### ############################################### # ############# ################### Opcje Kerberos ############### # ######### ######################################## # ################### # # ## Uwierzytelnianie Kerberos ######################### # ######## # # # Wskazuje, czy hasło podane ## przez użytkownika w celu uwierzytelnienia ## (PasswordAuthentication) wymaga weryfikacji w KDC Kerberos. # # Aby użyć tej opcji, serwer musi # # sprawdzić, czy KDC jest prawdziwe. (Serwer potrzebuje servtab # # Kerberos, która umożliwia weryfikację tożsamości # # KDC) # # Domyślnie jest to „nie”. # # # ## KerberosGetAFSToken ##################################### # # # Jeśli AFS jest aktywny a użytkownik otrzymał bilet TGT Kerberos 5, # # czy spróbować uzyskać token AFS, zanim użytkownik # # uzyska dostęp do swojego folderu domowego. # # Wartość domyślna to „nie”. # # # ## KerberosOrLocalPasswd ################################### # # # Określa sposób postępowania w przypadku jeśli uwierzytelnianie # # za pomocą protokołu Kerberos nie powiodło się. Jeśli # # wartość to "yes", hasło zostanie # # zweryfikowane przy użyciu dowolnego dodatkowego lokalnego mechanizmu autoryzacji, # # na przykład - /etc/passwd. # # Wartość domyślna to „tak”. # # # ## KerberosTicketCleanup ################################### # # # Określa, czy automatycznie zabijać plik z # # pamięcią podręczną biletu użytkownika po zakończeniu sesji. # # Wartość domyślna to „tak”. #### ############################################### # ############# ################# Opcje przekierowania ################# # ## ############################################### ## ############ # # ## AllowAgentForwarding ############################### # ### # # # Określa, czy włączyć, czy wyłączyć przekierowanie ssh-agenta # #. Wartość domyślna to „tak”, tj. zezwól. # # Należy pamiętać, że wyłączenie przekierowania # # nie zwiększy # # bezpieczeństwa, chyba że użytkownicy również odmówią # # dostęp do powłoki, ponieważ ## mogą zainstalować własne odpowiedniki agentów ###### ## AllowTcpForwarding ###################### ########## ###### # # # Określa, czy zezwolić, czy wyłączyć przekierowanie TCP # # Wartość domyślna to „tak”, tj. zezwolić Należy pamiętać, że # #, podobnie jak w przypadku AllowAgentForwarding, # # przekierowywanie nie poprawi bezpieczeństwa tak długo jako ## użytkownicy mają dostęp do konsoli, ponieważ mogą ## instalować swoje odpowiedniki ## # # # ## GatewayPorts ######### ## ################################# # # # Określa, czy zezwolić zdalne hosty dostęp do ## przekazanych portów. Domyślnie sshd nasłuchuje # # tylko dla przekierowanych portów na lokalnym interfejsie # # (pętla zwrotna). Uniemożliwia to innym zdalnym hostom łączenie się # # z przekierowanymi portami. Możesz # # użyć GatewayPorts, aby zezwolić sshd na # # zrobienie tego. Dyrektywa może przyjąć 3 wartości: # # "no" - tylko pętla zwrotna. # # "tak" - dowolne adresy. # # "określony przez klienta" - adresy podane przez klienta. # # # ## ZezwólOpen ######################################### # # # # # Określa, gdzie dozwolone jest przekazywanie portów TCP. # # Wskazówka dotycząca przekierowania musi mieć jedną z # # następujących form: # # PermitOpen host:port # # PermitOpen IPv4_addr:port # # PermitOpen :port # # Można określić wiele wpisów, oddzielając je spacjami. # # Argument "dowolny" może być użyty do usunięcia wszystkich # # ograniczeń przekierowania portów. Domyślnie każde # # przekierowanie jest dozwolone. # # # ## PermitTunnel ######################################### # # # Wskazuje, czy dozwolone jest przekierowanie urządzenia tun. # # Można ustawić na: # # „tak” # # „od punktu do punktu” (trzecia warstwa sieci) # # „ethernet” (druga warstwa sieci) # # „nie” # # Wartość „tak” umożliwia zarówno „ punkt-punkt" # # i "ethernet" w tym samym czasie. Wartość domyślna to „nie”. #### ############################################### # ############# ################## Opcje logowania ################ ############################################## ## ############# ## ## SyslogFacility ############################## # ########## # # # Określa kod obiektu dziennika do zapisywania komunikatów w ## dzienniku syslog z sshd. Możliwe wartości: # # DAEMON ## USER ## AUTH # # LOCAL0 # # LOCAL1 # # LOCAL2 # # LOCAL3 # # LOCAL4 # # LOCAL5 # # LOCAL6 # # LOCAL7 # # Wartość domyślna to AUTH. # # # SyslogFacility AUTH ## ## LogLevel ######################################## ######## # # # Ustawia poziom szczegółowości dziennika sshd. # # Opcje to: # # CICHY ## CICHY ## KRYTYCZNY ## BŁĄD ## INFO ## GŁOŚNY ## DEBUG ## DEBUG1 # # DEBUGOWANIE2 # # DEBUGOWANIE3 # # Domyślnie jest to INFO. # # DEBUG i DEBUG1 są sobie równoważne. # # DEBUG2 i DEBUG3 ustawiają najwyższe poziomy wyjścia debugowania # #. Logowanie na poziomie DEBUG ## zagraża prywatności użytkownika i nie jest zalecane. # # # LogLevel INFO # # ######################################## # ################ ################### X11 przekierowanie ############ # ####### ########################################## # ################# # # ## X11Przekazywanie ########################## ## ############## # # # Wskazuje, czy przekierowanie grafiki X11 ## jest dozwolone. Może przyjmować wartości „tak” lub „nie”. # # Wartość domyślna to „nie”. # # Ostrzeżenie - włączenie prostego przekierowania X11 jest # # dużym ryzykiem zarówno dla serwera, jak i dla klientów, ponieważ w # # tym przekierowaniu wyświetlacz proxy sshd będzie # # akceptował połączenia z dowolnego adresu. # # Użyj dyrektywy X11UseLocalhost, aby ograniczyć dostęp do # # serwera przekierowań X. Warto zauważyć, że # # wyłączenie przekierowań nie gwarantuje, że # # użytkownicy nie będą mogli przekierować X11, ponieważ mając # # dostęp do konsoli, zawsze ustawiają # # swój readresator. Przekierowanie X11 zostanie # # automatycznie wyłączone, jeśli # # zostanie użyta dyrektywa UseLogin. # # # X11Forwarding tak # # ## X11UseLocalhost ####################################### # # # # Określa, czy sshd powinien # # ograniczać przekierowanie X11 do lokalnego adresu pętli zwrotnej, czy # # zezwalać na dowolne adresy. Domyślnie - sshd # # "ląduje" serwer przekierowań X11 na lokalny adres# # i ustawia część nazwy hosta w zmiennej środowiskowej DISPLAY # # na "localhost". Zauważ, że # # niektóre starsze klienty X11 mogą nie działać # # z tymi ustawieniami. Wartość domyślna to „tak”, tj. # # przekierowanie jest ograniczone do lokalnego hosta, wartość to "nie" - # # wyłącza ograniczenia. # # # ## XAuthLocation ######################################## # # # Określa pełną ścieżkę do programu xauth. # # Domyślnie jest to /usr/bin/X11/xauth. # # # ## X11DisplayOffset #################################### # # # Wskazuje numer pierwszego ekranu dostępnego dla sshd # # jako przekierowanie X11. Odbywa się to tak # #, że przekierowane x nie pokrywają się z # # prawdziwymi. Wartość domyślna to 10. # # # X11DisplayOffset 10 # # ##################################### # ##################### ################### Różne opcje ####### # ################ ################################# # ########################## # # ## LoginGraceTime ################## # ####################### # # # Czas, po którym serwer rozłączy ## użytkownika, jeśli nie uda mu się ## logować w sposób zadowalający. Wartość 0 - pozwala użytkownikowi # # na logowanie w nieskończoność. Wartość domyślna to 120 (sekund). # ## LoginGraceTime 120 ## ## MaxAuthTries ######################################### # ### # # # Wskazuje maksymalny numer próby uwierzytelnienia # # dozwolone na połączenie. # # Jak tylko liczba nieudanych prób przekroczy połowę # # ustalić wartość, wszystkie kolejne próby będą # # rejestrowane. Wartość domyślna to 6. # # # ## MaxSession ##################################### # ###### # # # Określa maksymalną liczbę jednoczesnych połączeń ## dla każdego połączenie internetowe. Wartość domyślna to 10. # # # ## MaxStartups ####################################### # ##### # # # Określa maksymalną liczbę jednoczesnych # # nieautoryzowanych połączeń z sshd. W przypadku # # liczba połączeń przekroczy limit - wszystkie dodatkowe # # połączenia zostaną odrzucone, dopóki bieżące # # połączenia nie zostaną zakończone albo przez pomyślną autoryzację, # # albo przez wygaśnięcie okresu czasu określonego w # # dyrektywie LoginGraceTime . Domyślna wartość to 10. # # Opcjonalnie można ustawić wcześniejsze zerwanie połączeń, # # określając trzy wartości oddzielone # # dwukropkiem „start:rate:full” (np.: „10:30:60”). # # sshd odrzuci próbę połączenia z prawdopodobieństwem # # „rate/100” (tj. 30% w naszym przykładzie), jeśli # # istnieją już „start” (10) nieautoryzowanych połączeń. # # Prawdopodobieństwo wzrasta liniowo i # # wszelkie próby połączenia zostaną odrzucone, jeśli liczba # # nieautoryzowanych połączeń osiągnie „pełną” (60). # ## ## Kompresja ########################################## # # # # Wskazuje, czy kompresja danych jest włączona. Może być # # "tak" - kompresja jest włączona. # # "opóźniona" - kompresja jest opóźniona do # # pomyślnego uwierzytelnienia użytkownika. # # "nie" - kompresja jest wyłączona. # # Domyślnie jest to "opóźnione". # # # ## UżyjLogin ######################################### # ### # # # Wskazuje, czy logowanie powinno być używane w # # sesji interaktywnej. Wartość domyślna to „nie”. # # Warto zauważyć, że logowanie nigdy nie było używane # # do wykonywania zdalnych poleceń. Zwróć też uwagę, że # # używanie login wyłączy # # dyrektywę X11Forwarding, ponieważ login nie wie, co # # zrobić z xauth. Jeśli dyrektywa # # UsePrivilegeSeparation jest włączona - zostanie wyłączona po # # autoryzacji. #### ## UsePrivilegeSeparation ################################# # # # Określa, czy sshd ma rozdzielać uprawnienia. Jeśli tak # # to nieuprzywilejowany proces potomny # # zostanie utworzony jako pierwszy dla przychodzącego ruchu sieciowego. Po pomyślnej autoryzacji, # # zostanie utworzony kolejny proces z # # uprawnieniami zalogowanego użytkownika. # # # Podstawowym celem współdzielenia uprawnień jest zapobieganie nadpisaniom. # # Wartość domyślna to „tak”. # # # UsePrivilegeSeparation tak ###################################### ## ### # # # Określa, czy sshd powinien sprawdzać tryby dostępu i # # własność foldery użytkownika i pliki przed # # wpuszczeniem użytkownika. Zwykle dzieje się tak, ponieważ # # nowicjusze często sprawiają, że ich pliki są zapisywalne # # przez wszystkich.Domyślnie jest to „tak”. # # # StrictModes tak # # ## AkceptujEnv ######################################## ####### # # # Określa, które zmienne środowiskowe przekazane # # przez klienta będą akceptowane. Zobacz opcję SendEnv w kliencie. # # Zauważ, że przekazywanie zmiennych jest możliwe tylko # # dla protokołu ssh2. Zmienne są określane według nazwy, # # można używać symboli wieloznacznych ('*' i '?'). Możesz określić # # wiele zmiennych oddzielonych spacjami lub # # złamać wiele wierszy AcceptEnv. Bądź ostrożny - niektóre # # zmienne środowiskowe mogą być użyte do ominięcia # # zabronionych środowisk użytkownika. # # Używaj tej dyrektywy ostrożnie. Domyślnie nie są akceptowane # # niestandardowe zmienne środowiskowe. # # # AcceptEnv LANG LC_* # # ## PermitUserEnvironment ################################## # # # Określa czy sshd powinien # # akceptować ~/.ssh/environment i opcję environment= w # # ~/.ssh/authorized_keys. Wartość domyślna to „nie”. Warto # # zauważyć, że włączenie obsługi środowiska może dać # # użytkownikom możliwość ominięcia ograniczeń w niektórych # # konfiguracjach przy użyciu mechanizmów takich jak # # LD_PRELOAD. # # # # # ## PidFile ####################################### # ###### # # # Określa plik zawierający identyfikator procesu # # (identyfikator procesu, PID) demona SSH. # # Domyślnie jest to /var/run/sshd.pid # # # # # ## PrintLastLog ############################ ## ############# # # # Określa, czy sshd ma wyświetlać datę i godzinę # # ostatniej sesji, gdy użytkownik loguje się interaktywnie. # # Wartość domyślna to „tak”. # # # PrintLastLog tak # # ## PrintMotd ######################################## ####### # # # Określa, czy sshd powinien drukować /etc/motd # #, gdy użytkownik loguje się interaktywnie. W niektórych # # systemach (np. Ubuntu) informacja ta jest również # # wyświetlana przez powłokę. # # Wartość domyślna to „tak”. # # # PrintMotd nie ## ## Baner ####################################### # ######### # # # Określa, który plik zawiera baner tekstowy ##, który będzie wyświetlany użytkownikowi PRZED procedurą uwierzytelniania ##. Opcja dostępna tylko dla protokołu ssh2.# # Domyślnie - nic nie pokazuje. # # W Ubuntu plik issue.net zawiera frazę Ubuntu (wersja), # # np. dla karmicznego jest to "Ubuntu 9.10". # # może być użyty do zmylenia potencjalnych napastników, ## pisząc „Mój router internetowy D-Link” =) # # # Baner /etc/issue.net # # ## ChrootDirectory ########### # ############################# # # # Jeśli określono, podaje ścieżkę do # # chroot po uwierzytelnieniu. Ścieżka i cała jej # # zawartość musi odpowiadać # # folderom należącym do superużytkownika i nie może być # # zapisywana przez innych użytkowników. # # Ścieżka może zawierać etykiety, które są podstawiane w # # procesie uwierzytelniania: # # %% — zastępowane przez dosłowne „%” # # %h — zastępowane katalogiem domowym # # uwierzytelnianego użytkownika # # %u - zastąpiony nazwą uwierzytelnianego użytkownika # # chroot -folder powinien zawierać wszystkie niezbędne pliki i # # foldery dla sesji użytkownika. Sesja interaktywna # # wymaga co najmniej: # # powłoki, zwykle sh # # podstawowych urządzeń w /dev, takich jak: # # null, zero, stdin, stdout, stderr, arandom i tty # # dla sesji przesyłania danych przy użyciu brak sftp # # zaawansowane ustawienia nie jest potrzebne, jeśli używasz # # wewnętrznego procesu sftp serwera. Zobacz Podsystem # # więcej informacji. Domyślnie chroot nie jest wykonywany. # # # ## ForceCommand ######################################### # # # Powoduje wykonanie podanego polecenia. Ignoruje # # wszelkie polecenia wydane przez klienta lub zapisane w # # ~/.ssh/rc. Polecenie jest wywoływane z # # powłoki użytkownika z opcją -c. Nadaje się do uruchamiania powłoki, # # polecenia lub podsystemu. Najbardziej przydatne w bloku # # Match. Komenda oryginalnie wysłana przez klienta jest przechowywana # # w zmiennej środowiskowej SSH_ORIGINAL_COMMAND. Jeśli # # określono polecenie "internal-sftp", # # zostanie uruchomiony wewnętrzny serwer sftp, który nie potrzebuje # # dodatkowych plików i folderów opisanych w dyrektywie ChrootDirectory. # # # ## Podsystem ######################################### # ## # # # Definiuje i konfiguruje zewnętrzny podsystem (na przykład # # demon transferu plików - transfer plików demon). # # Argumentami są nazwa i polecenie (z możliwymi # # argumentami), które będą wykonywane podczas zapytania # # w podsystemach. Polecenie sftp-server uruchamia podsystem transferu plików „sftp” # #. Opcjonalnie możesz # # określić „internal-sftp” jako podsystem, # # który uruchomi wewnętrzny serwer sftp. Może to znacznie uprościć # # konfigurację przy użyciu # # dyrektywy ChrootDirectory # # Domyślnie nie są wywoływane żadne podsystemy. Dotyczy tylko protokołu ssh2. # # # Podsystem sftp /usr/lib/openssh/sftp-server ## ################################ # ########################## ##################### Blok dopasowania # ########################## ######################## ###################################### # # # Specjalnie przesunięty na koniec pliku, aby go wygodniej # # napisz zasady dopasowania. # # Szalony Koks. # # # # Dyrektywa Match jest początkiem # # bloku warunkowego. Jeśli wszystkie kryteria określone w # # Wierszu dopasowania są spełnione, dyrektywy w kolejnych wierszach bloku są wykonywane, # # pozwalając na pominięcie wartości globalnych dyrektyw sshd_config # # dla przypadku, który # # pasuje do kryteria dyrektywy. Blok to wszystkie wiersze następujące po wierszu # # z kryterium (Dopasuj - wiersze) do następnego wiersza dopasowania # # lub do końca pliku. Argumentem dyrektywy Match jest jedna lub # # więcej par wpisów kryteriów. Możliwe typy rekordów to: # # Użytkownik # # Grupa # # Host # # Adres # # Rekordy mogą zawierać pojedyncze wartości # # (np. Użytkownik=użytkownik) lub wiele wartości # # oddzielonych przecinkami (Użytkownik=użytkownik1,użytkownik2 ). # # Można również użyć wyrażeń regularnych opisanych w # # sekcji PATTERNS pliku ssh_config. Wpisy w # # Kryterium adresu mogą zawierać adresy w notacji CIDR # # (Adres/Długość maski, na przykład „192.0.2.0/24” lub # # „3ffe:ffff::/32”). Warto zauważyć, że podana długość maski # # musi być zgodna z adresem, a # # zbyt długa/krótka dla adresu nie zadziała. # # Dyrektywy dopasowania mogą używać tylko # # określonego zestawu dyrektyw: # # AllowTcpForwarding ## Banner # # ChrootDirectory # # ForceCommand # # GatewayPorts # # GSSAPIAuthentication # # HostbasedAuthentication # # KbdInteractiveAuthentication # # KerberosAuthentication # # #MaxAuthentication # # #MaxAuthentication # # PasswordAuthentication ## PermitOpen ## PermitRootLogin ## RhostsRSAAuthentication ## RSAAuthentication ## X11DisplayOffset ## X11Forwarding ## X11UseLocalHost #
Możesz skopiować powyższy tekst do własnego sshd_config i użyć go później do konfiguracji.
Źle skonfigurowany serwer SSH sam w sobie stanowi ogromną lukę w zabezpieczeniach, ponieważ potencjalny atakujący ma możliwość uzyskania prawie nieograniczonego dostępu do systemu. Poza tym sshd ma wiele dodatkowych przydatne opcje, które chcesz włączyć, aby poprawić użyteczność i bezpieczeństwo.
Port, ListenAddress i AddressFamily
Te trzy opcje określają, na których portach i adresach serwer będzie nasłuchiwał połączeń przychodzących. Po pierwsze, sensowne jest, jeśli to możliwe, ograniczenie rodziny przetwarzanych adresów do faktycznie używanych, to znaczy, jeśli używasz tylko IPv4, wyłącz IPv6 i odwrotnie. Można to zrobić za pomocą parametru AddressFamily, na przykład (aby zezwolić na IPv4 i odmówić IPv6):
AdresRodzina inet
Po drugie, pożądana jest zmiana standardowego portu (22), na którym nasłuchuje sshd. Wynika to z faktu, że liczne skanery sieciowe ciągle próbuje połączyć się z 22. portem i przynajmniej uzyskać dostęp poprzez wyliczenie loginów / haseł z ich bazy danych. Nawet jeśli masz wyłączone uwierzytelnianie hasłem, te próby zapychają dzienniki i (w w dużych ilościach) może negatywnie wpłynąć na szybkość serwera ssh. Jeśli z jakiegoś powodu nie chcesz zmieniać standardowego portu, możesz użyć różnych zewnętrznych narzędzi do zwalczania brute-forcerów, takich jak fail2ban lub wbudowanych, takich jak MaxStartups .
Możesz ustawić port jako wartość bezwzględną dla wszystkich interfejsów za pomocą dyrektywy Port lub konkretne znaczenie dla każdego interfejsu za pomocą dyrektywy ListenAddress. Na przykład:
Port 2002
Adres nasłuchiwania 192.168.0.1:2003 Adres nasłuchiwania 192.168.1.1:2004
Wyłącz zdalny dostęp dla superużytkownika
Domyślnie dostęp roota jest odmawiany za pomocą hasła (kluczem - możesz) - opcja PermitRootLogin jest ustawiona na without-password . Ale pod warunkiem, że domyślnie Użytkownik Ubuntu, dodana podczas instalacji systemu ma możliwość wykonywania wszystkich zadań administracyjnych poprzez sudo, stworzenie możliwości rootowania dostępu do systemu przez ssh - wygląda nierozsądnie (nawet przy uwierzytelnianiu kluczem). Zaleca się, aby całkowicie go wyłączyć. tę opcję lub zastosuj ją tylko w trybie wymuszonych tylko poleceń. Możesz wyłączyć dostęp roota w ten sposób:
PermitRootZaloguj się nie
Uwierzytelnianie hasłem
Domyślnie włączone uwierzytelnianie hasłem jest praktycznie najbardziej prymitywnym sposobem logowania do sshd. Z jednej strony upraszcza to konfigurację i podłączanie nowych użytkowników (wystarczy, że użytkownik zna swój login/hasło systemowe), z drugiej strony hasło zawsze można odgadnąć, a użytkownicy często zaniedbują tworzenie złożonych i długie hasła. Specjalne boty nieustannie skanują serwery ssh dostępne w Internecie i próbują się do nich zalogować, wyliczając loginy/hasła ze swojej bazy danych. Zdecydowanie zaleca się, aby nie używać uwierzytelniania hasłem. Możesz to wyłączyć w ten sposób:
Hasło Uwierzytelnianie nie
Jeśli z jakiegoś powodu nadal chcesz korzystać z uwierzytelniania hasłem - upewnij się, że nikt nie może zalogować się pustym hasłem. Aby to zrobić, ustaw dyrektywę PermitEmptyPasswords:
Zezwól na pusteHasła nie
Protokoły SSH1 i SSH2
Jak już wspomniano, sshd może współpracować z protokołami SSH1 i SSH2. Jednak korzystanie z niezabezpieczonego SSH1 jest wysoce odradzane. Możesz zmusić sshd do pracy tylko z protokołem SSH2 w następujący sposób:
Uwierzytelnianie klucza RSA SSH2
Preferowaną metodą autoryzacji jest uwierzytelnianie kluczem SSH2 RSA. Dzięki tej metodzie użytkownik generuje po swojej stronie parę kluczy, z których jeden jest tajny, a drugi publiczny. Klucz publiczny jest kopiowany na serwer i służy do weryfikacji tożsamości użytkownika. Aby uzyskać więcej informacji na temat tworzenia pary kluczy i umieszczania ich na serwerze, zobacz opis klienta SSH. Możesz włączyć uwierzytelnianie klucza publicznego w następujący sposób:
PubkeyAuthentication tak
Serwer musi wiedzieć, gdzie powinien szukać klucza publicznego użytkownika. Używany jest do tego specjalny plik Author_keys. Jego składnia może wyglądać następująco:
# Komentarze są pisane tylko z Nowa linia# ogólny widok wpisów w plikuauthor_keys # [opcje] key_type (ssh-rsa lub ssh-dss) very_long_string_incomprehensible_to_ordinary_human [login@host] ssh-rsa AAAAB3Nza...LiPk== [e-mail chroniony] from="*.sprzedaz.przyklad.net,!pc.sprzedaz.przyklad.net" ssh-rsa AAAAB2...19Q== [e-mail chroniony] command="dump /home",no-pty,no-port-forwarding ssh-dss AAAAC3...51R== example.net allowopen="192.0.2.1:80",permitopen="192.0.2.2:25" ssh -dss AAAAB5...21S== tunnel="0",command="sh /etc/netstart tun0" ssh-rsa AAAA...== [e-mail chroniony]
Możesz określić zarówno jeden udostępniony plik z kluczami, jak i jeden plik dla każdego użytkownika. Ostatni sposób jest wygodniejsze i bezpieczniejsze, ponieważ po pierwsze można określić różne kombinacje klawiszy dla każdego użytkownika, a po drugie ograniczyć dostęp do klucza publicznego użytkownika. Możesz ustawić plik z kluczami za pomocą dyrektywy AuthorizedKeysFile:
AuthorizedKeysFile %h/.ssh/my_keys Na kliencie ustaw parametry w pliku /etc/ssh/ssh_config (domyślnie wyłączone):
ForwardAgent tak ForwardX11 tak
Możesz go uruchomić na kliencie w ten sposób ssh [e-mail chroniony] ognik. Albo najpierw idziemy ssh [e-mail chroniony] następnie uruchom np. sudo synaptic .
SFTP
sshd ma domyślnie wbudowany serwer SFTP. SFTP (SSH File Transfer Protocol) - protokół SSH do przesyłania plików. Jest przeznaczony do kopiowania i wykonywania innych operacji na plikach na niezawodnej i bezpieczne połączenie. Z reguły protokół SSH2 jest używany jako podstawowy protokół zapewniający połączenie. Aby włączyć obsługę SFTP, dodaj linię do sshd_config
Podsystem sftp /usr/lib/openssh/sftp-server
Domyślnie obsługa SFTP jest włączona.
Stosowanie kryteriów. Dyrektywa dopasowania
2. Przygotowanie serwera. Musisz upewnić się, że konfiguracja sshd umożliwia uwierzytelnianie za pomocą kluczy publicznych. Aby to zrobić, musisz określić wartość parametru „PubkeyAuthentication” w pliku „sshd_config” na „yes”. Następnie dodajemy otrzymany wcześniej klucz publiczny (w jednej linii) do pliku „~/.ssh/authorized_keys”. Należy pamiętać, że plik „.ssh/authorized_keys” znajduje się w katalogu domowym użytkownika, który następnie zaloguje się przy użyciu klucza publicznego.
3. Część klienta w systemie Linux. Będziesz musiał przebudować pakiet OpenSSH bez opcji. Zalecane jest określenie tylko przedrostków katalogów, takich jak --prefix=/usr. Zauważ też, że pliki konfiguracyjne będą znajdować się w /usr/etc. Przed rozpoczęciem potrzebne są pakiety: opensc-lite-devel, zlib-devel, openssl-devel. Zainstaluj sterownik karty inteligentnej. Dla wygody w konfiguracji ssh_config (nie mylić z sshd_config) podaj ścieżkę do biblioteki pkcs: PKCS11Provider=<путь к библиотеке>
4. Uruchom ssh na kliencie [e-mail chroniony] Jeśli karta inteligentna (token) jest podłączona, zostanie zażądane hasło i zalogowana zostanie sesja SSH.
Oznacza to, że użytkownik1 może być zarejestrowany zarówno dla siebie - w pliku /home/user1/.ssh/keys), jak i dla innego użytkownika, co pozwoli mu zalogować się ze swojego komputera zarówno „pod sobą”, jak i pod „inny”
SSH to jedno z najważniejszych narzędzi do administrowania systemem.
SSH lub Secure Shell (bezpieczna powłoka) to protokół używany do bezpieczne połączenie do systemów zdalnych. Jest to najczęstszy sposób łączenia się ze zdalnymi serwerami Linux i Unix (np. VPS).
Ten samouczek skupi się na używaniu SSH do łączenia się z systemem zdalnym.
Podstawowa składnia
Aby połączyć się ze zdalnym systemem za pomocą SSH w Linuksie, istnieje narzędzie o tej samej nazwie - ssh.
Podstawowy typ polecenia:
ssh zdalny_host
W tym przykładzie fraza „zdalny_host” zastępuje adres IP lub Nazwa domeny hosta, z którym chcesz się połączyć.
Ta komenda zakłada, że nazwa użytkownika w systemie zdalnym i lokalnym jest taka sama.
Jeśli w systemie zdalnym ustawiona jest inna nazwa użytkownika, należy ją określić przy użyciu następującej składni:
ssh nazwa_użytkownika@komputer zdalny
Po połączeniu się z serwerem musisz podać hasło, aby przejść autoryzację.
Procedura generowania kluczy, których można użyć zamiast hasła, zostanie opisana w dalszej części.
Aby wrócić do sesji lokalnej, po prostu wpisz:
Jak działa SSH?
SSH działa poprzez połączenie programu klienta z serwerem ssh.
W powyższych poleceniach ssh jest programem klienckim. Serwer ssh już działa na określonym zdalnym hoście.
Jeśli serwer ssh nie jest jeszcze uruchomiony na VPS, kliknij przycisk „Dostęp do konsoli” znajdujący się na stronie serwera. Spowoduje to wyświetlenie ekranu autoryzacji. Użyj swoich danych logowania, aby się zalogować.
Ogólnie proces uruchamiania serwera ssh zależy od używanej dystrybucji Linuksa.
W Ubuntu, aby uruchomić serwer ssh na VPS, wpisz:
Sudo service sshd start
Konfiguracja SSH
Zmiana ustawień SSH powoduje również zmianę ustawień serwera SSH.
W Ubuntu główny plik konfiguracyjny SSH znajduje się w /etc/ssh/sshd_config.
Tworzyć utworzyć kopię zapasową aktualna wersja tego pliku przed edycją:
Sudo cp /etc/ssh/sshd_config(,.bak)
Otwórz go za pomocą edytora tekstu:
sudo nano /etc/ssh/sshd_config
Niektóre ustawienia wymagają szczególnej uwagi, na przykład:
Ta linia określa, na którym porcie serwer ssh będzie nasłuchiwał połączeń. Domyślnie jest to port 22.
Wskazane jest użycie niestandardowego portu w celu ochrony serwera przed przypadkowym skanowaniem portów. Później pokażemy, jak połączyć się z nowym portem.
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
Linie HostKey wskazują, gdzie znajdują się klucze hosta (więcej o kluczach hosta później).
SyslogFacility
Informacje o poziomie dziennika
Te wiersze zawierają ustawienia rejestrowania i określają poziom rejestrowania.
Jeśli wystąpią jakiekolwiek problemy z SSH, zaleca się zwiększenie poziomu dziennika (co zwiększa ilość zapisywanych danych).
ZalogujGraceTime 120
PermitRootZaloguj tak
Tryby ścisłe tak
Te parametry zawierają pewne informacje rejestracyjne.
ZalogujGraceTime Określa liczbę sekund, podczas których połączenie musi być utrzymywane bez autoryzacji.
Notatka: w tym wierszu ustaw trochę więcej czasu niż jest to zwykle konieczne do rejestracji.
ZezwolenieRootZaloguj określa możliwość zalogowania się jako użytkownik root.
W większości przypadków po utworzeniu użytkownika z podwyższonymi uprawnieniami (su lub sudo) i możliwością łączenia się przez ssh zaleca się ustawienie tej linii na „nie”
strictModes to urządzenie zabezpieczające, które odmówi wejścia, jeśli pliki uwierzytelniające są czytelne dla wszystkich.
Zapobiega to próbom logowania, jeśli pliki konfiguracyjne nie są bezpieczne.
X11 Przekazywanie tak
X11 Przesunięcie wyświetlacza 10
Te ustawienia konfigurują funkcję o nazwie X11 Forwarding, która umożliwia wyświetlanie graficznego interfejsu użytkownika (GUI) systemu zdalnego w systemie lokalnym.
Ta opcja musi być włączona zarówno na komputerze lokalnym, jak i zdalnym; aby skorzystać z tej funkcji, musisz przekazać klienta i opcję -X.
Poprzez edycję podany plik nie zapomnij zrestartować serwera ssh w celu aktywacji zmiany dokonane:
restart sshd usługi sudo
Ponadto wprowadzane zmiany muszą zostać dokładnie przetestowane, aby upewnić się, że wszystko działa zgodnie z oczekiwaniami.
Jeśli napotkasz problemy, pamiętaj, że możesz również zalogować się za pomocą przycisku „Dostęp do konsoli”.
Zaloguj się za pomocą kluczy SSH
Uwierzytelnianie oparte na kluczu jest często znacznie bezpieczniejsze niż logowanie się do zdalnego systemu za pomocą hasła.
Jak działa uwierzytelnianie oparte na kluczu?
Uwierzytelnianie oparte na kluczu polega na utworzeniu pary kluczy — prywatnego i publicznego.
Klucz prywatny znajduje się na komputerze klienta i musi być chroniony i utrzymywany w tajemnicy.
Klucz publiczny można przekazać każdemu i umieścić na dowolnym serwerze, do którego należy uzyskać dostęp.
Podczas próby połączenia przy użyciu pary kluczy serwer używa klucza publicznego do utworzenia wiadomości dla komputera klienckiego, którą można odczytać tylko przy użyciu klucza prywatnego.
Komputer kliencki wysyła następnie odpowiednią odpowiedź do serwera, aby serwer zrozumiał, że klient jest uprawniony.
Po skonfigurowaniu kluczy, cały proces odbywa się automatycznie w tło.
Generowanie kluczy SSH
Klucze SSH należy utworzyć na komputerze, z którego chcesz się połączyć (zwykle na komputerze lokalnym).
W wierszu poleceń wpisz:
ssh-keygen -t rsa
Aby zaakceptować ustawienia domyślne, naciśnij klawisz Enter. Klucze zostaną wygenerowane w ~/.ssh/id_rsa.pub i ~/.ssh/id_rsa.
Przejdź do katalogu .ssh, wpisując:
Zwróć uwagę na uprawnienia do plików:
ls-l
-rw-r--r-- 1 demo 807 9 września 22:15 autoryzowane_klucze
-rw------- 1 demo 1679 9 września 23:13 id_rsa
-rw-r--r-- 1 demo 396 9 września 23:13 id_rsa.pub
Jak widać, tylko właściciel ma prawo czytać i modyfikować plik id_rsa. Takie uprawnienia są niezbędne do zachowania klucza w tajemnicy.
Jednocześnie plik id_rsa.pub może być udostępniany, ponieważ posiada odpowiednie uprawnienia.
Przeniesienie klucza publicznego na serwer
Następujące polecenie skopiuje klucz publiczny na zdalny serwer:
ssh-copy-id zdalny_host
Spowoduje to otwarcie sesji SSH, która wymaga podania hasła.
Po wpisaniu hasła klucz publiczny zostanie skopiowany na serwer, co umożliwi ponowne zalogowanie się bez hasła.
Ustawienia klienta SSH
Podczas łączenia przez SSH można użyć kilku flag.
Niektóre z nich są potrzebne do ustawienia odpowiednich opcji w pliku ssh zdalnego hosta.
Na przykład, jeśli numer portu w konfiguracjach ssh na hoście lokalnym został zmieniony, należy ustawić odpowiedni port po stronie klienta, wpisując:
ssh -p numer portu zdalny host
Jeśli polecenie musi zostać wykonane w systemie zdalnym, można je określić w następujący sposób:
ssh remote_host pożądana_komenda
Ta linia nawiąże połączenie ze zdalną maszyną i wykona określone polecenie.
Jak już wspomniano, jeśli funkcja przekazywania X11 jest włączona na obu komputerach, można jej użyć, wpisując:
ssh -X zdalny_host
Jeśli system lokalny posiada wszystkie odpowiednie narzędzia programowe z GUI używany w systemie zdalnym otworzy się na komputerze lokalnym.
Wyniki
Nauka pracy z SSH jest bardzo ważna, choćby dlatego, że jest niezbędna do wykonywania najbardziej podstawowych zadań.
Dzięki stałemu korzystaniu z SSH możesz nie tylko zabezpieczyć serwer, ale także zostać zaawansowanym użytkownikiem, co znacznie uprości Twoje życie. Protokół SSH pozostaje popularny, ponieważ jest bezpieczny, niezawodny i przydatny w różnych sytuacjach.
Tagi: ,Yossi
Yossi
Przepraszam, problem rozwiązany
Zorientowaliśmy się, co? SSH i jakie są jego zalety, wdrożyliśmy też najprostszy przykład szi- serwer i klient.
Dziś opowiem o więcej szczegółowe ustawienie szi- serwer.
Jak mówi słynne zdanie „in linux wszystko jest plikiem", więc aby skonfigurować szi- serwera, konieczna i wystarczająca jest edycja jednego pliku konfiguracyjnego. Jego pełna ścieżka to /etc/ssh/sshd_config. Aby edytować, otwórz ten plik z prawami administratora w dowolnym edytorze tekstu.
Przed edycją zróbmy to na wszelki wypadek utworzyć kopię zapasową plik:
Sudo cp /etc/ssh/sshd_config(,.bak)
Zobaczmy teraz jego zawartość:
sudo nano /etc/ssh/sshd_config
Po każdej zmianie w tym pliku należy ponownie uruchomić szi- serwer, aby zastosować nasze zmiany.
Jak widać, parametrów jest tu całkiem sporo, z każdym z nich będziemy sobie radzić stopniowo.
Port
Tutaj jest napisane, na którym porcie nasz serwer będzie nasłuchiwał. Domyślnie nasłuchuje 22 Port TCP/IP. Interesujący faktże możesz określić wiele portów. Na przykład:
Adres słuchania
Ograniczenie autoryzacji przez interfejs (Adres Odsłuchu)
Ogólny widok ustawienia można zapisać w następujący sposób:
Host nasłuchiwania adresu | Adres_IPv4 | Adres IPv6_addr ListenAddress :port
Wskazuje adres sieciowy na którym serwer będzie nasłuchiwał.
Jeśli serwer ma wiele interfejsów sieciowych, które są skonfigurowane do używania różnych IP adresy, wtedy możesz ograniczyć dostęp za pomocą tego parametru.
Na przykład na serwerze: 4
interfejsy sieciowe:
eth0 — 192.168.0.1 eth1 — 192.168.0.2 eth2 — 192.168.0.3 eth3 — 192.168.0.4
Domyślna szi- serwer w ogóle jest w stanie oczekiwania na połączenie IP adresy. Jeśli chcesz, aby użytkownicy mogli logować się tylko na interfejsach 2 I 3 , powinieneś to zrobić:
Adres nasłuchiwania 192.168.0.2 Adres nasłuchiwania 192.168.0.3
W tym miejscu możesz również określić port. Na przykład:
Adres nasłuchiwania 192.168.0.2:222
Jeśli port nie jest ustawiony, cisza posłuchaj tego adresu i
na porcie określonym w opcji Port. Jeśli użyjesz Adres słuchania bez określania portu, to opcja Port musi poprzedzać opcję Adres nasłuchiwania. Jeśli w ogóle nie określono Adres nasłuchiwania, wtedy domyślnie serwer nasłuchuje na wszystkich adresach lokalnych.
Adres rodziny
Określa, która rodzina IP adresy muszą być używane przez usługę cisza. Możliwe opcje:
"każdy"- każdy
„net”(tylko IPv4)
"inet6"(tylko IPv6)
Domyślna - "każdy".
Jeśli to możliwe, warto ograniczyć rodzinę przetwarzanych adresów do tych faktycznie używanych, tj. jeśli używasz tylko IPv4- wyłączyć IPv6, i wzajemnie.
Na przykład, aby zezwolić IPv4 i zakaz IPv6:
AdresRodzina inet
Protokół
cisza może pracować z protokołami SSH1 I SSH2. Jednak korzystanie z niebezpiecznych SSH1 wysoce nie zalecane. zmuszać cisza pracuj tylko z protokołem SSH2 jest to możliwe tak:
Protokół 2
ZezwolenieRootZaloguj
Możliwość autoryzacji w ramach superużytkownika
Domyślnie loguj się do zdalnego serwera jako użytkownik źródło nikt nie zabrania. Ale to nie jest całkowicie bezpieczne. Zamiast tego bardziej poprawne będzie logowanie pod użytkownikiem rachunek i podnieś swoje przywileje za pomocą polecenia „su-”, albo użyj „sudo”.
Jeśli w Twojej organizacji jest kilku administratorów systemu i wszyscy łączą się z serwerem z uprawnieniami superużytkownika, nie zawsze można dowiedzieć się, który z administratorów znajduje się na serwerze. Dlatego po wyłączeniu możliwości autoryzacji bezpośrednio pod użytkownikiem źródło, administratorzy systemu najpierw zalogują się na własne konto, a dopiero potem otrzymają uprawnienia superużytkownika; ułatwia to kontrolę serwera i czynności, które wykonują administratorzy.
Aby wyłączyć powyższą funkcję, wyłącz parametr ZezwolenieRootZaloguj ustawiając wartość "nie".
PermitRootZaloguj się nie
Zezwól na puste hasła
Blokowanie pustych haseł
Zezwól na pusteHasła nie
AllowUsers, AllowGroups
Domyślnie zalogować się może każdy użytkownik serwera. Lepiej ograniczyć krąg użytkowników, którzy mają dostęp do szsz.
Może to być przydatne, gdy tworzysz w systemie wielu użytkowników, ale zezwalasz na dostęp przez cisza tylko chcę trochę.
Aby to zrobić, w pliku konfiguracyjnym sshd_config powinien dodać określonych użytkowników istniejących na serwerze. W poniższym przykładzie są to użytkownicy Jan, Piotr I Michał, którzy mogą wejść na serwer. Nazwy użytkowników są oddzielone spacjami.
AllowUsers john peter michael
Podczas dodawania wszystkich użytkowników, którzy są obecni w określonej grupie, należy ich określić, jak pokazano w poniższym przykładzie. Grupy użytkowników, którzy mogą wejść na serwer, są również oddzielone spacją.
Administratorzy deweloperów AllowGroups
Odmów Użytkownikom, Odmów Grupom
W przeciwieństwie do zezwalania na dostęp określonym użytkownikom lub grupom, można również określić użytkowników lub grupy, którym odmówiono dostępu do serwera.
Aby to zrobić, dodaj do pliku konfiguracyjnego sshd_config parametr Odmów użytkownikom, w którym oddzielone spacją określają użytkowników, którym odmówiono dostępu do serwera. W poniższym przykładzie jest to system apacze, jak również bardzo realne Borys.
DenyUsers apache boris
Istnieje również ustawienie, za pomocą którego można odmówić dostępu nie poszczególnym użytkownikom, ale całym grupom obejmującym użytkowników. To jest parametr Odrzuć grupy a grupy są również oznaczone spacją.
Hakerzy marketingowi DenyGroups
Pamiętaj, że możesz używać kombinacji parametrów odrzuć i zezwól: Odmów użytkownikom, Zezwól Użytkownikom, Odrzuć grupy, I Zezwól na grupy.
ZalogujGraceTime
Podczas próby zalogowania się za pomocą cisza do serwera, który masz 2 minut na wprowadzenie nazwy użytkownika i hasła. Jeśli tego nie zrobisz, połączenie z serwerem zostanie przerwane. 2 minut oczekiwania na dane autoryzacyjne to całkiem sporo. powinien być ograniczony do 1 minuty lub nawet 30 sekundy.
Aby to zrobić, zmień parametr ZalogujGraceTime edytując plik sshd_config, i wprowadź tam wymagany czas. W poniższym przykładzie 1 minuta.
ZalogujGraceTime 1m
Interwał Życia Klienta
Rozłącz się, gdy w powłoce nie ma żadnej aktywności
Po pomyślnym zalogowaniu się na serwerze możesz chcieć umożliwić automatyczne zakończenie połączenia po upływie czasu, w którym nie wykonałeś żadnej akcji w konsoli. Jest to powszechnie określane jako czas bezczynności.
Za pomocą grzmotnąć, możesz to osiągnąć, zmieniając zmienną środowiskową TMOUT .
W OpenSSH osiąga się to poprzez kombinację parametrów ClientAliveCountMax I Interwał Życia Klienta w pliku konfiguracyjnym sshd_config.
- ClientAliveCountMax- wskazuje maksymalną liczbę check-żywy wysłane wiadomości szi- serwer, w ramach którego nie otrzymuje żadnej odpowiedzi od szi- klient. Wartość domyślna to 3.
- Interwał Życia Klienta- wskazuje limit czasu (limit czasu) w sekundach. Po określonym czasie szi- serwer wyśle check-żywy wiadomość do klienta, czekam na odpowiedź od niego (odpowiedź). Wartość domyślna to 0, oznacza to, że serwer nie wyśle wiadomości do weryfikacji.
W porządku dla twojego szi- klient jest automatycznie rozłączany po 10 minuty ( 600 sekund), musisz wprowadzić zmiany w pliku konfiguracyjnym sshd_config w następujący sposób:
ClientAliveInterval 600 ClientAliveCountMax 0
To wszystko na teraz. W zasadzie myślę, że to już wystarczy do dobrej konfiguracji i poprawy bezpieczeństwa. szsz. W następnej części przeanalizujemy jeszcze kilka parametrów. szi- serwer i może możemy mówić o uwierzytelnianiu opartym na kluczu.
Powodzenia wszystkim i do zobaczenia wkrótce na naszym blogu!
Do działania serwera ssh, jak i klienta ssh wykorzystamy znany pakiet OpenSSH
Instalacja
Zainstaluj OpenSSH za pomocą polecenia:
sudo apt zainstaluj ssh
Dostrajanie serwera
Podczas instalacji serwer SSH jest automatycznie dodawany do uruchamiania. Możesz sterować jego uruchomieniem, zatrzymaniem lub ponownym uruchomieniem za pomocą poleceń:
usługa sudo ssh stop|start|restart
Głównym plikiem konfiguracyjnym serwera SSH jest plik /etc/ssh/sshd_config, który może być odczytywany lub edytowany tylko przez administratora. Po każdej zmianie w tym pliku musisz zrestartować serwer ssh, aby zmiany odniosły skutek.
Przykład konfiguracji serwera SSH na Ubuntu 16.04:
# Jakie porty, adresy IP i protokoły nasłuchujemy na porcie 22 # „dowolny” - dowolny # # „inet” (tylko IPv4) # # „inet6” (tylko IPv6) # AddressFamily inet # Które interfejsy/sieci mają dostęp, jeśli # nie określaj, następnie nasłuchuje wszystkich adresów. #ListenAddress:: #ListenAddress 0.0.0.0 # Protokół, na którym będzie działać SSH (drugi zalecany) Protokół 2 # Określa plik zawierający klucz prywatny hosta dla protokołu w wersji 2 HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_dsa_key #HostKey /etc/ssh/ssh_host_ecdsa_key #HostKey /etc/ssh/ssh_host_ed25519_key #Separacja uprawnień włączona dla bezpieczeństwa UsePrivilegeSeparation yes # Długość życia i rozmiar bitu klucza dla protokołu w wersji 1 #KeyRegenerationInterval 3600 #ServerKeyBits 1024 ##AUTH #Logging # DAUTH USER # # # LOKALNY0 # # LOKALNY1 # # LOKALNY2 # # LOKALNY3 # # LOKALNY4 # # LOKALNY5 # # LOKALNY6 # # LOKALNY7 # SyslogFacility AUTH # SILENT # # CICHY # # KRYTYCZNY # # BŁĄD # # INFORMACJE # # GŁOŚNY # # DEBUGOWANIE # # DEBUGOWANIE1 ## DEBUG2 ## DEBUG3 # LogLevel INFO # Uwierzytelnianie: LoginGraceTime 45 # Zezwalaj na dostęp użytkownika root lub nie. # "tak" - superużytkownik może się zalogować. # Używany jest aktualny globalny schemat uwierzytelniania. # "bez hasła" - superużytkownik może się zalogować. # Uwierzytelnianie hasłem dla niego zostanie wyłączone. # „tylko polecenia wymuszone” - superużytkownik będzie mógł się zalogować # przy użyciu uwierzytelniania klucza publicznego i # tylko wtedy, gdy przekaże wymagane polecenie do wykonania. # Wszystkie inne metody uwierzytelniania dla superużytkownika zostaną wyłączone. # "nie" - superużytkownik nie może używać ssh do logowania. PermitRootLogin nie StrictModes tak # Wskazuje, czy dozwolone jest surowe uwierzytelnianie RSA. # Dotyczy tylko wersji protokołu 1. RSAAuthentication yes # Użyj uwierzytelniania klucza publicznego PubkeyAuthentication yes # Określa plik zawierający klucze publiczne # używane do uwierzytelniania użytkowników. #AuthorizedKeysFile %h/.ssh/authorized_keys # Wyłącza używanie plików .rhosts i .shosts # # w uwierzytelnianiu na hoście. IgnoreRhosts yes # Aby to zadziałało, potrzebne będą również klucze hosta w /etc/ssh_known_hosts RhostsRSAAuthentication no # to samo dla wersji protokołu 2 HostbasedAuthentication no # Określa, czy sshd powinien ignorować użytkownika # "znane hosty" ~/.ssh/known_hosts dla RhostsRSAAuthentication #IgnoreUserKnow yes # Włącza uwierzytelnianie pustym hasłem (NOT RECOMMENDED) PermitEmptyPasswords no # Określa, czy zezwolić na uwierzytelnianie typu wyzwanie-odpowiedź ChallengeResponseAuthentication no # Określa, czy uwierzytelnianie hasłem jest dozwolone PasswordAuthentication no # Opcje Kerberos # Określa, czy hasło podane przez użytkownika # # jest wymagane do uwierzytelniania # KerberosAuthentication no # Jeśli AFS jest włączony, a użytkownik otrzymał bilet TGT Kerberos 5, # czy należy próbować uzyskać token AFS, zanim użytkownik # uzyska dostęp do swojego folderu domowego. # Wartość domyślna to „nie”. #KerberosGetAFSToken no # Określa, co zrobić, jeśli uwierzytelnianie # za pomocą protokołu Kerberos nie powiedzie się. Jeśli # wartość = "yes" - hasło zostanie # zweryfikowane przy użyciu # dowolnego dodatkowego lokalnego mechanizmu autoryzacji, # na przykład - /etc/passwd. # Wartość domyślna to „tak”. #KerberosOrLocalPasswd yes # Określa, czy automatycznie niszczyć plik pamięci podręcznej biletów # użytkownika po zakończeniu sesji. # Wartość domyślna to „tak”. #KerberosTicketCleanup yes # Opcje GSSAPI # Wskazuje, czy uwierzytelnianie użytkownika oparte na GSSAPI jest # dozwolone. Wartość domyślna to "no" #GSSAPIAuthentication no # Określa, czy automatycznie niszczyć pamięć podręczną poświadczeń uwierzytelniania # użytkownika po # zakończeniu sesji. # Wartość domyślna to "yes" #GSSAPICleanupCredentials yes # Wskazuje, czy przekierowywanie podsystemu grafiki X11 jest # dozwolone. #X11Forwarding yes # Określa numer pierwszego wyświetlacza dostępnego dla sshd w # jako przekazywanie X11. #X11DisplayOffset 10 # Określa, czy sshd powinien wyświetlać informacje w /etc/motd #, gdy użytkownik loguje się interaktywnie. PrintMotd no # Określa, czy sshd ma drukować datę i godzinę ostatniej sesji # na ekranie, gdy użytkownik loguje się interaktywnie. # Wartość domyślna to „tak”. PrintLastLog yes # Wskazuje, czy system powinien wysyłać komunikaty TCP do klienta w celu # utrzymania połączenia. TCPKeepAlive yes # Określa liczbę wiadomości do klientów, # które sshd wysyła z rzędu bez otrzymywania odpowiedzi od klienta. Jeśli próg zostanie osiągnięty i # klient nadal nie odpowiada, sshd odłączy klienta, # kończąc sesję ssh. #ClientAliveCountMax # Ustawia interwał czasu w sekundach. Jeśli w tym czasie nie nawiązano komunikacji z klientem, # sshd # wysyła wiadomość przez zaszyfrowany kanał # żądając odpowiedzi od klienta. Wartość domyślna to 0, tj. # nie wysyłaj takich wiadomości. Ta dyrektywa działa # tylko dla protokołu ssh2. #ClientAliveInterval # Wskazuje, czy logowanie powinno być # używane w sesji interaktywnej. Wartość domyślna to „nie”. #UseLogin no # Określa maksymalną liczbę jednoczesnych # nieautoryzowanych połączeń z sshd. # Opcjonalnie można określić wczesny reset połączeń, # określając jako parametr trzy wartości oddzielone # dwukropkiem „start:rate:full” (na przykład: „3:30:30”). # sshd odrzuci próbę połączenia z prawdopodobieństwem # „rate/100” (tj. 30% w naszym przykładzie), jeśli # istnieją już „start” (3) nieautoryzowane połączenia. # Prawdopodobieństwo rośnie liniowo i wszelkie # próby połączenia zostaną odrzucone, jeśli liczba nieautoryzowanych połączeń osiągnie „pełną” (30). # MaxStartups 3:30:30 # Wskazuje, który plik zawiera baner tekstowy #, który zostanie wyświetlony użytkownikowi PRZED procedurą uwierzytelniania #. Ta opcja jest dostępna tylko dla protokołu ssh2. Banner /etc/issue.net # Zezwalaj klientowi na przekazywanie regionalnych zmiennych środowiskowych AcceptEnv LANG LC_* # Definiuje i konfiguruje podsystem zewnętrzny (np. # demon transferu plików). Podsystem sftp /usr/lib/openssh/sftp-server # Włącza interfejs PAM (interfejs Plugable Authentication Module #) Jeśli ustawione na "yes" - dla wszystkich typów uwierzytelniania # oprócz przetwarzania modułu sesji i konta # PAM użyje uwierzytelnianie na podstawie # request-response (ChallengeResponseAuthentication i # PasswordAuthentication) challenge-response # uwierzytelniania w PAM zwykle pełni tę samą rolę, co uwierzytelnianie hasłem, # należy wyłączyć # albo PasswordAuthentication albo # ChallengeResponseAuthentication. Warto zauważyć, że # jeśli dyrektywa UsePAM jest włączona, nie będziesz mógł # uruchomić sshd jako użytkownik inny niż root. # Wartość domyślna to „nie”. Użyj PAM tak
Możesz skopiować powyższy tekst do własnego sshd_config i użyć go później.
Źle skonfigurowany serwer SSH sam w sobie stanowi ogromną lukę w zabezpieczeniach systemu, ponieważ potencjalny atakujący ma możliwość uzyskania prawie nieograniczonego dostępu do systemu. Ponadto sshd posiada wiele dodatkowych przydatnych opcji, których włączenie jest pożądane, aby poprawić użyteczność i bezpieczeństwo).
Port, ListenAddress i AddressFamily
Te trzy opcje określają, na których portach i adresach serwer będzie nasłuchiwał połączeń przychodzących. Po pierwsze, sensowne jest, jeśli to możliwe, ograniczenie rodziny przetwarzanych adresów do faktycznie używanych, to znaczy, jeśli używasz tylko IPv4, wyłącz IPv6 i odwrotnie. Można to zrobić za pomocą parametru AddressFamily, na przykład (aby zezwolić na IPv4 i odmówić IPv6):
Po drugie, pożądana jest zmiana standardowego portu (22), na którym nasłuchuje sshd. Wynika to z faktu, że liczne skanery sieciowe nieustannie próbują połączyć się z 22. portem i przynajmniej uzyskać dostęp poprzez wyliczanie loginów/hasła ze swojej bazy danych. Nawet jeśli masz wyłączone uwierzytelnianie hasłem, te próby zapychają logi i (w dużych ilościach) mogą negatywnie wpłynąć na szybkość serwera ssh. Jeśli z jakiegoś powodu nie chcesz zmieniać standardowego portu, możesz użyć zarówno różnych zewnętrznych narzędzi do zwalczania brute-forcerów, takich jak fail2ban, jak i wbudowanych, takich jak MaxStartups.
Port można ustawić jako wartość bezwzględną dla wszystkich interfejsów za pomocą dyrektywy Port lub jako określoną wartość dla każdego interfejsu za pomocą dyrektywy ListenAddress.
Zakaz zdalny dostęp dla superużytkownika
Domyślnie dostęp roota jest odmawiany za pomocą hasła (kluczem - możesz) - opcja PermitRootLogin jest ustawiona na bez hasła4). Ale biorąc pod uwagę, że domyślnie w Ubuntu użytkownik dodany podczas instalacji systemu ma możliwość wykonywania wszystkich zadań administracyjnych za pomocą sudo, stworzenie możliwości rootowania dostępu do systemu przez ssh wygląda na nieuzasadnione (nawet przy uwierzytelnianiu klucza). Zaleca się, aby całkowicie go wyłączyć. tę opcję lub zastosuj ją tylko w trybie wymuszonych tylko poleceń.
Uwierzytelnianie hasłem
Domyślnie włączone uwierzytelnianie hasłem jest praktycznie najbardziej prymitywnym sposobem logowania do sshd. Z jednej strony upraszcza to konfigurację i podłączanie nowych użytkowników (wystarczy, że użytkownik zna swój login/hasło systemowe), z drugiej strony hasło zawsze można odgadnąć, a użytkownicy często zaniedbują tworzenie złożonych i długie hasła. Specjalne boty nieustannie skanują serwery ssh dostępne w Internecie i próbują się do nich zalogować, wyliczając loginy/hasła ze swojej bazy danych. Zdecydowanie zaleca się, aby nie używać uwierzytelniania hasłem.
Jeśli z jakiegoś powodu nadal chcesz korzystać z uwierzytelniania hasłem - upewnij się, że nikt nie może zalogować się pustym hasłem. Aby to zrobić, ustaw dyrektywę PermitEmptyPasswords no
Protokoły SSH1 i SSH2
Jak już wspomniano, sshd może współpracować z protokołami SSH1 i SSH2. Jednak korzystanie z niezabezpieczonego SSH1 jest wysoce odradzane. Wymuś działanie sshd tylko z protokołem SSH2
Uwierzytelnianie klucza RSA SSH2
Preferowaną metodą autoryzacji jest uwierzytelnianie kluczem SSH2 RSA. Dzięki tej metodzie użytkownik generuje po swojej stronie parę kluczy, z których jeden jest tajny, a drugi publiczny. Klucz publiczny jest kopiowany na serwer i służy do weryfikacji tożsamości użytkownika. Aby uzyskać więcej informacji na temat tworzenia pary kluczy i umieszczania ich na serwerze, zobacz opis klienta SSH.
Konfigurowanie klienta SSH
Logowanie za pomocą klucza jest uważane za najbezpieczniejsze iw większości przypadków ta funkcja jest włączona po stronie serwera, więc nie są wymagane żadne uprawnienia administratora, aby z niej korzystać. Wygeneruj klucz na komputerze klienckim:
ssh-keygen
Dostajemy propozycję podania hasła zabezpieczającego plik klucza (okazuje się to przydatne, jeśli plik wpadnie w niepowołane ręce). Przekazujemy klucz publiczny na serwer za pomocą polecenia
ssh-copy-id -i ~/.ssh/id_rsa.pub użytkownik_serwera@adres_serwera
Wszystko, możesz wejść.
Gdy ssh działa na niestandardowym porcie:
ssh-copy-id -i ~/.ssh/id_rsa.pub -p twój_port użytkownik_serwera@adres_serwera
Czasami istnieje potrzeba przejścia z jednego komputera na drugi, aby nie tylko przeglądać dane, ale także wykonywać pewne czynności. SSH jest idealny do takich zadań, zwłaszcza w Ubuntu. Pozwala na bezpieczne połączenie serwera i klienta, a jednocześnie instalacja i konfiguracja nie zajmie dużo czasu, jeśli będziesz postępować zgodnie z instrukcjami.
Jak zainstalować serwer w Ubuntu
Chodzi o to, że domyślnie system operacyjny Klient Ubuntu jest już zainstalowany. Dlatego najważniejsza jest instalacja programu Serwer OpenSSH na komputerze i jego późniejszej konfiguracji. Aby zainstalować serwer, otwórz terminal i wpisz wiersz: sudo apt-get install openssh-server. Ubuntu poprosi Cię o hasło - potwierdź je. Po zakończeniu instalacji pojawi się komunikat informujący o pomyślnej instalacji. W rezultacie zostanie zainstalowany serwer OpenSSH. Ten program jest w Dystrybucje Ubuntu domyślnie, ponieważ serwer OpenSSH jest bardzo popularny wśród użytkowników tego systemu operacyjnego.
Konfiguracja serwera ssh w ubuntu
Teraz najważniejszą rzeczą jest to, że musisz poprawnie skonfigurować serwer OpenSSH przed jego włączeniem i uruchomieniem klienta przez bezpieczny protokół na hoście. Nieprawidłowe ustawienie może prowadzić do obniżenia poziomu bezpieczeństwa, a serwer może zostać zhakowany.
A do tego potrzebny jest protokół SSH, aby połączenie i transfer danych odbywały się niezawodnymi, zaszyfrowanymi kanałami, więc lepiej poświęcić trochę czasu i ustalić ustawienia.
Sposób działania serwera jest opisany w konfiguracji pliku konfiguracyjnego. W szczególności określa wymagania, które klient musi spełnić, aby przejść przez ochronę SSH. Najpierw musisz zdecydować, przez którego użytkownika będziesz zarządzać systemem. Domyślnym użytkownikiem jest root. Ale pozostawienie tego ustawienia jako takiego nie jest bezpieczne - użytkownik root za dużo uprawnień i możesz przypadkowo uszkodzić system, więc lepiej wyłączyć jego połączenie z serwerem.
Musisz ponownie zainstalować inne konto użytkownika na serwerze, aby móc bezpiecznie korzystać z innego komputera przez SSH. Aby to zrobić, musisz dodać innego użytkownika zamiast roota za pomocą wiersz poleceń: adduser nazwa użytkownika. Ale to nie wystarczy - w końcu czasami będziesz potrzebować użytkownika root. Następnie ustaw dodanego użytkownika w połowie superadministratora, aby mógł tymczasowo odbierać prawa roota. Aby to zrobić, przejdź do roota i napisz następującą linię: gpasswd -a nazwa użytkownika sudo. W ten sposób dodasz nowego użytkownika do grupy użytkowników sudo, która ma najwyższy poziom dostępu.
Jeśli planujesz utworzyć serwer publiczny przy użyciu SSH i żaden klient nie pojawi się na komputerze, lepiej całkowicie usunąć użytkownika root. Jeśli masz pewność co do swoich umiejętności i nie planujesz publikować hosta, możesz uczynić klienta superadministratorem i zabezpieczyć go hasłem. Ale czasami po tym pojawia się komunikat o błędzie: odmowa dostępu. Odmowa dostępu do napisu po próbie zalogowania się na konto superużytkownika poprzez wpisanie hasła może oznaczać pewną sprzeczność w pliku konfiguracyjnym config.
Aby wyeliminować odmowę dostępu, należy dokładnie przyjrzeć się wszystkim w ustawieniach. Najbardziej popularny przypadek, powodem pojawienia się odmowy dostępu jest aktywacja opcji autoryzacji hasła zarówno dla zwykłych użytkowników, jak i roota. Aby usunąć odmowę dostępu, zmień PermitRootLogin z tak na bez hasła. A potem napisz PermitRootLogin tak. Następnie uruchom ponownie serwer (restart usługi ssh), a komunikat o odmowie dostępu w końcu zniknie.
Kolejnym ważnym krokiem jest włączenie silnego uwierzytelniania użytkownika. Autoryzacja poprzez wprowadzenie hasła jest już przestarzałym i nieefektywnym sposobem ochrony kont. Obecnie istnieje wiele programów, za pomocą których można łamać hasła, wybierając je. Dlatego lepiej jest korzystać z uwierzytelniania klucza publicznego. Oznacza to, że lepiej jest użyć uwierzytelniania klucza publicznego i umieścić tak obok tego elementu w konfiguracji.
Aby zalogować się do serwera poprzez weryfikację klucza publicznego, musisz go najpierw wygenerować. W Ubuntu bardzo wygodnie jest generować klucze, ponieważ nie trzeba ich pobierać dodatkowe programy- po prostu wpisz ssh-keygen w terminalu. Następnie pojawi się komunikat z informacją o lokalizacji wygenerowanego klucza. Będzie znajdować się w folderze .ssh. Następnie system poprosi Cię o hasło, ale zdecydowanie zaleca się pozostawienie go pustego - w przeciwnym razie będziesz wprowadzać je za każdym razem, gdy wykonujesz jakąkolwiek operację.
Następnym krokiem jest dodanie wygenerowanego klucza publicznego do listy zaufanych na serwerze. Najpierw musisz skopiować klucz publiczny. Znajduje się w pliku .pub w folderze .ssh. Skopiuj go i przejdź do serwera. Na serwerze musi również znajdować się folder .ssh. Jeśli nie istnieje, będziesz musiał sam go stworzyć. A potem używając standardu Edytor tekstu, utwórz plik autoryzowanych_kluczy. Tutaj będziesz musiał umieścić klucz publiczny. Po tym będziesz mógł wejść na serwer bez żadnego potwierdzenia. Uwierzytelnianie odbędzie się automatycznie, w tle, co jest jednocześnie bardzo wygodne i bezpieczne.
Ogólnie rzecz biorąc, na tym kończy się konfiguracja protokołu SSH! Chyba że możesz zmienić port 22 na inny.
