Skip to main content

Wszystko o poleceniu Linux / Unix: sshd

SSH, FTP, Ping, Telnet: Linux Networking Commands Tutorial 12 (Może 2024)

SSH, FTP, Ping, Telnet: Linux Networking Commands Tutorial 12 (Może 2024)
Anonim

Imię

sshd - Demon OpenSSH SSH

Streszczenie

sshd -deiqtD46 -b bity -fa plik_konfiguracyjny -sol login_grace_time -h host_key_file -k key_gen_time -o opcja -str Port -u len

Opis

sshd (Demon SSH) to program daemon dla ssh (1). Razem te programy zastępują rlogin i rshi zapewniają bezpieczną szyfrowaną komunikację między dwoma niezaufanymi hostami w niezabezpieczonej sieci. Programy mają być tak proste w instalacji i obsłudze, jak to tylko możliwe.

sshd jest demonem, który nasłuchuje połączeń od klientów. Zaczyna się normalnie przy starcie z / etc / rc Wyświetla nowego demona dla każdego połączenia przychodzącego. Rozproszone demony obsługują wymianę kluczy, szyfrowanie, uwierzytelnianie, wykonywanie poleceń i wymianę danych. Ta implementacjasshd jednocześnie obsługuje zarówno protokół SSH w wersji 1 i 2.

Protokół SSH w wersji 1

Każdy host ma klucz RSA specyficzny dla hosta (zwykle 1024 bity) używany do identyfikacji hosta. Dodatkowo, kiedy demon się uruchomi, generuje klucz RSA serwera (zwykle 768 bitów). Ten klucz jest zwykle regenerowany co godzinę, jeśli został użyty i nigdy nie jest przechowywany na dysku.

Za każdym razem, gdy klient łączy się z demonem, odpowiada za pomocą publicznych kluczy hosta i serwera. Klient porównuje klucz hosta RSA z własną bazą danych, aby sprawdzić, czy nie został zmieniony. Klient następnie generuje 256-bitową liczbę losową. Szyfruje on tę losową liczbę przy użyciu zarówno klucza hosta, jak i klucza serwera i wysyła zaszyfrowany numer do serwera. Obie strony następnie używają tej liczby losowej jako klucza sesji, który jest używany do szyfrowania wszystkich dalszych komunikacji w sesji. Reszta sesji jest szyfrowana przy użyciu tradycyjnego szyfru, obecnie Blowfish lub 3DES, z domyślnie używaną 3DES. Klient wybiera algorytm szyfrowania do użycia z tych oferowanych przez serwer.

Następnie serwer i klient wprowadzają okno dialogowe uwierzytelniania. Klient próbuje uwierzytelnić się przy użyciu uwierzytelniania .rhosts, uwierzytelniania .rhosts w połączeniu z uwierzytelnianiem hosta RSA, uwierzytelnianiem typu challenge-response RSA lub uwierzytelnianiem opartym na haśle.

Uwierzytelnianie Rhost jest zwykle wyłączone, ponieważ jest zasadniczo niezabezpieczone, ale w razie potrzeby można je włączyć w pliku konfiguracyjnym serwera. Bezpieczeństwo systemu nie ulegnie poprawie, chyba żershdrlogind i rexecd są wyłączone (w ten sposób całkowicie wyłączając rlogin i rsh w maszynie).

Protokół SSH w wersji 2

Wersja 2 działa podobnie: każdy host ma klucz specyficzny dla hosta (RSA lub DSA) używany do identyfikacji hosta. Jednak po uruchomieniu demona nie generuje klucza serwera. Zabezpieczenia forward są zapewniane przez umowę klucza Diffiego-Hellmana. Ta kluczowa umowa powoduje udostępnienie klucza sesji.

Reszta sesji jest szyfrowana przy użyciu symetrycznego szyfru, obecnie 128 bitowego AES, Blowfish, 3DES, CAST128, Arcfour, 192 bitowego AES lub 256 bitowego AES. Klient wybiera algorytm szyfrowania do użycia z tych oferowanych przez serwer. Ponadto integralność sesji jest zapewniana za pomocą kodu uwierzytelniania wiadomości kryptograficznych (hmac-sha1 lub hmac-md5).

Protokół wersja 2 udostępnia metodę uwierzytelniania opartą na kluczu publicznym (PubkeyAuthentication) lub hosta klienta (HostbasedAuthentication), konwencjonalne uwierzytelnianie haseł i metody oparte na odpowiedziach.

Wykonanie polecenia i przekazywanie danych

Jeśli klient pomyślnie uwierzytelni się, zostanie wyświetlone okno dialogowe do przygotowania sesji. W tym momencie klient może zażądać takich rzeczy jak przydzielanie pseudo-tty, przekazywanie połączeń X11, przekazywanie połączeń TCP / IP lub przekazywanie połączenia agenta uwierzytelniającego przez bezpieczny kanał.

Na koniec klient żąda powłoki lub wykonania polecenia. Boki następnie wchodzą w tryb sesji. W tym trybie każda ze stron może wysyłać dane w dowolnym czasie, a dane te są przekazywane do / z powłoki lub polecenia po stronie serwera, a terminal użytkownika po stronie klienta.

Gdy program użytkownika kończy działanie, a wszystkie przekierowane X11 i inne połączenia zostały zamknięte, serwer wysyła do klienta kod zakończenia polecenia i obie strony wychodzą.

sshd można skonfigurować za pomocą opcji wiersza poleceń lub pliku konfiguracyjnego. Opcje wiersza polecenia zastępują wartości określone w pliku konfiguracyjnym.

sshd ponownie odczytuje swój plik konfiguracyjny po otrzymaniu sygnału zawieszenia,SIGHUP wykonując swoją nazwę, która została uruchomiona jako, to jest / usr / sbin / sshd

Dostępne są następujące opcje:

-b bity

Określa liczbę bitów klucza serwera efemerycznego protokołu wersji 1 (domyślnie 768).

-re

Tryb debugowania. Serwer wysyła pełne wyniki debugowania do dziennika systemu i nie umieszcza się w tle. Serwer również nie zadziała i przetworzy tylko jedno połączenie. Ta opcja jest przeznaczona wyłącznie do debugowania serwera. Wiele opcji -d zwiększa poziom debugowania. Maksymalnie 3.

-mi

Po określeniu tej opcji,sshd wyśle ​​wynik do standardowego błędu zamiast logu systemowego.

-fa plik konfiguracyjny

Określa nazwę pliku konfiguracyjnego. Wartością domyślną jest / etc / ssh / sshd_configsshdodmawia uruchomienia, jeśli nie ma pliku konfiguracyjnego.

-sol login_grace_time

Daje czas oczekiwania na uwierzytelnienie klientów (domyślnie 120 sekund). Jeśli klient nie uwierzytelni użytkownika w ciągu tych wielu sekund, serwer rozłączy się i zakończy działanie.Wartość zero oznacza brak limitu.

-h host_key_file

Określa plik, z którego odczytany jest klucz hosta. Ta opcja musi być podana, jeślisshd nie jest uruchamiany jako root (normalne pliki kluczy hostów zwykle nie są odczytywane przez nikogo poza rootem). Domyślnie jest to / etc / ssh / ssh_host_key dla wersji protokołu 1 i / etc / ssh / ssh_host_rsa_key i / etc / ssh / ssh_host_dsa_key dla wersji 2. protokołu. Możliwe jest posiadanie wielu plików kluczy hosta dla różnych wersji protokołów i klucza hosta algorytmy.

-ja

Określa tosshd jest uruchamiany z inetd.sshd zwykle nie jest uruchamiany z inetd, ponieważ musi wygenerować klucz serwera, zanim będzie mógł odpowiedzieć klientowi, a to może zająć kilkadziesiąt sekund. Klienci musieliby czekać zbyt długo, gdyby klucz był regenerowany za każdym razem. Jednak przy małych rozmiarach kluczy (np. 512) przy użyciusshd z inetd może być wykonalne.

-k key_gen_time

Określa, jak często regenerowany jest klucz serwera efemerycznej wersji protokołu 1 (domyślnie 3600 sekund lub godzina). Motywacją do regeneracji klucza dość często jest to, że klucz nie jest przechowywany w dowolnym miejscu, a po około godzinie niemożliwe staje się odzyskanie klucza do odszyfrowania przechwyconej komunikacji, nawet jeśli maszyna jest pęknięta lub fizycznie zajęta. Wartość zero wskazuje, że klucz nigdy nie zostanie zregenerowany.

-o opcja

Może być użyty do podania opcji w formacie używanym w pliku konfiguracyjnym. Jest to przydatne do określania opcji, dla których nie ma osobnej flagi wiersza polecenia.

-p Port

Określa port, na którym serwer nasłuchuje połączeń (domyślnie 22). Dozwolone są opcje wielu portów. Porty określone w pliku konfiguracyjnym są ignorowane po określeniu portu wiersza polecenia.

-q

Tryb cichy. Nic nie jest wysyłane do logu systemowego. Zwykle rejestrowane są początek, uwierzytelnianie i zakończenie każdego połączenia.

-t

Tryb testowania. Sprawdzaj tylko poprawność pliku konfiguracyjnego i poprawność kluczy. Jest to przydatne do aktualizacjisshd niezawodnie, ponieważ opcje konfiguracji mogą się zmienić.

-u len

Ta opcja służy do określenia rozmiaru pola wutmp struktura przechowująca nazwę zdalnego hosta. Jeśli rozwiązana nazwa hosta jest dłuższa niż len zamiast tego zostanie użyta kropkowana wartość dziesiętna. Dzięki temu hosty o bardzo długich nazwach hosta, które przepełniają to pole, nadal mogą być jednoznacznie identyfikowane. Określanie -u0 wskazuje, że tylko ułamkowe adresy dziesiętne powinny być umieszczane w pliku utmp. -u0 jest również używany do zapobieganiasshd od wysyłania żądań DNS, chyba że wymaga tego mechanizm uwierzytelniania lub konfiguracja. Mechanizmy uwierzytelniania, które mogą wymagać usługi DNS, obejmująRhostsAuthenticationRhostsRSAAuthentication HostbasedAuthentication i używanie afrom = lista-wzorówopcja w pliku klucza. Opcje konfiguracji wymagające DNS obejmują użycie parametru USER @ HOSTpattern wAllowUsers lubDenyUsers

-RE

Po określeniu tej opcjisshd nie odłączy się i nie stanie się demonem. Pozwala to na łatwe monitorowaniesshd

-4

Siłysshd używać tylko adresów IPv4.

-6

Siłysshd używać tylko adresów IPv6.

Plik konfiguracyjny

sshd odczytuje dane konfiguracyjne z / etc / ssh / sshd_config (lub pliku określonego za pomocą -fa w wierszu poleceń). Format pliku i opcje konfiguracji opisano w sshd_config5.

Proces logowania

Gdy użytkownik loguje się,sshd wykonuje następujące czynności:

  1. Jeśli login znajduje się na tty, a nie podano żadnej komendy, wyświetla ostatni czas logowania i / etc / motd (chyba że jest to uniemożliwione w pliku konfiguracyjnym lub przez $ HOME / .hushlogin patrz sekcja Sx FILES).
  2. Jeśli login jest na tty, zapisuje czas logowania.
  3. Sprawdza / etc / nologin, jeśli istnieje, drukuje zawartość i kończy działanie (chyba że root).
  4. Zmiany uruchamiane przy normalnych uprawnieniach użytkownika.
  5. Konfiguruje podstawowe środowisko.
  6. Czyta $ HOME / .ssh / environment, jeśli istnieje i użytkownicy mogą zmieniać swoje środowisko. ZobaczPermitUserEnvironment opcja w sshd_config5.
  7. Zmienia katalog domowy użytkownika.
  8. Jeśli istnieje $ HOME / .ssh / rc, uruchamia je; jeśli jeszcze istnieje / etc / ssh / sshrc, uruchamia go; w przeciwnym razie uruchamia xauth. Pliki `` rc 'są opatrzone standardowym protokołem uwierzytelniania X11 i plikiem cookie.
  9. Uruchamia powłokę lub polecenie użytkownika.

Authorized_Keys File Format

$ HOME / .ssh / authorized_keys to domyślny plik zawierający listę kluczy publicznych, które są dozwolone dla uwierzytelniania RSA w wersji protokołu 1 i dla uwierzytelniania klucza publicznego (PubkeyAuthentication) w wersji protokołu 2.AuthorizedKeysFile może być użyty do określenia alternatywnego pliku.

Każda linia pliku zawiera jeden klucz (puste linie i linie zaczynające się od `# 'są ignorowane jako komentarze). Każdy klucz publiczny RSA składa się z następujących pól, oddzielonych spacjami: opcje, bity, wykładnik, moduł, komentarz. Każdy klucz publiczny w wersji 2 protokołu składa się z: opcji, klucza, klucza zakodowanego w base64, komentarza. Pole opcji jest opcjonalne; jego obecność zależy od tego, czy linia zaczyna się od liczby, czy nie (pole opcji nigdy nie zaczyna się od cyfry). Bity, wykładnik, moduł i pola komentarza dają klucz RSA dla wersji protokołu 1; pole komentarza nie jest używane do niczego (ale może być wygodne dla użytkownika do zidentyfikowania klucza). Dla wersji protokołu 2 typ klucza to `` ssh-dss '' lub `` ssh-rsa ''

Zwróć uwagę, że wiersze w tym pliku mają zwykle długość kilkuset bajtów (ze względu na rozmiar kodowania klucza publicznego). Nie chcesz ich wpisywać; zamiast tego skopiuj plik identity.pub id_dsa.pub lub id_rsa.pub i edytuj go.

sshd wymusza minimalny rozmiar modułu klucza RSA dla kluczy protokołu 1 i protokołu 2 z 768 bitów.

Opcje (jeśli są obecne) zawierają specyfikacje opcji oddzielonych przecinkami. Żadne spacje nie są dozwolone, z wyjątkiem podwójnych cudzysłowów. Obsługiwane są następujące specyfikacje opcji (zwróć uwagę, że w słowach kluczowych opcji rozróżniana jest wielkość liter):

from = lista-wzorów

Określa, że ​​oprócz uwierzytelniania za pomocą klucza publicznego, nazwa kanoniczna zdalnego hosta musi znajdować się na liście wzorców rozdzielonych przecinkami ("*" i "?" Służą jako symbole wieloznaczne). Lista może również zawierać wzory negowane przez prefiksowanie ich za pomocą `! ' ; jeśli kanoniczna nazwa hosta odpowiada negowanemu wzorowi, klucz nie jest akceptowany. Celem tej opcji jest opcjonalnie zwiększenie bezpieczeństwa: uwierzytelnianie klucza publicznego samo w sobie nie ufa sieci ani serwerom nazw ani nic takiego (ale klucz); Jeśli jednak ktoś w jakiś sposób ukradnie klucz, klucz umożliwia intruzowi zalogowanie się z dowolnego miejsca na świecie. Ta dodatkowa opcja sprawia, że ​​używanie skradzionego klucza jest trudniejsze (serwery nazw i / lub routery musiałyby zostać naruszone oprócz samego klucza).

command = command

Określa, że ​​polecenie jest wykonywane, gdy ten klucz jest używany do uwierzytelniania. Polecenie dostarczone przez użytkownika (jeśli jest) jest ignorowane. Komenda uruchamiana jest na pty, jeśli klient zażąda pty; w przeciwnym razie jest uruchamiany bez tty. Jeśli wymagany jest 8-bitowy, czysty kanał, nie należy żądać pty lub należy go określićno-pty Cytat można dołączyć do polecenia, cytując go za pomocą odwrotnego ukośnika. Ta opcja może być przydatna do ograniczenia pewnych kluczy publicznych do wykonania tylko określonej operacji. Przykładem może być klucz, który pozwala na zdalne tworzenie kopii zapasowych, ale nic więcej. Należy zauważyć, że klient może określić przekazywanie TCP / IP i / lub X11, chyba że są one wyraźnie zabronione. Zauważ, że ta opcja dotyczy wykonywania powłoki, polecenia lub podsystemu.

environment = NAME = wartość

Określa, że ​​ciąg ma zostać dodany do środowiska podczas logowania przy użyciu tego klucza. Zmienne środowiska ustawione w ten sposób zastępują inne domyślne wartości środowiska. Dozwolonych jest wiele opcji tego typu. Przetwarzanie środowiska jest domyślnie wyłączone i jest kontrolowane przezPermitUserEnvironment opcja. Ta opcja jest automatycznie wyłączona, jeśliUseLogin jest włączony.

no-port-forwarding

Zabrania przekierowania TCP / IP, gdy ten klucz jest używany do uwierzytelniania. Wszelkie żądania przekazywania portów przez klienta zwrócą błąd. Może to być użyte, na przykład, w połączeniu zdowództwo opcja.

no-X11-forwarding

Zabrania przekierowania X11, gdy ten klucz jest używany do uwierzytelniania. Wszelkie żądania forwardowania X11 przez klienta zwrócą błąd.

no-agent-forwarding

Zabrania przekierowania agenta uwierzytelniającego, gdy ten klucz jest używany do uwierzytelniania.

no-pty

Zapobiega alokacji tty (niepowodzenie żądania alokacji pty).

permitopen = host: port

Ogranicz lokalne`` ssh -L '' przekierowanie portów tak, że może łączyć się tylko z określonym hostem i portem. Adresy IPv6 można określić za pomocą alternatywnej składni: host / port Wielokrotność allowopen opcje mogą być stosowane oddzielone przecinkami. Na określonych nazwach hostów nie jest wykonywane dopasowanie do wzorca, muszą to być dosłowne domeny lub adresy.

Przykłady

1024 33 12121 … 312314325 [email protected]

from = "*. niksula.hut.fi,! pc.niksula.hut.fi" 1024 35 23 … 2334 ylo @ niksula

command = "dump / home", no-pty, no-port-forwarding 1024 33 23 … 2323 backup.hut.fi

permitopen = "10.2.1.55:80", permitopen = "10.2.1.56:25" 1024 33 23 … 2323

Ssh_Known_Hosts Format pliku

Pliki / etc / ssh / ssh_known_hosts i $ HOME / .ssh / known_hosts zawierają klucze publiczne hosta dla wszystkich znanych hostów. Plik globalny powinien być przygotowany przez administratora (opcjonalnie), a plik dla użytkownika jest utrzymywany automatycznie: za każdym razem, gdy użytkownik łączy się z nieznanym hostem, jego klucz jest dodawany do pliku użytkownika.

Każda linia w tych plikach zawiera następujące pola: nazwy hostów, bity, wykładnik, moduł, komentarz. Pola są oddzielone spacjami.

Nazwy hostów to rozdzielone przecinkami listy wzorców ("*" i "?" Działają jak symbole wieloznaczne); każdy wzorzec jest z kolei porównywany z kanoniczną nazwą hosta (podczas uwierzytelniania klienta) lub z nazwą podaną przez użytkownika (podczas uwierzytelniania serwera). Wzór może być również poprzedzony znakiem `! ' wskazanie negacji: jeśli nazwa hosta pasuje do negowanego wzorca, nie jest akceptowana (przez tę linię), nawet jeśli pasuje do innego wzoru na linii.

Bity, wykładnik i moduł są pobierane bezpośrednio z klucza hosta RSA; można je uzyskać np. z /etc/ssh/ssh_host_key.pub Opcjonalne pole komentarza kontynuuje koniec linii i nie jest używane.

Wiersze rozpoczynające się od `# 'i puste wiersze są ignorowane jako komentarze.

Podczas wykonywania uwierzytelniania hosta uwierzytelnianie jest akceptowane, jeśli jakakolwiek pasująca linia ma odpowiedni klucz. Jest zatem dopuszczalne (ale nie zalecane) posiadanie kilku linii lub różnych kluczy hosta dla tych samych nazw. To nieuchronnie nastąpi, gdy do pliku zostaną wstawione krótkie formy nazw hostów z różnych domen. Możliwe, że pliki zawierają sprzeczne informacje; uwierzytelnienie jest akceptowane, jeśli z jednego pliku można znaleźć prawidłowe informacje.

Zwróć uwagę, że wiersze w tych plikach mają zwykle setki znaków i na pewno nie chcesz wpisywać kluczy hostów ręcznie. Zamiast tego generuj je za pomocą skryptu lub pobierając /etc/ssh/ssh_host_key.pub i dodając nazwy hostów z przodu.

Przykłady

closenet, …, 130.233.208.41 1024 37 159 … 93 closenet.hut.fi cvs.openbsd.org, 199.185.137.3 ssh-rsa AAAA1234 ….. =

Zobacz też

scp (1), sftp (1), ssh (1), ssh-add1, ssh-agent1, ssh-keygen1, login.conf5, moduli (5), sshd_config5, sftp-server8

T. Ylonen T. Kivinen M. Saarinen T. Rinne S. Lehtinen "Architektura protokołu SSH" draft-ietf-secsh-architecture-12.txt Styczeń 2002 materiał do wykonania w toku

M. Friedl N. Provos W. A. ​​Simpson "Wymiana grup Diffie-Hellmana dla protokołu SSH Transport Layer Protocol" draft-ietf-secsh-dh-group-exchange-02.txt Styczeń 2002 materiał do wykonania w toku

Ważny: Użyj mężczyzna dowództwo ( % mężczyzna ), aby zobaczyć, jak polecenie jest używane na danym komputerze.