Scroll to navigation

SSH(1) General Commands Manual SSH(1)

NAZWA

ssh — klient zdalnego logowania OpenSSH

SKŁADNIA

ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B interfejs-przypisania] [-b adres-przypisania] [-c określenie-szyfru] [-D [adres-przypisania:]port] [-E plik-dziennika] [-e znak-specjalny] [-F plik-konfiguracyjny] [-I pkcs11] [-i plik-tożsamości] [-J położenie-docelowe] [-L adres] [-l nazwa-logowania] [-m określenie-mac] [-O polecenie-npz] [-o opcja] [-P znacznik] [-p port] [-R adres] [-S ścieżka-npz] [-W stacja:port] [-w lokalny-tun[:zdalny-tun]] położenie-docelowe [polecenie [argument ...]] ssh [-Q opcja-odpytania]

OPIS

ssh (klient SSH) jest programem służącym do logowania się na zdalnym komputerze i do wykonywania poleceń na zdalnym komputerze. Został zaprojektowany, aby zapewnić bezpieczną, szyfrowaną komunikację pomiędzy dwiema niezaufanymi stacjami, poprzez niezabezpieczoną sieć. Bezpiecznym kanałem można przekierowywać również połączenia X11, wybrane porty TCP i gniazda domeny Uniksa.

ssh łączy się i loguje do podanego położenia-docelowego, które można podać określić jako [użytkownik@]nazwa-stacji lub jako URI w postaci ssh://[użytkownik@]nazwa-stacji[:port]. Użytkownik musi potwierdzić swoją tożsamość wobec zdalnego komputera jedną z wielu metod.

Jeśli poda się polecenie, zostanie ono wykonane na zdalnym komputerze zamiast powłoki logowania. Jako polecenie można podać pełen wiersz polecenia lub może ono zawierać dodatkowe argumenty. Jeśli się je przekaże, argumenty zostaną dołączone do polecenia, rozdzielone spacjami, przed wysłaniem ich do wykonania przez serwer.

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

Wymusza na ssh używanie tylko adresów IPv4.

Wymusza na ssh używanie tylko adresów IPv6.

Włącza przekierowywanie połączeń z agenta uwierzytelniania, takiego jak ssh-agent(1). Można je określić również w zależności od stacji, w pliku konfiguracyjnym.

Przekierowywania agenta należy włączać ostrożnie. Użytkownicy z możliwością pominięcia uprawnień plików na stacji zdalnej (dla gniazd agenta z domeny Uniksa) mogą uzyskać dostęp do lokalnego agenta za pomocą przekierowanego połączenia. Atakujący nie może uzyskać danych klucza z agenta, ale może przeprowadzić operacje na kluczach, które pozwolą mu się uwierzytelnić korzystając z tożsamości załadowanej do agenta. Bezpieczniejszą alternatywą może być skorzystanie z serwera pośredniczącego (zob. -J).

Wyłącza przekierowywanie połączeń z agenta uwierzytelniania.

interfejs-przypisania
Przypisuje do adresu interfejsu-przypisania przed podjęciem próby połączenia ze zdalnym komputerem. Przydatne tylko w systemach o kilku adresach.

adres-przypisania
Używa adresu-przypisania na lokalnym komputerze jako adresu źródłowego połączenia. Przydatne tylko w systemach o kilku adresach.

Żąda kompresji wszystkich danych (w tym standardowych: wejścia, wyjścia i wyjścia błędów oraz danych w przekierowanych połączeniach domeny Uniksa, TCP i X11). Używa tego samego algorytmu kompresji z gzip(1). Kompresja jest pożądana przy liniach modemowych i innych wolnych połączeniach, ale jedynie spowolni działanie w szybkich sieciach. Domyślną wartość można ustawić według stacji w plikach konfiguracyjnych, zob. opcję Compression w ssh_config(5).

określenie-szyfru
Wybiera szyfr używany do zabezpieczenia sesji. określenie-szyfru jest listą szyfrów, w kolejności według preferencji, z przecinkiem jako separatorem. Zob. słowo kluczowe Ciphers w ssh_config(5), aby dowiedzieć się więcej.

[adres-przypisania:]port
Określa lokalne „dynamiczne” przekierowanie portów na poziomie aplikacji. Działa to na zasadzie przydzielenia gniazda do nasłuchu na porcie po stronie lokalnej, opcjonalnie przypisanego do określonego adresu-przypisania. Gdy do tego portu tworzone jest połączenie, jest ono przekierowywane bezpiecznym kanałem, a do określenia gdzie należy połączyć się z komputera zdalnego służy protokół aplikacji. Obecnie obsługiwane są protokoły SOCKS4 i SOCKS5, a ssh będzie działał jako serwer SOCKS. Jedynie root może przekierowywać uprzywilejowane porty. Dynamiczne przekierowanie portów można wskazać również w pliku konfiguracyjnym.

Adresy IPv6 można podać ujmując je w nawiasy kwadratowe. Jedynie root może przekierowywać uprzywilejowane porty. Domyślnie, lokalny port jest przypisywany zgodnie z ustawieniem GatewayPorts. Można jednak podać adres-przypisania, aby przypisać połączenie do określonego adresu. Adres-przypisania z wartością „localhost” oznacza, że port nasłuchu jest przypisany wyłącznie do użytku lokalnego, a pusty adres lub „*” wskazuje, że port ma być dostępny ze wszystkich interfejsów.

plik-dziennika
Dopisuje dzienniki debugowania do pliku-dziennika, zamiast na standardowe wyjście błędów.

znak-specjalny
Ustawia znak specjalny do sesji z pty (domyślnie: „~”). Znak specjalny jest rozpoznawany tylko na początku wiersza. Znak specjalny, po którym nastąpi: kropka „.” – zamyka połączenie, control-Z – zawiesza połączenie, kolejny znak specjalny – wysyła pojedynczy znak specjalny. Ustawienie tego znaku na „none” wyłącza znaki specjalne i czyni sesję w pełni transparentną.

plik-konfiguracyjny
Określa alternatywny plik konfiguracyjny użytkownika. Jeśli poda się plik konfiguracyjny w wierszu polecenia, systemowy plik konfiguracyjny (/etc/ssh/ssh_config) zostanie zignorowany. Domyślnym plikiem konfiguracyjnym użytkownika jest ~/.ssh/config. Argument „none” wyłączy odczyt wszelkich plików konfiguracyjnych.

Żąda przejścia ssh w tło, zaraz przed wykonaniem polecenia. Przydatne, gdy ssh będzie pytał o hasła lub frazy kodujące, lecz użytkownik chce dokonać tego w tle. Wymusza -n. Zalecanym sposobem uruchamiania programów X11 po stronie zdalnej jest coś w stylu ssh -f stacja xterm.

Jeśli opcja konfiguracyjna ExitOnForwardFailure zostanie ustawiona na „yes”, to klient uruchomiony z opcją -f poczeka na poprawne zestawienie wszelkich zdalnych przekierowań portów, przed przejściem w tło. Szczegóły wskazano w opisie ForkAfterAuthentication w podręczniku ssh_config(5).

Powoduje, że ssh wypisze swoją konfigurację po przeanalizowaniu bloków Host oraz Match, a potem wyjdzie.

Zezwala zdalnym stacjom na połączenie do przekierowanych portów lokalnych. Przy korzystaniu z połączenia zwielokrotnionego, opcja ta musi być podana procesowi nadrzędnemu.

pkcs11
Określa bibliotekę współdzieloną PKCS#11, którą ssh powinien używać do komunikacji z tokenem PKCS#11, zapewniającym klucze do uwierzytelnienia użytkownika.

plik-tożsamości
Wybiera plik, z którego odczytywana jest tożsamość (klucz prywatny) dla klucza publicznego w celu uwierzytelniania. Można również podać plik klucza publicznego, w celu użycia powiązanego klucza prywatnego załadowanego za pomocą ssh-agent(1) w sytuacji, gdy plik klucza prywatnego nie jest dostępny lokalnie. Wartość domyślna obejmuje: ~/.ssh/id_rsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519 i ~/.ssh/id_ed25519_sk. Pliki tożsamości można również określić wobec konkretnej stacji w pliku konfiguracyjnym. Można podać opcję -i wielokrotnie (i określić wiele tożsamości w plikach konfiguracyjnych). Jeśli nie podano jawnie certyfikatu dyrektywą CertificateFile, ssh spróbuje także załadować informacje o certyfikacie, z pliku o nazwie powstałej przez dołączenie cząstki -cert.pub, do nazwy pliku tożsamości.

położenie-docelowe
Łączy się ze stacją docelową, tworząc wcześniej połączenie ssh ze stacją pośredniczącą opisaną w argumencie położenie-docelowe, a następnie tworząc przekierowanie TCP do końcowego położenia ze stacji pośredniczącej. Można podać wiele stacji pośredniczących, rozdzielając je przecinkiem. Adresy IPv6 można podać, ujmując je w nawiasy kwadratowe. Jest to skrót wobec dyrektywy konfiguracyjnej ProxyJump. Proszę zauważyć, że dyrektywy konfiguracyjne podawane w wierszu polecenia generalnie stosują się tylko do końcowej stacji, a nie do stacji pośredniczących. Plik ~/.ssh/config pozwoli określić konfigurację dla stacji pośredniczących.

Włącza uwierzytelnianie w oparciu o GSSAPI oraz przekierowanie (delegację) poświadczeń GSSAPI na serwer.

Wyłącza przekierowanie (delegację) poświadczeń GSSAPI na serwer.

[adres-powiązania:]port:stacja:port-stacji
 
[adres-powiązania:]port:zdalne-gniazdo
 
lokalne-gniazdo:stacja:port-stacji
 
lokalne-gniazdo:zdalne-gniazdo
Określa, że połączenia do danego portu TCP lub gniazda Uniksa na lokalnej stacji (kliencie) mają być przekierowywane do podanej stacji i portu, lub gniazda Uniksa, na zdalnej stacji. Działa to przez przydzielenie gniazda do nasłuchu albo na porcie TCP po stronie lokalnej, opcjonalnie powiązanego z podanym adres-powiązania, lub na gnieździe Uniksa. Gdy tylko nawiązywane jest połączenie z lokalnym portem lub gniazdem, połączenie jest przekierowywane poprzez bezpieczny kanał do portu port-stacji na stacji albo do gniazda Uniksa zdalne-gniazdo na stacji zdalnej.

Przekierowania portu można określić również w pliku konfiguracyjnym. Tylko superużytkownik może przekierowywać uprzywilejowane porty. Adresy IPv6 można podać, ujmując je w nawiasy kwadratowe.

Domyślnie, porty lokalne są przypisywane zgodnie z ustawieniem GatewayPorts. Jednak można podać adres-przypisania aby przypisać połączenie do określonego adresu. Adres-przypisania z wartością „localhost” oznacza, że port nasłuchu jest przypisany wyłącznie do użytku lokalnego, a pusty adres lub „*” wskazuje, że port ma być dostępny ze wszystkich interfejsów.

nazwa-logowania
Określa użytkownika, jako który ma nastąpić zalogowanie na zdalnym komputerze. Można go również określić w zależności od stacji, w pliku konfiguracyjnym.

Umieszcza klienta ssh w trybie „nadrzędnym” przy dzieleniu połączenia. Wielokrotna opcja -M umieszcza ssh w trybie „nadrzędnym”, jednak wymagane jest potwierdzenie za pomocą ssh-askpass(1), przed każdą operacją zmieniającą stan zwielokrotnienia (np. otwarcie nowej sesji). Więcej szczegółów w opisie ControlMaster w podręczniku ssh_config(5).

określenie-mac
Lista algorytmów MAC (ang. message authentication code - kod uwierzytelnienia wiadomości), podanych w preferowanej kolejności, używająca przecinka jako separatora. Więcej informacji w opisie słowa kluczowego MACs w podręczniku ssh_config(5).

Nie wykonuje zdalnego polecenia. Przydatne, jeśli oczekiwane jest jedynie przekierowanie portów. Więcej informacji w opisie SessionType w podręczniku ssh_config(5).

Przekierowuje standardowe wejście z /dev/null (czyli zapobiega odczytowi ze standardowego wejścia). Konieczne, gdy ssh ma działać w tle. Popularną sztuczką jest korzystanie z tej opcji w celu uruchamiania programów X11 na zdalnym komputerze. Na przykład ssh -n shadows.cs.hut.fi emacs & uruchomi program emacs na shadows.cs.hut.fi, a połączenie X11 zostanie automatycznie przekierowane bezpiecznym kanałem. Program ssh zostanie umieszczony w tle (nie zadziała to, gdy ssh musi zapytać o hasło lub frazę kodującą, zob. też opcję -f). Więcej szczegółów w opisie StdinNull w podręczniku ssh_config(5).

polecenie-npz
Steruje nadrzędnym procesem zwielokrotniania aktywnego połączenia. Gdy poda się opcję -O, argument ctl_cmd jest interpretowany i przekazywany procesowi nadrzędnemu. Prawidłowe polecenia to: „check” (sprawdza, czy proces nadrzędny działa), „forward” (żąda przekierowania bez wykonywania polecenia), „cancel” (odwołuje przekierowania), „proxy” (łączy się z nadrzędnym procesem zwielokrotniania w trybie pośredniczenia), „exit” (żąda wyjścia procesu nadrzędnego) oraz „stop” (żąda zatrzymywania przyjmowania kolejnych żądań zwielokrotniania przez proces nadrzędny).

opcja
Może posłużyć do przekazania opcji w formacie używanym w pliku konfiguracyjnym. Przydatne, gdy brak dla nich oddzielnych opcji wiersza poleceń. Pełny opis poniższych opcji i ich dopuszczalnych wartości podano w podręczniku ssh_config(5).

AddKeysToAgent
 
AddressFamily
 
BatchMode
 
BindAddress
 
BindInterface
 
CASignatureAlgorithms
 
CanonicalDomains
 
CanonicalizeFallbackLocal
 
CanonicalizeHostname
 
CanonicalizeMaxDots
 
CanonicalizePermittedCNAMEs
 
CertificateFile
 
ChannelTimeout
 
CheckHostIP
 
Ciphers
 
ClearAllForwardings
 
Compression
 
ConnectTimeout
 
ConnectionAttempts
 
ControlMaster
 
ControlPath
 
ControlPersist
 
DynamicForward
 
EnableEscapeCommandline
 
EnableSSHKeysign
 
EscapeChar
 
ExitOnForwardFailure
 
FingerprintHash
 
ForkAfterAuthentication
 
ForwardAgent
 
ForwardX11
 
ForwardX11Timeout
 
ForwardX11Trusted
 
GSSAPIAuthentication
 
GSSAPIKeyExchange
 
GSSAPIClientIdentity
 
GSSAPIDelegateCredentials
 
GSSAPIKexAlgorithms
 
GSSAPIRenewalForcesRekey
 
GSSAPIServerIdentity
 
GSSAPITrustDns
 
GatewayPorts
 
GlobalKnownHostsFile
 
HashKnownHosts
 
Host
 
HostKeyAlgorithms
 
HostKeyAlias
 
HostbasedAcceptedAlgorithms
 
HostbasedAuthentication
 
Hostname
 
IPQoS
 
IdentitiesOnly
 
IdentityAgent
 
IdentityFile
 
IgnoreUnknown
 
Include
 
KbdInteractiveAuthentication
 
KbdInteractiveDevices
 
KexAlgorithms
 
KnownHostsCommand
 
LocalCommand
 
LocalForward
 
LogLevel
 
LogVerbose
 
MACs
 
NoHostAuthenticationForLocalhost
 
NumberOfPasswordPrompts
 
ObscureKeystrokeTiming
 
PKCS11Provider
 
PasswordAuthentication
 
PermitLocalCommand
 
PermitRemoteOpen
 
Port
 
PreferredAuthentications
 
ProxyCommand
 
ProxyJump
 
ProxyUseFdpass
 
PubkeyAcceptedAlgorithms
 
PubkeyAuthentication
 
RekeyLimit
 
RemoteCommand
 
RemoteForward
 
RequestTTY
 
RequiredRSASize
 
RevokedHostKeys
 
SecurityKeyProvider
 
SendEnv
 
ServerAliveCountMax
 
ServerAliveInterval
 
SessionType
 
SetEnv
 
StdinNull
 
StreamLocalBindMask
 
StreamLocalBindUnlink
 
StrictHostKeyChecking
 
SyslogFacility
 
TCPKeepAlive
 
Tag
 
Tunnel
 
TunnelDevice
 
UpdateHostKeys
 
User
 
UserKnownHostsFile
 
VerifyHostKeyDNS
 
VisualHostKey
 
XAuthLocation
 

znacznik
Podaje znacznik, który może posłużyć do wyboru określonej konfiguracji z pliku ssh_config(5). Więcej informacji w opisie słów kluczowych Tag i Match w podręczniku ssh_config(5).
port
Port, do którego ma nastąpić połączenie na zdalnej stacji. Można go również określić w zależności od stacji, w pliku konfiguracyjnym.

opcja-odpytania
Odpytuje o algorytmy obsługujące jedną z poniższych funkcji: cipher (obsługa szyfrów symetrycznych), cipher-auth (obsługa szyfrów symetrycznych obsługujących szyfrowanie z uwierzytelnieniem), help (obsługa zapytań do użycia z opcją -Q), mac (obsługa kodów integralności komunikatów), kex (algorytmy wymiany klucza), kex-gss (algorytmy wymiany klucza GSSAPI), key (typy kluczy), key-ca-sign (prawidłowe algorytmy podpisów ośrodków certyfikacji dla certyfikatów), key-cert (typy kluczy certyfikatów), key-plain (typy kluczy niebędących certyfikatami), key-sig (wszystkie typy kluczy i algorytmy podpisów), protocol-version (obsługiwane wersje protokołu SSH) i sig (obsługiwane algorytmy podpisów). Alternatywnie, dowolne słowo kluczowe z ssh_config(5) lub sshd_config(5) przyjmujące listę algorytmów może posłużyć jako alias odpowiadającej opcji-odpytania.

Tryb cichy. Wyłącza większość ostrzeżeń i komunikatów diagnostycznych.

[adres-powiązania:]port:stacja:port-stacji
 
[adres-przypisania:]port:lokalne-gniazdo
 
zdalne-gniazdo:stacja:port-stacji
 
zdalne-gniazdo:lokalne-gniazdo
 
[adres-przypisania:]port
Określa, że połączenia z danym portem TCP lub gniazdem Uniksa na zdalnej stacji (serwerze) mają być przekierowywane na stronę lokalną.

Działa to, poprzez przydzielenia gniazda do nasłuchu albo portu TCP, albo gniazda Uniksa po stronie zdalnej. Gdy do tego portu lub gniazda Uniksa tworzone jest połączenie, jest ono przekierowywane poprzez bezpieczny kanał, a połączenie jest tworzone z lokalnego komputera albo do jawnie podanego położenia docelowego, określonego portem stacji port-stacji lub do lokalnego-gniazda, albo, jeśli nie podano jawnie lokalizacji, ssh będzie działał jako serwer pośredniczący SOCKS 4/5, przekierowując połączenia do celów zażądanych przez zdalnego klienta SOCKS.

Przekierowania portu można określić również w pliku konfiguracyjnym. Porty uprzywilejowane mogą być przekierowywane tylko, jeśli zalogowano się jako root na zdalnym komputerze. Adresy IPv6 można podać, ujmując je w nawiasy kwadratowe.

Domyślnie, gniazda nasłuchujące TCP na serwerze będą powiązane tylko z interfejsem pętli zwrotnej. Można to przesłonić, podając adres-powiązania. Pusty adres-powiązania lub adres o wartości „*” wskazuje, że gniazdo zdalne ma nasłuchiwać na wszystkich interfejsach. Podanie zdalnego adresu-powiązania powiedzie się tylko, jeśli na serwerze włączono opcję GatewayPorts (zob. sshd_config(5)).

Jeśli argumentem port będzie „0”, to nasłuchujący port zostanie dynamicznie przydzielony na serwerze i zgłoszony klientowi w momencie uruchomienia. Przy użyciu razem z opcją -O forward, przydzielony port zostanie wypisany na standardowe wyjście.

ścieżka-npz
Określa położenie gniazda sterującego dzieleniem połączenia; łańcuch „none” wyłączy dzielenie połączenia. Więcej szczegółów w opisie ControlPath i ControlMaster w podręczniku ssh_config(5).

Może posłużyć do zażądania przywołania podsystemu na zdalnym systemie. Podsystemy korzystają z SSH jako bezpiecznej komunikacji dla innych aplikacji (np. sftp(1)). Podsystem jest określony jako polecenie zdalne. Więcej szczegółów w opisie SessionType w podręczniku ssh_config(5).

Wyłącza przydzielenie pseudoterminala.

Wymusza przydzielenie pseudoterminala. Można w ten sposób wykonać dowolne programy korzystające z screen na zdalnym komputerze, co może być bardzo przydatne np. przy implementacji usług menu. Wielokrotna opcja -t wymusi przydzielenie tty, nawet, gdy ssh nie ma lokalnego tty.

Wyświetla numer wersji i wychodzi.

Tryb szczegółowy. Powoduje, że ssh wypisuje szczegółowe komunikaty informujące o postępach programu. Przydatne do rozwiązywania problemów z połączeniem, uwierzytelnieniem i konfiguracją. Opcja -v podana wielokrotnie zwiększa szczegółowość. Jej maksymalny poziom to 3.

stacja:port
Żąda, aby standardowe wejście i standardowe wyjście na kliencie były przekierowywane do stacji i portu poprzez bezpieczny kanał. Wymusza -N, -T, ExitOnForwardFailure i ClearAllForwardings, choć można je przesłonić w pliku konfiguracyjnym lub za pomocą opcji -o wiersza poleceń.

lokalny-tun[:zdalny-tun]
Żąda przekierowanie urządzenia tunelu za pomocą podanych urządzeń tun(4) pomiędzy klienckim (lokalnym-tun) i (zdalnym-tun) po stronie serwera.

Urządzenia te można określić numerycznym identyfikatorem lub słowem kluczowym „any”, które użyje następnego dostępnego urządzenia tunelu. Jeśli nie poda się zdalnego-tun, przyjmie on wartość domyślną „any”. Zob. też dyrektywy Tunnel i TunnelDevice w podręczniku ssh_config(5).

Jeśli dyrektywa Tunnel jest nieustawiona, będzie ustawiona na domyślny tryb tunelowania, którym jest „point-to-point”. Jeśli oczekiwany jest inny tryb przekierowania Tunnel, trzeba go określić przed podaniem opcji -w.

Włącza przekierowanie X11. Można to również określić w zależności od stacji, w pliku konfiguracyjnym.

Należy zachować ostrożność przed włączaniem przekierowania X11. Użytkownicy z możliwością pominięcia uprawnień pliku na stacji zdalnej (dla bazy danych autoryzacji użytkowników X) mogą uzyskać dostęp do lokalnego ekranu X11 za pomocą przekierowanego połączenia. Atakujący może następnie prowadzić aktywność taką jak podsłuchiwanie wprowadzanych klawiszy.

Z tego względu, przekierowanie X11 podlega domyślnie ograniczeniom wynikającym z rozszerzenia X11 SECURITY. Więcej szczegółów przy opcji -Y ssh i dyrektywie ForwardX11Trusted w podręczniku ssh_config(5).

(Konfiguracja w Debianie: przekierowania X11 nie podlegają domyślnie ograniczeniom rozszerzenia X11 SECURITY, ponieważ obecnie zbyt wiele programów załamuje się w tym trybie. Aby przywrócić domyślnie zachowanie autorów programu, należy ustawić opcję ForwardX11Trusted na „no”. Może się to zmienić w przyszłości, w zależności od usprawnień po stronie klienta).

Wyłącza przekierowanie X11.

Włącza zaufane przekierowanie X11. Zaufane przekierowania X11 nie podlegają regulacjom rozszerzenia X11 SECURITY.

(Konfiguracja w Debianie: W domyślnej konfiguracji, opcja ta jest odpowiednikiem -X, ponieważ ForwardX11Trusted domyślnie wynosi „yes”, jak opisano powyżej. Aby przywrócić domyślnie zachowanie autorów programu, należy ustawić opcję ForwardX11Trusted na „no”. Może się to zmienić w przyszłości, w zależności od usprawnień po stronie klienta).

Wysyła informacje dziennika do modułu systemowego syslog(3). Domyślnie informacje te są wypisywane na standardowe wyjście błędów.

ssh może dodatkowo pozyskiwać dane konfiguracyjne z pliku konfiguracyjnego użytkownika oraz z systemowego pliku konfiguracyjnego. Format pliku i opcje konfiguracyjne opisano w podręczniku ssh_config(5).

UWIERZYTELNIANIE

Klient SSH OpenSSH obsługuje protokół SSH 2.

Dostępne są następujące metody uwierzytelniania: uwierzytelnianie w oparciu o GSSAPI, uwierzytelnianie na podstawie danej stacji, uwierzytelnianie kluczem publicznym, uwierzytelnianie wymagające wpisania znaków z klawiatury i uwierzytelnianie hasłem. Domyślnie, próba uwierzytelnienia następuje według metod w opisanej kolejności, choć można ją zmienić za pomocą PreferredAuthentications.

Uwierzytelnianie na podstawie danej stacji działa w następujący sposób. Jeśli komputer, na którym loguje się użytkownik znajduje się na liście w plikach /etc/hosts.equiv lub /etc/ssh/shosts.equiv na zdalnym komputerze, użytkownik ten nie jest rootem, a nazwy użytkownika są identyczne po obu stronach, albo gdy pliki ~/.rhosts lub ~/.shosts istnieją w katalogu domowym użytkownika na komputerze zdalnym i zawierają wiersz z nazwą komputera klienckiego oraz nazwą użytkownika na tym komputerze, to użytkownik jest przedstawiany do zalogowania się. Dodatkowo serwer być w stanie zweryfikować klucz stacji klienckiej (zob. opis /etc/ssh/ssh_known_hosts i ~/.ssh/known_hosts, poniżej) aby logowanie się powiodło. Ta metoda uwierzytelnienia zamyka luki bezpieczeństwa związane z atakami IP spoofing (podszywaniem się pod numer IP), DNS spoofing oraz routing spoofing. [Uwaga do administratora: /etc/hosts.equiv, ~/.rhosts i w ogólności protokół rlogin/rsh są generalnie do gruntu niebezpieczne i powinny być wyłączone, jeśli oczekuje się zapewnienia bezpieczeństwa.]

Uwierzytelnianie kluczem publicznym działa następująco: ten sposób korzysta z kryptografii klucza publicznego, używając systemów kryptograficznych, w których szyfrowanie i odszyfrowywanie odbywa się odrębnymi kluczami i nie da się wywieść klucza odszyfrowującego z klucza szyfrującego. Każdy użytkownik tworzy zatem do celów uwierzytelniania parę kluczy: publiczny i prywatny. Serwer zna klucz publiczny, ale tylko użytkownik zna klucz prywatny. ssh automatycznie implementuje protokoły uwierzytelniania kluczem publicznym, za pomocą jednego z algorytmów: ECDSA, Ed25519 lub RSA.

Plik ~/.ssh/authorized_keys zawiera listę kluczy publicznych, którymi można się zalogować. Gdy użytkownik się zaloguje, ssh informuje serwer której pary kluczy chciałby użyć do uwierzytelnienia. Klient potwierdza, że ma dostęp do klucza prywatnego, a serwer sprawdza, czy powiązany klucz publiczny jest upoważniony do zaakceptowania danego konta.

Serwer może poinformować klienta o błędach, które uniemożliwiły poprawne uwierzytelnienie kluczem publicznym, ale dopiero po tym, gdy uwierzytelnienie nastąpi inną metodą. Można je sprawdzić zwiększając poziom LogLevel na DEBUG lub wyższy (np. opcją -v).

Użytkownik tworzy swoją parę kluczy poleceniem ssh-keygen(1). Klucz prywatny zostanie umieszczony w pliku ~/.ssh/id_ecdsa (ECDSA), ~/.ssh/id_ecdsa_sk (ECDSA po stronie uwierzytelniającego się), ~/.ssh/id_ed25519 (Ed25519), ~/.ssh/id_ed25519_sk (Ed25519 po stronie uwierzytelniającego się) lub ~/.ssh/id_rsa (RSA), a klucz publiczny w pliku ~/.ssh/id_ecdsa.pub (ECDSA), ~/.ssh/id_ecdsa_sk.pub (ECDSA po stronie uwierzytelniającego się), ~/.ssh/id_ed25519.pub (Ed25519), ~/.ssh/id_ed25519_sk.pub (Ed25519 po stronie uwierzytelniającego się) lub ~/.ssh/id_rsa.pub (RSA) w katalogu domowym użytkownika. Użytkownik powinien następnie skopiować klucz publiczny do pliku ~/.ssh/authorized_keys w swoim katalogu domowym na zdalnym komputerze. Plik authorized_keys odpowiada tradycyjnemu plikowi ~/.rhosts i posiada po jednym kluczu na wiersz, choć wiersze te mogą być bardzo długie. Po dokonaniu opisanych czynności, użytkownik może zalogować się bez podawania hasła.

Odmianą uwierzytelniania kluczem publicznym jest postać uwierzytelniania certyfikatem: zamiast zbioru kluczy publicznych/prywatnych, korzysta się z podpisanych certyfikatów. Ma to tę zaletę, że pojedynczy, zaufany ośrodek certyfikacji może służyć w miejscu wielu kluczy publicznych/prywatnych. Więcej informacji w rozdziale CERTYFIKATY w podręczniku ssh-keygen(1).

Najwygodniejszym sposobem korzystania z kluczy publicznych może być agent uwierzytelniania. Więcej informacji w podręczniku ssh-agent(1) i (opcjonalnie) w opisie dyrektywy AddKeysToAgent w ssh_config(5).

Uwierzytelnianie wymagające wpisania znaków z klawiatury działa następująco: Serwer wysyła arbitralny łańcuch „wyzwanie” i czeka na odpowiedź, być może powtarzając to wielokrotnie. Przykłady tego typu uwierzytelniania obejmują Uwierzytelniania BSD (zob. login.conf(5)) oraz PAM (część systemów innych niż Ox).

Ostatecznie, jeśli inne metody zawiodą, ssh pyta użytkownika o hasło. Hasło jest wysyłane do zdalnej stacji celem sprawdzenia; jednak ponieważ cała komunikacja jest szyfrowana, hasła nie da się podsłuchać z sieci.

ssh automatycznie zarządza i sprawdza bazę danych zawierającą identyfikatory wszystkich stacji, z jakimi był kiedykolwiek użyty. Klucze stacji są przechowywane w pliku ~/.ssh/known_hosts, w katalogu domowym użytkownika. Dodatkowo, sprawdzany jest automatycznie plik /etc/ssh/ssh_known_hosts pod kątem znanych stacji. Nowe stacje są dodawane automatycznie do pliku użytkownika. Gdyby identyfikacja stacji uległa zmianie, ssh ostrzeże o tym i wyłączy uwierzytelnienie hasłem, aby uniknąć podszywania się pod serwer oraz ataków typ man-in-the-middle, które mogłyby służyć do ominięcia szyfrowania. Opcją StrictHostKeyChecking można ograniczyć logowanie się do komputerów, których klucz stacji nie jest znany lub zmienił się.

Gdy identyfikacja użytkownika zostanie zaakceptowana przez serwer, serwer albo wykonuje podane polecenie w sesji nieinteraktywnej lub, jeśli nie podano polecenia, loguje się do komputera i daje użytkownikowi dostęp do zwykłej powłoki w sesji interaktywnej. Cała komunikacja ze zdalnym poleceniem lub powłoką będzie automatycznie szyfrowana.

Jeśli zażądano sesji interaktywnej, ssh domyślnie zażąda jedynie pseudoterminala (pty) do sesji interaktywnej, gdy klient taki posiada. Do przesłonięcia tego zachowania można użyć opcji -T i -t.

Jeśli przydzielono pseudoterminal, użytkownik może korzystać ze znaków specjalnych opisanych niżej.

Jeśli nie przydzielono pseudoterminala, sesja jest transparentna i może służyć do wiarygodnego przesyłania danych binarnych. W wielu systemach ustawienie znaku specjalnego na „none” również uczyni sesję transparentną nawet, gdy korzysta się z tty.

Sesja kończy się, gdy polecenie lub powłoka na komputerze zdalnym wyjdzie i wszystkie połączenia X11 i TCP zostaną zamknięte.

ZNAKI SPECJALNE

Gdy zażądano pseudoterminala, ssh obsługuje wiele funkcji za pomocą znaku specjalnego.

Pojedynczy znak tyldy można wysłać wpisując „~~” lub za pomocą podania po tyldzie znaku innego, niż jednego z opisanych niżej. Znak specjalny musi zawsze następować na początku wiersza, aby został zinterpretowany jako takowy. Znak specjalny można zmienić w plikach konfiguracyjnych za pomocą dyrektywy konfiguracyjnej EscapeChar lub w wierszu polecenia, opcją -e.

Obsługiwane sekwencje specjalne (zakładając domyślny znak specjalny „~”) to:

Rozłącza się.
ssh przechodzi w tło.
Wypisuje przekierowane połączenia.
ssh przechodzi w tło przy wylogowaniu, podczas oczekiwania na zakończenie przekierowanego połączenia lub sesji X11.
Wyświetla listę znaków specjalnych.
Wysyła BREAK do zdalnego systemu (przydatne tylko, jeśli ten umie go obsłużyć).
Otwiera wiersz polecenia. Obecnie pozwala to na uzupełnienie przekierowania portów za pomocą opcji -L, -R i -D (zob. wyżej). Pozwala również na odwołanie istniejących przekierowań portów za pomocą -KL[adres-przypisania:]port po stronie lokalnej, -KR[adres-przypisania:]port po stronie zdalnej oraz -KD[adres-przypisania:]port w przypadku dynamicznego przekierowania portów. !polecenie pozwala użytkownikowi na wykonanie polecenia lokalnego, jeśli włączona jest opcja PermitLocalCommand w pliku ssh_config(5). Skrócona pomoc jest dostępna za pomocą opcji -h.
Żąda odnowienia kluczy połączenia (przydatne tylko, jeśli zdalna stacja to obsługuje).
Zmniejsza szczegółowość (LogLevel), gdy błędy są wypisywane na standardowe wyjście błędów.
Zwiększa szczegółowość (LogLevel), gdy błędy są wypisywane na standardowe wyjście błędów.

PRZEKIEROWANIE TCP

Przekierowanie dowolnych połączeń TCP poprzez bezpieczny kanał można określić w wierszu polecenia albo w pliku konfiguracyjnym. Jednym z zastosowań przekierowania TCP może być bezpieczne połączenie z serwerem pocztowym, innym – omijanie zapór sieciowych.

W poniższym przykładzie obserwujemy szyfrowania komunikacji klienta IRC, nawet w sytuacji, gdy serwer IRC do którego się on łączy, nie obsługuje bezpośrednio szyfrowanej komunikacji. Działa to w następujący sposób: użytkownik łączy się ze zdalną stacją za pomocą ssh, podając porty, jakie mają posłużyć do przekierowania połączenia. Następnie można uruchomić program lokalnie, a ssh zaszyfruje i przekieruje połączenie do zdalnego serwera.

Poniższy przykład tuneluje sesję IRC z klienta do serwera IRC pod adresem „server.example.com”, dołącza do kanału „#users” z ksywką „pinky”, korzystając ze standardowego portu IRC, 6667:

$ ssh -f -L 6667:localhost:6667 server.example.com sleep 10
$ irc -c '#users' pinky IRC/127.0.0.1

Opcja -f umieszcza ssh w tle, a polecenie zdalne „sleep 10” służy daniu czasu (w tym przykładzie 10 sekund) na uruchomienie programu, który będzie używał tunelu. Jeśli w podanym czasie nie zostanie utworzone połączenie, ssh wyjdzie.

PRZEKIEROWANIE X11

Jeśli zmienna ForwardX11 jest ustawiona na „yes” (albo zob. opis opcji -X, -x i -Y powyżej), a użytkownik korzysta z X11 (ustawiona jest zmienna środowiskowa DISPLAY), połączenie do ekranu X11 jest automatycznie przekierowywane na stronę zdalną w ten sposób, że programy uruchomione w powłoce (lub poleceniem) są przepuszczane przez szyfrowany tunel, a połączenie do prawdziwego serwera X zostanie utworzone z lokalnego komputera. Użytkownik nie powinien ręcznie ustawiać DISPLAY. Przekierowywanie połączeń X11 można skonfigurować w wierszu polecenia lub w plikach konfiguracyjnych.

Wartość zmiennej DISPLAY ustawiona przez ssh będzie wskazywać na serwer, lecz z numerem ekranu większym niż zero. Jest to normalne zachowanie i ma miejsce, ponieważ ssh tworzy serwer „pośredniczący” X na serwerze, w celu przekierowania połączeń przez szyfrowany kanał.

ssh również automatycznie skonfiguruje dane Xauthority na serwerze. W tym celu utworzy losowe ciasteczko autoryzacji, przechowa je w Xauthority na serwerze i zweryfikuje, że wszelkie przekierowywane połączenia identyfikują się tym ciasteczkiem oraz zastąpi je prawdziwym ciasteczkiem po otwarciu połączenia. Prawdziwe ciasteczko autoryzacji nigdy nie jest wysyłane na serwer (a żadne ciasteczka nie są przesyłane jawnie).

Jeśli zmienna ForwardAgent jest ustawiona na „yes” (lub zob. opis opcji -A i -a powyżej), a użytkownik korzysta z agenta uwierzytelniania, to połączenie z agentem jest automatycznie przekierowywane na stronę zdalną.

WERYFIKOWANIE KLUCZY STACJI

Przy łączeniu się z serwerem po raz pierwszy, użytkownikowi prezentowany jest odcisk palca klucza publicznego serwera (chyba, że wyłączono opcję StrictHostKeyChecking). Odciski palców można określić za pomocą ssh-keygen(1):

$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key

Jeśli odcisk palca jest już znany, może być dopasowany, a klucz można zaakceptować lub odrzucić. Jeśli dostępne są tylko przestarzałe (MD5) odciski palców serwera, opcja -E programu ssh-keygen(1) może posłużyć do obniżenia poziomu algorytmu dopasowującego.

Z powodu trudności w porównywaniu odcisków palców stacji tylko na podstawie wizualnej obserwacji ciągów znaków, istnieje również możliwość wizualnego porównania kluczy stacji, za pomocą . Ustawiając opcję VisualHostKey na „yes”, przy każdym logowaniu do serwera wyświetlana jest niewielka grafika ASCII, bez znaczenia, czy sama sesja jest interaktywna, czy nie. Ucząc się tego wzoru, tworzonego przez znany serwer, użytkownik może w łatwy sposób przekonać się, gdy klucz stacji zmieni się, bowiem wyświetli to zupełnie odmienny wzór. Jednak wzory te nie są jednoznaczne, zatem wzór wyglądający podobnie do zapamiętanego daje jedynie duże prawdopodobieństwo, że klucz stacji pozostał ten sam, nie stanowi natomiast takiej gwarancji.

Aby pobrać listę odcisków palców wraz z ich losowymi grafikami dla wszystkich znanych stacji, można użyć następującego wiersza polecenia.

$ ssh-keygen -lv -f ~/.ssh/known_hosts

Jeśli odcisk palca jest nieznany, dostępna jest alternatywna metoda uwierzytelniania: odciski SSH zweryfikowane za pomocą SSH. Dodatkowy rekord zasobu (ang. resource record – RR), SSHFP, jest dodawany do pliku strefy, a łączący się klient może dopasować odcisk palca do odcisku prezentowanego klucza.

W tym przykładzie, następuje połączenie klienta do serwera „host.example.com”. Rekordy zasobu SSHFP powinno się najpierw dodać do pliku strefy dla host.example.com:

$ ssh-keygen -r host.example.com.

Wiersze wyjściowe zostaną dodane do pliku strefy. Aby sprawdzić, że strefa odpowiada na zapytania o odciski palców:

$ dig -t SSHFP host.example.com

I w końcu następuje połączenie klienta:

$ ssh -o "VerifyHostKeyDNS ask" host.example.com
[...]
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?

Więcej informacji przy opcji VerifyHostKeyDNS w podręczniku ssh_config(5).

WIRTUALNE SIECI PRYWATNE (VPN) WYKORZYSTUJĄCE SSH

ssh obsługuje tunelowanie wirtualnych sieci prywatnych (ang. Virtual Private Network – VPN) za pomocą pseudourządzenia sieciowego tun(4), pozwalając na bezpieczne złączenie dwóch sieci. Opcja konfiguracyjna PermitTunnel w sshd_config(5) kontroluje, czy serwer to obsługuje i na jakim poziomie (2. lub 3. warstwa transportowa).

W poniższym przykładzie klient łączy sieć 10.0.50.0/24 ze zdalną siecią 10.0.99.0/24 za pomocą połączenia typu point-to-point z adresu 10.1.1.1 do 10.1.1.2, zakładając, że serwer SSH działający na bramie sieciowej zdalnej sieci, pod adresem 192.168.1.15, na to pozwala.

Po stronie klienta:

# ssh -f -w 0:1 192.168.1.15 true
# ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252
# route add 10.0.99.0/24 10.1.1.2

Po stronie serwera:

# ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.252
# route add 10.0.50.0/24 10.1.1.1

Dostęp klienta można dokładnie skonfigurować za pomocą pliku /root/.ssh/authorized_keys (zob. niżej) i opcji serwera PermitRootLogin. Poniższy wpis zezwoliłby na połączenia na 1. urządzeniu tun(4) od użytkownika „jane”, a na 2. urządzeniu tun od użytkownika „john”, jeśli PermitRootLogin jest ustawione na „forced-commands-only”:

tunnel="1",command="sh /etc/netstart tun1" ssh-rsa ... jane
tunnel="2",command="sh /etc/netstart tun2" ssh-rsa ... john

Konfiguracja korzystająca z SSH pociąga za sobą sporo narzutu, zatem może być właściwsza do konfiguracji tymczasowych, takich jak bezprzewodowe VPN. Dla długotrwałych konfiguracji VPN istnieją lepsze narzędzia, takie jak ipsecctl(8) i isakmpd(8).

ŚRODOWISKO

ssh zwykle ustawi następujące zmienne środowiskowe:

Zmienna DISPLAY wskazuje położenie serwera X11. Jest automatycznie ustawiana przez ssh, aby wskazywać na wartość w postaci „nazwa-stacji:n”, gdzie „nazwa-stacji” oznacza stację, na której działa powłoka, a „n” jest liczbą całkowitą ≥ 1. ssh używa tej wartości specjalnej do przekierowania połączeń X11 bezpiecznym kanałem. Użytkownicy zwykle nie powinni sami ustawiać zmiennej DISPLAY, ponieważ uczyniłoby to połączenie X11 niezabezpieczonym (i wymagałoby ręcznego kopiowania wymaganych ciasteczek autoryzujących).
Ustawiana na ścieżkę katalogu domowego użytkownika.
Równoważne USER; ustawiana ze względu na kompatybilność z systemami korzystającymi z tej zmiennej.
Ustawiana na ścieżkę skrzynki pocztowej użytkownika.
Ustawiana na domyślną PATH, jak określono przy kompilacji ssh.
Jeśli ssh wymaga frazy kodującej, odczyta frazę kodującą z bieżącego terminala, jeśli program uruchomiono z terminala. Jeśli ssh nie ma powiązanego terminala, lecz ustawiono zmienne DISPLAY i SSH_ASKPASS, wykonany zostanie program określony zmienną SSH_ASKPASS i otwarte będzie okno X11 służące do odczytu frazy kodującej. Przydatne szczególnie przy wywołaniu ssh z .xsession lub powiązanego skryptu (proszę zauważyć, że na niektórych komputerach aby to zadziałało, może być konieczne przekierowanie wejścia z /dev/null).
Pozwala na dokładniejszą kontrolę nad programem askpass. Jeśli zmienną ustawiono na „never”, to ssh nigdy nie będzie go używał. Jeśli ustawi się ją na „prefer”, to przy odpytywaniu o hasła ssh będzie preferował korzystanie z programu askpass zamiast TTY. Jeśli natomiast zmienną ustawi się na „force”], to program askpass będzie używany do wszelkiego wprowadzania fraz kodujących, niezależnie od tego, czy ustawiono DISPLAY.
Identyfikuje ścieżkę gniazda domeny Uniksa służącego do komunikacji z agentem.
Identyfikuje końcówki połączenia po stronie klienta i serwera. Zmienna zawiera cztery wartości rozdzielone spacją: adres IP klienta, numer portu klienta, adres IP serwera i numer portu serwera.
Zmienna zawiera pierwotny wiersz polecenia, jeśli wykonywane jest wymuszone polecenie. Może posłużyć do wydobycia pierwotnych argumentów.
Ustawiana na nazwę tty (ścieżka do urządzenia) powiązanego z bieżącą powłoką lub poleceniem. Jeśli bieżąca sesja nie posiada tty, zmienna ta nie jest ustawiana.
Opcjonalnie ustawiana przez sshd(8); zawiera przypisane nazwy interfejsów, jeśli klient zażądał przekierowania tunelem.
Opcjonalnie ustawiana przez sshd(8), zmienna ta może zawierać ścieżkę do pliku zawierającego listę pomyślnie dokonanych metod uwierzytelnia, które posłużyły do zestawienia sesji, w tym użytych kluczy publicznych.
Zmienna ta służy do wskazania bieżącej strefy czasowej, jeśli była ustawiona przy uruchomieniu demona (tj. demon przekazał tę wartość nowym połączeniom).
Ustawiana na nazwę logującego się użytkownika.

Dodatkowo ssh odczytuje plik ~/.ssh/environment i dodaje wiersze w postaci „NAZWA-ZMIENNEJ=wartość” do środowiska, jeśli plik ten istnieje, a użytkownicy mogą zmieniać swoje środowisko. Więcej informacji w opisie opcji PermitUserEnvironment w podręczniku sshd_config(5).

PLIKI

~/.rhosts
Plik używany przy uwierzytelnianiu na podstawie danej stacji (zob. wyżej). Na niektórych komputerach może być konieczne, aby plik ten był odczytywalny dla wszystkich, jeśli katalog domowy użytkownika jest na partycji NFS, ponieważ sshd(8) odczytuje go jako root. Dodatkowo plik ten musi być własnością użytkownika i nie może posiadać uprawnień do zapisu dla kogokolwiek innego. Zalecany zestaw uprawnień w większości konfiguracji to: odczyt/zapis dla użytkownika i brak dostępu dla pozostałych.

~/.shosts
Plik używany dokładnie w ten sam sposób jak .rhosts, lecz zezwala na uwierzytelnienie na podstawie danej stacji bez dozwolenia logowań za pomocą rlogin/rsh.

~/.ssh/
Katalog jest domyślnym położeniem dla całej konfiguracji danego użytkownika oraz informacji uwierzytelniających. Nie ma ogólnego wymagania, aby zawartość całego katalogu była utrzymywana w tajemnicy, ale zaleca się uprawnienia do odczytu/zapisu/wykonania dla użytkownika i brak dostępu dla pozostałych.

~/.ssh/authorized_keys
Lista kluczy publicznych (ECDSA, Ed25519, RSA), które mogą służyć do logowania się jako dany użytkownik. Format tego pliku opisano w podręczniku sshd(8). Plik ten nie jest zbyt wrażliwy, ale zaleca się uprawnienia do odczytu/zapisu dla użytkownika i brak dostępu dla pozostałych.

~/.ssh/config
Plik konfiguracyjny użytkownika. Format pliku i opcje konfiguracyjne opisano w podręczniku ssh_config(5). Ze względu na możliwości nadużyć, plik musi posiadać ścisłe uprawnienia: odczyt/zapis przez użytkownika i brak zapisu przez pozostałych. Może być zapisywalny dla grupy zakładając, że przedmiotowa grupa zawiera tylko samego użytkownika.

~/.ssh/environment
Dodatkowe definicje zmiennych środowiskowych: zob. ŚRODOWISKO, powyżej.

~/.ssh/id_ecdsa
 
~/.ssh/id_ecdsa_sk
 
~/.ssh/id_ed25519
 
~/.ssh/id_ed25519_sk
 
~/.ssh/id_rsa
Zawierają prywatne klucze do uwierzytelniania. Pliki te zawierają wrażliwe dane i powinny być odczytywalne dla użytkownika ale niedostępne dla innych (brak uprawnienia do odczytu/zapisu/wykonania). ssh po prostu pominie klucz prywatny, który jest dostępny dla innych. Przy tworzeniu klucza prywatnego można ustawić frazę kodującą, która zostanie użyta do zaszyfrowania wrażliwych części tego pliku za pomocą AES-128.

~/.ssh/id_ecdsa.pub
 
~/.ssh/id_ecdsa_sk.pub
 
~/.ssh/id_ed25519.pub
 
~/.ssh/id_ed25519_sk.pub
 
~/.ssh/id_rsa.pub
Zawierają klucze publiczne do uwierzytelniania. Pliki te nie zawierają danych wrażliwych i mogą być (ale nie muszą) odczytywalne dla wszystkich.

~/.ssh/known_hosts
Zawiera listę kluczy stacji dla wszystkich stacji, do których użytkownik się logował, a nie występują w systemowej liście kluczy znanych stacji. Więcej informacji na temat formatu tego pliku opisano w podręczniku sshd(8).

~/.ssh/rc
Polecenia w pliku są wykonywane przez ssh, gdy użytkownik się zaloguje, zaraz przed uruchomieniem powłoki użytkownika (lub polecenia). Więcej informacji w podręczniku sshd(8).

/etc/hosts.equiv
Plik służy do uwierzytelniania w oparciu o stację (zob. wyżej). Powinien być zapisywalny tylko przez roota.

/etc/ssh/shosts.equiv
Plik używany dokładnie w ten sam sposób jak hosts.equiv, lecz zezwala na uwierzytelnienie na podstawie danej stacji bez dozwolenia logowań za pomocą rlogin/rsh.

/etc/ssh/ssh_config
Systemowy plik konfiguracyjny. Format pliku i opcje konfiguracji opisano w podręczniku ssh_config(5).

/etc/ssh/ssh_host_ecdsa_key
 
/etc/ssh/ssh_host_ed25519_key
 
/etc/ssh/ssh_host_rsa_key
Pliki zawierają części prywatne kluczy stacji i służą do uwierzytelniania w oparciu o stację.

/etc/ssh/ssh_known_hosts
Systemowa lista kluczy znanych stacji. Plik powinien być przygotowany przez administratora systemu w taki sposób, aby zawierał publiczne klucze stacji wszystkich komputerów w danej organizacji. Powinien być odczytywalny dla wszystkich. Więcej informacji o formacie tego pliku opisano w podręczniku sshd(8).

/etc/ssh/sshrc
Polecenia w pliku są wykonywane przez ssh, gdy użytkownik się zaloguje, zaraz przed uruchomieniem powłoki użytkownika (lub polecenia). Więcej informacji w podręczniku sshd(8).

STATUS ZAKOŃCZENIA

ssh wychodzi ze statusem zakończenia zdalnego polecenia lub z 255, jeśli wystąpił błąd.

ZOBACZ TAKŻE

scp(1), sftp(1), ssh-add(1), ssh-agent(1), ssh-argv0(1), ssh-keygen(1), ssh-keyscan(1), tun(4), ssh_config(5), ssh-keysign(8), sshd(8)

STANDARDY

S. Lehtinen and C. Lonvick, The Secure Shell (SSH) Protocol Assigned Numbers, RFC 4250, styczeń 2006.

T. Ylonen and C. Lonvick, The Secure Shell (SSH) Protocol Architecture, RFC 4251, styczeń 2006.

T. Ylonen and C. Lonvick, The Secure Shell (SSH) Authentication Protocol, RFC 4252, styczeń 2006.

T. Ylonen and C. Lonvick, The Secure Shell (SSH) Transport Layer Protocol, RFC 4253, styczeń 2006.

T. Ylonen and C. Lonvick, The Secure Shell (SSH) Connection Protocol, RFC 4254, styczeń 2006.

J. Schlyter and W. Griffin, Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints, RFC 4255, styczeń 2006.

F. Cusack and M. Forssen, Generic Message Exchange Authentication for the Secure Shell Protocol (SSH), RFC 4256, styczeń 2006.

J. Galbraith and P. Remaker, The Secure Shell (SSH) Session Channel Break Extension, RFC 4335, styczeń 2006.

M. Bellare, T. Kohno, and C. Namprempre, The Secure Shell (SSH) Transport Layer Encryption Modes, RFC 4344, styczeń 2006.

B. Harris, Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol, RFC 4345, styczeń 2006.

M. Friedl, N. Provos, and W. Simpson, Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol, RFC 4419, marzec 2006.

J. Galbraith and R. Thayer, The Secure Shell (SSH) Public Key File Format, RFC 4716, listopad 2006.

D. Stebila and J. Green, Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer, RFC 5656, grudzień 2009.

A. Perrig and D. Song, Hash Visualization: a New Technique to improve Real-World Security, 1999, International Workshop on Cryptographic Techniques and E-Commerce (CrypTEC '99).

AUTORZY

OpenSSH wywodzi się z pierwotnego i wolnego wydania ssh 1.2.12 autorstwa Tatu Ylonena. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt i Dug Song usunęli wiele błędów, dodali na nowo nowsze funkcje i utworzyli OpenSSH. Markus Friedl miał udział w dodaniu obsługi protokołów SSH w wersji 1.5 i 2.0.

TŁUMACZENIE

Autorami polskiego tłumaczenia niniejszej strony podręcznika są: Michał Kułach <michal.kulach@gmail.com>

Niniejsze tłumaczenie jest wolną dokumentacją. Bliższe informacje o warunkach licencji można uzyskać zapoznając się z GNU General Public License w wersji 3 lub nowszej. Nie przyjmuje się ŻADNEJ ODPOWIEDZIALNOŚCI.

Błędy w tłumaczeniu strony podręcznika prosimy zgłaszać na adres listy dyskusyjnej manpages-pl-list@lists.sourceforge.net

December 4, 2024 Debian