| SSH(1) | General Commands Manual | SSH(1) |
ssh — klient
zdalnego logowania OpenSSH
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]
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:
-4ssh używanie tylko
adresów IPv4.
-6ssh używanie tylko
adresów IPv6.
-APrzekierowywania 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-B
interfejs-przypisania-b
adres-przypisania-CCompression w
ssh_config(5).
-c
określenie-szyfruCiphers w ssh_config(5), aby
dowiedzieć się więcej.
-D
[adres-przypisania:]portssh 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-e
znak-specjalny-F
plik-konfiguracyjny-fssh 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).
-Gssh wypisze swoją
konfigurację po przeanalizowaniu bloków
Host oraz Match, a potem
wyjdzie.
-g-I
pkcs11ssh powinien
używać do komunikacji z tokenem PKCS#11,
zapewniającym klucze do uwierzytelnienia użytkownika.
-i
plik-tożsamości-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-docelowessh 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-k-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-gniazdoPrzekierowania 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-Mssh 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-macMACs w podręczniku
ssh_config(5).
-NSessionType w podręczniku
ssh_config(5).
-nssh
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-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-P
znacznikTag i
Match w podręczniku
ssh_config(5).-p
port-Q
opcja-odpytania-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-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:]portDział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-npzControlPath i
ControlMaster w podręczniku
ssh_config(5).
-sSessionType w podręczniku
ssh_config(5).
-T-t-t wymusi przydzielenie tty, nawet, gdy
ssh nie ma lokalnego tty.
-V-vssh 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-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]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.
-XNależ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-Y(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).
-yssh 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).
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.
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:
~.~^Zssh przechodzi w tło.~#~&ssh przechodzi w tło przy wylogowaniu,
podczas oczekiwania na zakończenie przekierowanego
połączenia lub sesji X11.~?~B~C-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~VLogLevel), gdy błędy są
wypisywane na standardowe wyjście błędów.~vLogLevel), gdy błędy są
wypisywane na standardowe wyjście błędów.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.
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ą.
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_keyJeś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_hostsJeś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.comI 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).
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).
ssh zwykle ustawi
następujące zmienne środowiskowe:
DISPLAYDISPLAY 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).HOMELOGNAMEUSER; ustawiana ze
względu na kompatybilność z systemami
korzystającymi z tej zmiennej.MAILPATHPATH, jak
określono przy kompilacji ssh.SSH_ASKPASSssh 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_REQUIREssh 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_SOCKSSH_CONNECTIONSSH_ORIGINAL_COMMANDSSH_TTYSSH_TUNNELSSH_USER_AUTHTZUSERDodatkowo 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).
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,
gdy użytkownik się zaloguje, zaraz przed uruchomieniem
powłoki użytkownika (lub polecenia). Więcej
informacji w podręczniku sshd(8).
ssh,
gdy użytkownik się zaloguje, zaraz przed uruchomieniem
powłoki użytkownika (lub polecenia). Więcej
informacji w podręczniku sshd(8).ssh wychodzi ze statusem
zakończenia zdalnego polecenia lub z 255, jeśli
wystąpił błąd.
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)
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).
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 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 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 |