Ubuntu Manpage: ssh — klient zdalnego logowania OpenSSH

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), „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
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

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

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

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

-x Wyłącza przekierowanie X11.

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

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

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

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

       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 .

Debian                                          December 4, 2024                                          SSH(1)