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:

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

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

-A  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).

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

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

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

-C  Żą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).

-c 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.

-D  [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.

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

-e 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ą.

-F 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.

-f  Żą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).

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

-g  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.

-I 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.

-i 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.

-J 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.

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

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

-L  [adres-powiązania:] port:stacja:port-stacji
-L  [adres-powiązania:] port:zdalne-gniazdo
-L  lokalne-gniazdo:stacja:port-stacji
-L  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.

-l 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.

-M  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).

-m 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).

-N  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).

-n  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).

-O 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), „conninfo” (zgłasza informacje o głównym połączeniu), „channels” (zgłasza informacje o otwartych kanałach), „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).

-o 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
    GSSAPIDelegateCredentials
    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

-P 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).
-p 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.

-Q 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), 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.

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

-R  [adres-powiązania:] port:stacja:port-stacji
-R  [adres-przypisania:] port:lokalne-gniazdo
-R  zdalne-gniazdo:stacja:port-stacji
-R  zdalne-gniazdo:lokalne-gniazdo
-R  [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.

-S ś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).

-s  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).

-T  Wyłącza przydzielenie pseudoterminala.

-t  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.

-V  Wyświetla numer wersji i wychodzi.

-v  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.

-W 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ń.

-w  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.

-X  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).

-x  Wyłącza przekierowanie X11.

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

-y  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 musi 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ż OpenBSD).

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ę.

~^Z 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.

~B  Wysyła BREAK do zdalnego systemu (przydatne tylko, jeśli ten umie go obsłużyć).

~C  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.

~I  Pokazuje informacje o bieżącym połączeniu SSH.

~R  Żąda odnowienia kluczy połączenia (przydatne tylko, jeśli zdalna stacja to obsługuje).

~V  Zmniejsza szczegółowość (LogLevel), gdy błędy są wypisywane na standardowe wyjście błędów.

~v  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ą grafiki losowej. 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:

DISPLAY
    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).

HOME
    Ustawiana na ścieżkę katalogu domowego użytkownika.

LOGNAME
    Równoważne USER; ustawiana ze względu na kompatybilność z systemami korzystającymi z tej zmiennej.

MAIL
    Ustawiana na ścieżkę skrzynki pocztowej użytkownika.

PATH
    Ustawiana na domyślną PATH, jak określono przy kompilacji ssh.

SSH_ASKPASS
    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).

SSH_ASKPASS_REQUIRE
    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.

SSH_AUTH_SOCK
    Identyfikuje ścieżkę gniazda domeny Uniksa służącego do komunikacji z agentem.

SSH_CONNECTION
    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.

SSH_ORIGINAL_COMMAND
    Zmienna zawiera pierwotny wiersz polecenia, jeśli wykonywane jest wymuszone polecenie. Może posłużyć do wydobycia pierwotnych argumentów.

SSH_TTY
    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.

SSH_TUNNEL
    Opcjonalnie ustawiana przez sshd(8); zawiera przypisane nazwy interfejsów, jeśli klient zażądał przekierowania tunelem.

SSH_USER_AUTH
    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.

TZ  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).

USER
    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.

~/.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-keygen(1), ssh-keyscan(1), tun(4), ssh_config(5), ssh-keysign(8), sshd(8)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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
Tłumaczenie niniejszej strony podręcznika: 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: https://www.gnu.org/licenses/gpl-3.0.html 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.