OpenSSH (Polski) - ArchWiki

Jump to content

# OpenSSH (Polski)

From ArchWiki

Related articles

- SSH keys
- Pam abl
- fail2ban
- sshguard
- Sshfs
- Syslog-ng
- SFTP chroot
- SCP and SFTP
- VPN over SSH

OpenSSH (OpenBSD Secure Shell) to zestaw programów zapewniających szyfrowane sesje SSH w sieci komputerowej. Stworzony jako alternatywa open source dla zastrzeżonego pakietu Secure Shell oferowanego przez SSH Communications Security. OpenSSH jest rozwijany w ramach projektu OpenBSD, prowadzonego przez Theo de Raadta.

OpenSSH jest czasem mylony z podobnie nazwanym OpenSSL, jednak projekty mają różne cele i są rozwijane przez różne zespoły — podobna nazwa pochodzi jedynie z podobnych celów.

## Instalacja

Install the openssh package.

## Client usage

Aby połączyć się z serwerem, uruchom:

    $ ssh -p port user@server-address

Jeśli serwer zezwala wyłącznie na uwierzytelnianie kluczem publicznym, wykonaj poniższe kroki SSH keys.

### Konfiguracja

This article or section needs expansion.

Reason: openssh 9.4p1-2 added `Include /etc/ssh/ssh_config.d/*.conf` to `/etc/ssh/ssh_config`. The instructions can now be made to use drop-in files. (Discuss in Talk:OpenSSH (Polski))

Klienta można skonfigurować do przechowywania wspólnych opcji i hostów. Wszystkie opcje można zadeklarować globalnie lub ograniczyć do konkretnych hostów. Na przykład:

    ~/.ssh/config

    # global options
    User user1

    # host-specific options
    Host myserver
        Hostname server-address
        Port     port
        User     user2

Przy takiej konfiguracji następujące polecenia są równoważne

    $ ssh -p port user2@server-address
    $ ssh myserver

See ssh_config(5) for more information.

Some options do not have command line switch equivalents, but you can specify configuration options on the command line with `-o`. For example `-oKexAlgorithms=+diffie-hellman-group1-sha1`.

## Server usage

This article or section needs expansion.

Reason: openssh 9.4p1-2 added `Include /etc/ssh/sshd_config.d/*.conf` to `/etc/ssh/sshd_config`. The instructions can now be made to use drop-in files. (Discuss in Talk:OpenSSH (Polski))

`sshd` to demon OpenSSH, skonfigurowany w `/etc/ssh/sshd_config` i zarządzany przez `sshd.service`. Przy każdej zmianie konfiguracji użyj `sshd` w trybie testowym przed ponownym uruchomieniem usługi, aby upewnić się, że uruchomi się prawidłowo. Prawidłowe konfiguracje nie generują żadnych danych wyjściowych.

    # sshd -t

### Konfiguracja

Aby zezwolić na dostęp tylko niektórym użytkownikom, dodaj następujący wiersz:

    AllowUsers    user1 user2

Aby zezwolić na dostęp tylko niektórym grupom:

    AllowGroups   group1 group2

Aby dodać miłą wiadomość powitalną (np. z pliku `/etc/issue`), skonfiguruj opcję `Banner`:

    Banner /etc/issue

Publiczne i prywatne klucze hosta są automatycznie generowane w `/etc/ssh` przez usługę `sshdgenkeys` zarządzania demonem i regenerowane w przypadku ich braku, nawet jeśli opcja `HostKeyAlgorithms` w `sshd_config` ogranicza się do wybranych algorytmów. Generowane są trzy pary kluczy na podstawie algorytmów ed25519, ecdsa i rsa. Aby sshd używał konkretnego klucza, określ następującą opcję:

    HostKey /etc/ssh/ssh_host_ed25519_key

Jeżeli serwer ma być wystawiony na sieć WAN, zaleca się zmianę domyślnego portu z 22 na losowy, wyższy port, w następujący sposób:

    Port 39901

Tip

- Aby wybrać alternatywny port niezapisany dla typowej usługi, sprawdź listę numerów portów TCP i UDP. Informacje o portach dostępne są również lokalnie w `/etc/services`. Zmiana portu z domyślnego 22 zmniejszy liczbę wpisów dziennika spowodowanych zautomatyzowanymi próbami uwierzytelnienia, ale ich nie wyeliminuje. Więcej informacji w Port knocking.
- Zaleca się całkowite wyłączenie logowania hasłem. To znacznie zwiększy bezpieczeństwo. Więcej informacji można znaleźć w artykule #Force public key authentication Więcej zalecanych metod zabezpieczeń można znaleźć w artykule #Protection
- OpenSSH może nasłuchiwać na wielu portach, wystarczy umieścić w pliku konfiguracyjnym kilka wierszy `Port port_number`.
- Nowe (lub brakujące) pary kluczy hosta można wygenerować, usuwając parę(y), które chcesz zastąpić, z `/etc/ssh` i uruchamiając `ssh-keygen -A` jako root.

### Zarządzanie demonami

Start/enable `sshd.service`. Utrzyma demona SSH w stanie aktywnym i będzie fork'ować dla każdego przychodzącego połączenia.

#### Socket activation

W wersji openssh 8.0p1-3 usunięto `sshd.socket`, który korzystał z socket activation systemd, ponieważ był podatny na denial of service. Zobacz FS#62248 aby uzyskać szczegóły. Jeśli `sshd.socket` jest włączony podczas aktualizacji do openssh 8.0p1-3, jednostki `sshd.socket` i `sshd@.service` zostaną skopiowane do `/etc/systemd/system/` i reenabled. Jest to zrobione tylko po to, aby nie uszkodzić istniejących konfiguracji; użytkownikom nadal zaleca się migracja do `sshd.service`.

Warning Jeśli nadal będziesz używać `sshd.socket`, pamiętaj o jego problemach:

- Jednostka `sshd.socket` może ulec awarii (np. z powodu braku pamięci), a parametru `Restart=always` nie można określić w jednostkach z gniazdem. Zobacz problem systemd nr 11553.
- Użycie aktywacji gniazda może skutkować odmową usługi, ponieważ zbyt duża liczba połączeń może uniemożliwić dalszą aktywację usługi. Zobacz FS#62248.

Użycie `sshd.socket` neguje ustawienie `ListenAddress`, co umożliwia połączenia przez dowolny adres. Aby uzyskać efekt ustawienia `ListenAddress`, należy określić port i adres IP dla `ListenStream` (np. `ListenStream=192.168.1.100:22`) poprzez edit pliku `sshd.socket`. Należy również dodać `FreeBind=true` w sekcji `[Socket]`, w przeciwnym razie ustawienie adresu IP będzie miało tę samą wadę co ustawienie `ListenAddress`: socket nie uruchomi się, jeśli sieć nie będzie aktywna w odpowiednim czasie.

Podczas aktywacji przez socket, dla każdego połączenia uruchamiana jest tymczasowa instancja `sshd@.service` (z różnymi nazwami instancji). W związku z tym ani `sshd.socket`, ani zwykła `sshd.service` nie pozwalają monitorować prób połączeń w logach. Logi instancji SSH aktywowanych przez socket można wyświetlić jako root poleceniami: `journalctl -u "sshd@*"` i `journalctl /usr/bin/sshd`

### Ochrona

Zezwolenie na zdalne logowanie przez SSH jest niezbędne do celów administracyjnych, ale stanowi zagrożenie dla bezpieczeństwa serwera. SSH jest częstym celem ataków siłowych. Dostęp SSH musi być odpowiednio ograniczony, aby zapobiegać nieautoryzowanemu dostępowi.

ssh-audit oferuje automatyczną analizę konfiguracji serwera i klienta. Dostępnych jest kilka innych dobrych poradników i narzędzi na ten temat, na przykład:

- Article by Mozilla Infosec Team
- SSH Hardening Guides

#### Wymuś uwierzytelnianie kluczem publicznym

Jeśli klient nie może uwierzytelniać się za pomocą klucza publicznego, serwer SSH domyślnie powraca do uwierzytelniania hasłem, umożliwiając w ten sposób atakującemu próbę uzyskania dostępu poprzez brute-force hasła. Jednym z najskuteczniejszych sposobów ochrony przed tym atakiem jest całkowite wyłączenie logowania hasłem i wymuszenie użycia kluczy SSH. Można to osiągnąć, ustawiając następujące opcje w pliku konfiguracyjnym serwera:

    /etc/ssh/sshd_config.d/20-force_publickey_auth.conf

    PasswordAuthentication no
    AuthenticationMethods publickey

Warning Zanim dodasz to do konfiguracji, upewnij się, że wszystkie konta wymagające dostępu SSH mają skonfigurowane uwierzytelnianie kluczem publicznym w odpowiednich plikach `authorized_keys`. Patrz SSH keys#Copying the public key to the remote server Aby uzyskać więcej informacji.

#### Uwierzytelnianie dwuskładnikowe i klucze publiczne

Protokół SSH można skonfigurować tak, aby wymagał wielu metod uwierzytelniania. Wymagane metody uwierzytelniania można sprawdzić za pomocą opcji `AuthenticationMethods`. Umożliwia to korzystanie z kluczy publicznych oraz autoryzacji dwuskładnikowej.

##### Dostawcy uwierzytelniania

Aby skonfigurować Google Authenticator, zapoznaj się z informacjami na jej temat.

For Duo, install duo_unixAUR which will supply the `pam_duo.so` module. Read the Duo Unix documentation for instructions on how to setup the necessary Duo credentials (Integration Key, Secret Key, API Hostname).

##### Konfiguracja PAM

The factual accuracy of this article or section is disputed.

Reason: The distribution defaults to `KbdInteractiveAuthentication no` since [1]. Later, the lexical order of the defaults was adjusted due to FS#79285 to allow for higher priority user snippets, which would match below `20-pam.conf`. However, a BBS thread appears to be resolved by ordering custom after `99-archlinux.conf` defaults only. (Discuss in Talk:OpenSSH (Polski))

Aby użyć PAM z OpenSSH, edytuj następujące pliki:

    /etc/ssh/sshd_config.d/20-pam.conf

    KbdInteractiveAuthentication yes
    AuthenticationMethods publickey keyboard-interactive:pam

Następnie możesz zalogować się kluczem publicznym lub hasłem użytkownika, zgodnie z wymaganiami konfiguracji PAM.

Jeśli natomiast wymagane jest uwierzytelnianie kluczem publicznym i metodą PAM jednocześnie, oddziel je przecinkiem zamiast spacją w opcji AuthenticationMethods:

    /etc/ssh/sshd_config.d/20-pam.conf

    KbdInteractiveAuthentication yes
    AuthenticationMethods publickey,keyboard-interactive:pam

Jeśli wymagany jest klucz publiczny i uwierzytelnianie PAM, możesz wyłączyć wymaganie podania hasła:

    /etc/pam.d/sshd

    auth      required  pam_securetty.so     #disable remote root
    #Require google authenticator
    auth      required  pam_google_authenticator.so
    #But not password
    #auth      include   system-remote-login
    account   include   system-remote-login
    password  include   system-remote-login
    session   include   system-remote-login

#### Ochrona przed atakami siłowymi

Brute forcing to prosta metoda: wielokrotne próby zalogowania się do strony internetowej lub serwera (np. SSH) przy użyciu dużej liczby losowych kombinacji nazwy użytkownika i hasła.

Zobacz ufw#Rate limiting with ufw lub Simple stateful firewall#Bruteforce attacks dla iptables.

Od wersji 9.8 zaimplementowano podstawową ochronę podobną do fail2ban: opcja `PerSourcePenalties` posiada rozsądne wartości domyślne. Kary za różne warunki są egzekwowane na podstawie adresu źródłowego klienta, co powoduje odrzucenie połączenia na określony czas.

Alternatywą jest ochrona przed atakami siłowymi poprzez użycie zautomatyzowanego skryptu, który blokuje każdego, kto próbuje wedrzeć się do Twojego systemu siłą.

- Zezwalaj tylko na połączenia przychodzące SSH z zaufanych lokalizacji
- Użyj fail2ban lub sshguard, aby automatycznie blokować adresy IP, które zbyt wiele razy nie przejdą uwierzytelniania hasłem.
- Użyj pam_shield, aby zablokować adresy IP, które podejmują zbyt wiele prób logowania w określonym czasie. W przeciwieństwie do fail2ban lub sshguard, ten program nie bierze pod uwagę powodzenia ani niepowodzenia logowania.

#### Ogranicz logowanie roota

This article or section is out of date.

Reason: Root login has been disabled by default upstream in the current version. Unclear to me what parts of this section and subsections are redundant. (Discuss in Talk:OpenSSH (Polski))

Zezwalanie użytkownikowi root na nieograniczone logowanie się przez SSH jest powszechnie uważane za złą praktykę. Istnieją dwie metody ograniczenia dostępu użytkownika root przez SSH w celu zwiększenia bezpieczeństwa.

##### Deny

sudo selektywnie przyznaje uprawnienia roota do operacji wymagających tych uprawnień bez konieczności uwierzytelniania się wobec konta root. Pozwala to na zablokowanie konta root przed dostępem przez SSH i stanowi potencjalną ochronę przed atakami brute-force, ponieważ atakujący musi teraz odgadnąć nazwę użytkownika oprócz hasła.

SSH można skonfigurować, aby zabronić zdalnych logowań użytkownika root, edytując sekcję „Authentication" w pliku konfiguracyjnym daemona. Wystarczy ustawić `PermitRootLogin` na wartość `no`:

    /etc/ssh/sshd_config.d/20-deny_root.conf

    PermitRootLogin no

Następnie restart demona SSH.

Od teraz nie będziesz w stanie zalogować się przez SSH jako root, ale nadal będziesz mógł zalogować się za pomocą zwykłego konta użytkownika i używać su lub sudo do administrowania systemem.

##### Restrict

Niektóre zadania automatyczne, takie jak zdalna kopia zapasowa całego systemu, wymagają pełnego dostępu root. Aby umożliwić to bezpiecznie zamiast wyłączać logowanie root przez SSH, można ograniczyć logowanie root do wybranych poleceń. Można to osiągnąć, edytując `~root/.ssh/authorized_keys` i poprzedzając żądany klucz, np.:

    command="rrsync -ro /" ssh-ed25519 ...

Umożliwi to każdemu użytkownikowi z tym kluczem wykonanie tylko polecenia w cudzysłowie

Zwiększoną powierzchnię ataku z ujawnieniem nazwy użytkownika root można ograniczyć, dodając do `sshd_config`:

    PermitRootLogin forced-commands-only

To ustawienie nie tylko ograniczy polecenia, które użytkownik root może wykonywać za pośrednictwem protokołu SSH, ale także wyłączy używanie haseł, wymuszając użycie uwierzytelniania za pomocą klucza publicznego dla konta root.

Nieco mniej restrykcyjna alternatywa pozwoli na dowolne polecenie dla użytkownika root, ale uniemożliwi ataki siłowe poprzez wymuszenie uwierzytelniania kluczem publicznym. W przypadku tej opcji należy ustawić:

    PermitRootLogin prohibit-password

#### Blokowanie pliku authorized_keys

Warning Zablokowanie tego pliku chroni jedynie przed błędami użytkownika i przed konkretnym atakiem fizycznym. Nie zapewnia ochrony przed złośliwymi programami ani włamaniami. Użyj uwierzytelniania wieloskładnikowego, zapory sieciowej i ochrony warstwowej, aby zapobiegać włamaniom od początku.

Jeżeli z jakiegoś powodu uważasz, że dany użytkownik nie powinien mieć możliwości dodawania lub zmieniania istniejących kluczy, możesz uniemożliwić mu manipulowanie plikiem.

Na serwerze ustaw plik `authorized_keys` jako tylko do odczytu dla użytkownika i zablokuj wszystkie inne uprawnienia:

    $ chmod 400 ~/.ssh/authorized_keys

Aby uniemożliwić użytkownikowi zmianę uprawnień, set the immutable bit na pliku `authorized_keys`. Aby uniemożliwić zmianę nazwy katalogu `~/.ssh` i utworzenie nowego katalogu `~/.ssh` oraz pliku `authorized_keys`, ustaw atrybut immutable również na katalogu `~/.ssh`. Aby dodać lub usunąć klucze, musisz tymczasowo usunąć atrybut immutable z pliku `authorized_keys` i przyznać uprawnienia zapisu.

Tip Zaleca się rejestrowanie zmian w dowolnym pliku `authorized_keys` np. za pomocą auditd.

#### Certyfikaty SSH

Chociaż zwykłe klucze SSH i ręczna weryfikacja fingerprinti mogą być łatwe w użyciu w przypadku niewielkiej liczby hostów zarządzanych przez jednego administratora, ta metoda uwierzytelniania w żaden sposób się nie skaluje. Gdy wielu serwerów musi być dostępnych dla kilku użytkowników przez SSH, ręczna weryfikacja fingerprinti kluczy publicznych SSH każdego hosta staje się niemal niemożliwa do przeprowadzenia w sposób bezpieczny i niezawodny.

Rozwiązaniem jest użycie certyfikatów SSH, które zapewniają automatyczną weryfikację tożsamości klucza publicznego poprzez łańcuch zaufania, znacznie lepiej skalujący się niż domyślne podejście SSH oparte na TOFU (trust-on-first-use). Certyfikaty SSH to zwykłe klucze publiczne SSH z dodatkowym podpisem od zaufanego urzędu certyfikacji (CA), który weryfikuje tożsamość klucza.

##### Utwórz klucz urzędu certyfikacji hosta dla swojej infrastruktury

    $ ssh-keygen -t ed25519 -f ~/.ssh/ca_host_key -C 'Host certificate authority for *.example.com'

Prywatny klucz urzędu certyfikacji powinien być przechowywany bezpiecznie, najlepiej na karcie inteligentnej lub tokenie sprzętowym, który uniemożliwia wyodrębnienie klucza, np. Nitrokey lub YubiKey.

##### Podpisz publiczny klucz hosta SSH serwera

Skopiuj klucz serwera publicznego do lokalnego systemu zawierającego klucz prywatny urzędu certyfikacji, aby go podpisać:

    $ ssh-keygen -h -s ~/.ssh/ca_key -I certLabel -n server01.example.com ./ssh_host_ed25519_key.pub

##### Przenieś nowy certyfikat i skonfiguruj sshd, aby go używać

Wygenerowany certyfikat `ssh_host_ed25519_key-cert.pub` należy skopiować na serwer w katalogu `/etc/ssh/`.

    /etc/ssh/sshd_config.d/20-ed25519_key.conf

    HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub

##### Skonfiguruj wszystkich klientów tak, aby ufali urzędowi certyfikacji

    ~/.ssh/known_hosts

    @cert-authority  *.example.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKL8gB/pjuff005YNazwMCqJpgsXAbQ3r4VStd/CRKwU Host certificate authority for *.example.com

Warning Jeśli serwer nie dostarczy certyfikatu do identyfikacji, domyślnie jako rozwiązanie awaryjne używane jest uwierzytelnianie za pomocą klucza publicznego.

##### Certyfikaty użytkownika SSH

W zależności od liczby użytkowników i metody wdrożenia, klucze użytkownika SSH mogą być również używane z certyfikatami. W przypadku organizacji z wieloma użytkownikami SSH zdecydowanie zaleca się bezpieczne zarządzanie wdrażaniem kluczy użytkownika.

Wdrażanie certyfikatów użytkowników działa zasadniczo tak samo, jak w przypadku tożsamości serwerów. Więcej szczegółów i instrukcji można znaleźć w Wikibooks:OpenSSH/Cookbook/Certificate-based Authentication.

##### Automatyzacja wdrażania certyfikatów

Automatyczne wdrażanie certyfikatów SSH można zapewnić za pomocą wielu narzędzi open source. Popularne przykłady to:

- Ansible - openssh_cert module
- privacyIDEA - authentication server
- Theo App - authorized keys manager

#### SSHFP record

Rekord odcisku palca Secure Shell (SSHFP) to opcjonalny rekord zasobu DNS, który przypisuje klucze SSH do nazwy hosta. Może być używany do weryfikacji odcisku palca SSH na serwerach publicznych za pomocą DNSSEC zamiast wdrażania zaufanych certyfikatów CA, co pozwala nawet niezarządzanym klientom na weryfikację ważności odcisków kluczy.

##### Wygeneruj wpis rekordu

Aby wygenerować wymagany szesnastkowy odcisk klucza do umieszczenia w rekordzie DNS, wygeneruj hash na serwerze docelowym.

    $ ssh-keygen -r host.example.com

Spowoduje to odczytanie wszystkich dostępnych kluczy SSH dla określonej domeny i wygenerowanie prawidłowych rekordów SSHFP, które można następnie zapisać we wpisach DNS danej domeny.

##### Konfiguracja klienta

Aby automatycznie pobierać i ufać odciskom kluczy SSH w rekordach SSHFP, dodaj to do pliku konfiguracji SSH:

    ~/.ssh/config

    # global options
    Match all
        VerifyHostKeyDNS yes

Jeśli host docelowy ma prawidłowy rekord SSHFP zweryfikowany prawidłowym podpisem DNSSEC, fingerprint zostaje automatycznie zaakceptowany bez pytania użytkownika o weryfikację tożsamości hosta. W przypadku braku weryfikacji DNSSEC rekordu DNS użytkownik zostaje poproszony o weryfikację fingerprintu w zwykły sposób.

Note For SSHFP records to work, make sure that `trust-ad` option is set in `/etc/resolv.conf`.

##### Generuj rekordy SSHFP

Aby ustalić fingerprint SSH konkretnej domeny, użyj polecenia ssh-keyscan do pobrania fingerprintów SSH w prawidłowym formacie rekordu DNS. (Domyślnie odciski palców dla każdego dostępnego typu klucza są podawane zarówno w SHA1 jak i SHA256.)

    $ ssh-keyscan -D github.com

    ; github.com:22 SSH-2.0-babeld-57ca1323
    ; github.com:22 SSH-2.0-babeld-57ca1323
    github.com IN SSHFP 1 1 6f4c60375018bae0918e37d9162bc15ba40e6365
    github.com IN SSHFP 1 2 b8d895ced92c0ac0e171cd2ef5ef01ba3417554a4a6480d331ccc2be3ded0f6b
    ; github.com:22 SSH-2.0-babeld-57ca1323
    github.com IN SSHFP 3 1 3358ab5dd3e306c461c840f7487e93b697e30600
    github.com IN SSHFP 3 2 a764003173480b54c96167883adb6b55cf7cfd1d415055aedff2e2c8a8147d03
    ; github.com:22 SSH-2.0-babeld-57ca1323
    github.com IN SSHFP 4 1 e9619e2ed56c2f2a71729db80bacc2ce9ccce8d4
    github.com IN SSHFP 4 2 f83898df0bef57a4ee24985ba598ac17fccb0c0d333cc4af1dd92be14bc23aa5
    ; github.com:22 SSH-2.0-babeld-57ca1323

Ponieważ rekord SSHFP przechowuje odciski kluczy w formacie heksadecymalnym, a typowe dane wyjściowe odcisków SSH to skrót SHA256 klucza publicznego zakodowany w base64, konieczna jest konwersja rekordu do formatu base64 w celu porównania go z wartościami w pliku known_hosts lub inną dokumentacją, która zwykle przechowuje odciski w formacie SHA256 base64.

    $ echo "SSHFP-fingerprint" | xxd -r -p | base64

Przykład dla github.com wykorzystujący wartość szesnastkową odcisku palca sha256 klucza ed25519

    $ echo "f83898df0bef57a4ee24985ba598ac17fccb0c0d333cc4af1dd92be14bc23aa5" | xxd -r -p | base64

    +DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU=

Porównaj z wpisami known_hosts:

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

##### Ręczne pobieranie rekordów SSHFP z DNS

    $ dig SSHFP targetdomain.tld +short

## Porady i wskazówki

### Szyfrowany tunel SOCKS

Może to być przydatne dla użytkowników laptopów podłączonych do niebezpiecznych sieci bezprzewodowych. Wymogiem jest serwer SSH działający w bezpiecznym miejscu, takim jak dom lub miejsce pracy. Zalecane jest użycie dynamicznej usługi DNS, na przykład DynDNS, aby nie trzeba było pamiętać adresu IP.

#### Rozpocznij połączenie

    $ ssh -TND 4711 user@host

Flaga `N` wyłącza interaktywny monit, a flaga `D` określa lokalny port, na którym nasłuchiwać (możesz wybrać dowolny numer portu). Flaga `T` wyłącza alokację pseudo-tty.

Można dodać flagę verbose (`-v`), aby zweryfikować połączenie.

#### Skonfiguruj swoją przeglądarkę (lub inne programy)

Powyższy krok jest przydatny tylko w połączeniu z przeglądarką lub innym programem. Ponieważ SSH obsługuje zarówno SOCKS v4, jak i SOCKS v5, możesz skonfigurować jeden z nich.

- For Firefox:

1. Go to Preferences > General > Network Settings and click on Settings....
2. In the new window, check the Manual proxy configuration option and enter `localhost` in the SOCKS host text field, and the port number in the Port text field (`4711` in the example above).
3. Restart Firefox.

  Note Firefox nie wysyła automatycznie żądań DNS przez tunel SOCKS. Można temu zapobiec, sprawdzając opcję „Serwer proxy DNS podczas korzystania z SOCKS vN” (wersja 4 lub 5).

- Dla Chromium:

1. Możesz ustawić ustawienia SOCKS jako zmienne środowiskowe lub opcje wiersza poleceń. Na przykład, dodaj jedną z następujących funkcji do swojego `.bashrc`:

       secure_chromium() {
           local port=4711
           export SOCKS_SERVER=localhost:$port
           export SOCKS_VERSION=5
           (chromium > /dev/null 2>&1 &)
       }

       secure_chromium() {
           local port=4711
           (chromium --proxy-server="socks://localhost:$port" > /dev/null 2>&1 &)
       }

2. Otwórz terminal i uruchom:

       $ secure_chromium

#### Skonfiguruj lokalny interfejs TUN

Początkowo wymaga to bardziej zaawansowanej konfiguracji, ale pozwala uniknąć konieczności ręcznego konfigurowania każdej aplikacji do użycia proxy SOCKS. Wymaga to skonfigurowania lokalnego interfejsu TUN i routowania ruchu przez niego.

Zobacz VPN over SSH#Set up badvpn and tunnel interface.

### Przekierowanie X11

Przekierowanie X11 to mechanizm umożliwiający wyświetlanie graficznych interfejsów programów X11 działających w systemie zdalnym na lokalnym komputerze klienckim. Do przekierowania X11 zdalny host nie musi mieć zainstalowanego pełnego systemu X11, jednak musi mieć zainstalowany co najmniej xauth. xauth to narzędzie, które zarządza konfiguracją `Xauthority` używaną przez serwer i klient do uwierzytelniania sesji X11 (źródło).

Warning Przekierowanie X11 ma istotne implikacje bezpieczeństwa, które powinny być co najmniej uwzględnione poprzez zapoznanie się z istotnymi sekcjami podręczników ssh(1), sshd_config(5) i ssh_config(5). Zobacz również to pytanie na StackExchange.

#### Setup

##### Zdalny

- zainstaluj pakiety xorg-xauth
- w `/etc/ssh/sshd_config`:
  - ustaw `X11Forwarding` na yes
  - sprawdź, czy opcje `AllowTcpForwarding` i `X11UseLocalhost` są ustawione na tak i czy `X11DisplayOffset` jest ustawione na 10 (są to wartości domyślne, jeśli nic nie zostało zmienione, zobacz sshd_config(5))
- następnie uruchom ponownie sshd daemon.

##### Klient

- zainstaluj pakiety xorg-xauth
- enable the `ForwardX11` option by either specifying the `-X` switch on the command line for opportunistic connections, or by setting `ForwardX11` to yes in the client's configuration.

Tip You can enable the `ForwardX11Trusted` option (`-Y` switch on the command line) if GUI is drawing badly or you receive errors; this will prevent X11 forwardings from being subjected to the X11 SECURITY extension controls. Be sure you have read the warning at the beginning of this section if you do so.

#### Używanie

Zaloguj się do maszyny zdalnej, podając przełącznik `-X`, jeśli `ForwardX11` nie został włączony w pliku konfiguracyjnym klienta:

    $ ssh -X user@host

Jeśli otrzymasz błędy przy uruchamianiu aplikacji graficznych, spróbuj zamiast tego ForwardX11Trusted:

    $ ssh -Y user@host

Jeśli otrzymasz wynik `X11 forwarding request failed`, powtórz konfigurację na maszynie zdalnej. Po pomyślnym wykonaniu żądania przekierowania X11 możesz uruchomić dowolny program X na serwerze zdalnym, a zostanie on przekierowany do sesji lokalnej:

    $ xclock

Komunikat błędu `Can't open display` wskazuje, że `DISPLAY` jest źle ustawione.

Należy uważać na niektóre aplikacje, które sprawdzają, czy na lokalnym komputerze istnieje uruchomiona instancja. Przykładem jest Firefox: zamknij uruchomioną instancję lub użyj następującego parametru uruchomienia, aby uruchomić drugą instancję na lokalnym komputerze:

    $ firefox --no-remote

Jeśli podczas łączenia pojawia się błąd „X11 forwarding request failed on channel 0" (a serwer wyświetla w `/var/log/errors.log` komunikat „Failed to allocate internet-domain X11 display socket"), upewnij się, że pakiet xorg-xauth jest zainstalowany. Jeśli instalacja nie powiedzie się, spróbuj jednej z poniższych opcji:

- włącz opcję `AddressFamily any` w `sshd_config` na serwerze lub
- Ustaw opcję `AddressFamily` w pliku `sshd_config` na serwerze na inet.

Ustawienie jej na inet może rozwiązać problemy z klientami Ubuntu na IPv4.

Aby uruchomić aplikacje X jako inny użytkownik na serwerze SSH, należy za pomocą `xauth add` dodać linię uwierzytelniania pobraną z wyniku `xauth list` zalogowanego użytkownika SSH.

Tip Here are some useful links for troubleshooting `X11 Forwarding` issues.

### Przekierowywanie innych portów

Oprócz wbudowanej obsługi X11, SSH można również użyć do bezpiecznego tunelowania dowolnego połączenia TCP za pomocą lokalnego lub zdalnego przekierowania portów.

Przekierowanie lokalne otwiera port na maszynie lokalnej, do którego połączenia są przekierowywane do hosta zdalnego, a następnie do określonego celu. Najczęściej cel przekierowania jest taki sam jak host zdalny, zapewniając bezpieczną powłokę i, np. bezpieczne połączenie VNC do tej samej maszyny. Przekierowanie lokalne realizuje się przełącznikiem `-L` ze specyfikacją `<tunnel port>:<destination address>:<destination port>`.

Thus:

    $ ssh -L 1000:mail.google.com:25 192.168.0.100

Użyje protokołu SSH do zalogowania się i otwarcia powłoki na maszynie `192.168.0.100`, a także utworzy tunel z portu TCP 1000 maszyny lokalnej do mail.google.com na porcie 25. Po nawiązaniu połączenia, połączenia do `localhost:1000` będą łączyć się z portem SMTP Gmaila. Google będzie uważać, że każde takie połączenie (choć niekoniecznie przesyłane przez nie dane) pochodzi z `192.168.0.100`, a dane będą bezpieczne między maszyną lokalną a maszyną 192.168.0.100, ale nie między `192.168.0.100` a Google, chyba że zastosowane będą dodatkowe środki.

Podobnie:

    $ ssh -L 2000:192.168.0.100:6001 192.168.0.100

umożliwi połączenia do `localhost:2000`, które będą transparentnie przesyłane do zdalnego hosta na porcie 6001. Przykład ten jest przydatny dla połączeń VNC przy użyciu narzędzia vncserver — części pakietu tightvnc — które, choć bardzo przydatne, nie gwarantuje bezpieczeństwa.

Zdalne przekierowywanie pozwala zdalnemu hostowi połączyć się poprzez tunel SSH z dowolnym hostem za pośrednictwem maszyny lokalnej, stanowiąc odwrócenie lokalnego przekierowywania. Jest przydatne w sytuacjach, gdy zdalny host ma ograniczoną łączność z powodu zapory. Włącza się je przełącznikiem `-R` i specyfikacją przekierowywania w postaci `<tunnel port>:<destination address>:<destination port>`.

Zatem:

    $ ssh -R 3000:irc.libera.chat:6667 192.168.0.200

otworzy powłokę na `192.168.0.200`, a połączenia z `192.168.0.200` na porcie 3000 (`localhost:3000` zdalnego hosta) będą przekierowywane przez tunel do maszyny lokalnej, a następnie do irc.libera.chat na porcie 6667. W tym przykładzie umożliwia to używanie programów IRC na zdalnym hoście, nawet jeśli port 6667 byłby normalnie dla niego zablokowany.

Zarówno lokalne, jak i zdalne przekierowywanie może być używane do zapewnienia bezpiecznej „bramy", umożliwiając innym komputerom korzystanie z tunelu SSH bez faktycznego uruchamiania SSH lub serwera SSH poprzez podanie adresu powiązania dla początku tunelu jako części specyfikacji przekierowywania, np. `<tunnel address>:<tunnel port>:<destination address>:<destination port>`. `<tunnel address>` może być dowolnym adresem na maszynie na początku tunelu. Adres `localhost` zezwala na połączenia przez `localhost` lub interfejs loopback, a pusty adres lub `*` zezwala na połączenia przez dowolny interfejs. Domyślnie przekierowywanie jest ograniczone do połączeń z maszyny na „początku" tunelu, tj. `<tunnel address>` jest ustawione na `localhost`. Lokalne przekierowywanie nie wymaga dodatkowej konfiguracji; jednak zdalne przekierowywanie jest ograniczone przez konfigurację serwera SSH na zdalnej maszynie. Szczegóły znajdują się w opcji `GatewayPorts` w sshd_config(5) oraz opcji `-L` w ssh(1).

### Jump hosts

W pewnych scenariuszach może nie być bezpośredniego połączenia z docelowym demonem SSH i wymagane jest użycie jump servera (lub bastion hosta). W związku z tym próbujemy połączyć dwa lub więcej tuneli SSH, zakładając, że klucze lokalne są autoryzowane na każdym serwerze w łańcuchu. Jest to możliwe dzięki przekierowaniu agenta SSH (`-A`) i alokacji pseudo-terminala (`-t`), które umożliwiają przekazanie klucza lokalnego za pomocą następującej składni:

    $ ssh -A -t -l user1 bastion1 \
      ssh -A -t -l user2 intermediate2 \
      ssh -A -t -l user3 target

Można to zautomatyzować za pomocą opcji ProxyCommand:

    $ ssh -o ProxyCommand="ssh -W %h:%p bastion.example.org" targetserver.example.org

Łatwiejszym i bezpieczniejszym sposobem wykonania tego zadania jest użycie opcji ProxyJump z flagą `-J`:

    $ ssh -J user1@bastion1,user2@intermediate2 user3@target

W dyrektywie `-J` wiele hostów można rozdzielić przecinkiem; będą podłączane w podanej kolejności. Część `user...@` jest opcjonalna, ale może być użyta. Specyfikacje hostów dla `-J` korzystają z pliku konfiguracyjnego ssh, więc w razie potrzeby można tam ustawić opcje dla każdego hosta.

Główną różnicą między opcjami ProxyCommand i ProxyJump jest to, że ProxyJump nie wymaga powłoki systemowej na jump hoście. W konsekwencji serwer jump host nie wymaga dostępu do danych logowania użytkownika ani przekazywania agenta SSH. Dzięki opcji ProxyJump klient SSH łączy się bezpośrednio przez jump host z serwerem docelowym, ustalając zaszyfrowany kanał end-to-end między klientem a serwerem docelowym.

Odpowiednikiem flagi `-J` w pliku konfiguracyjnym jest opcja `ProxyJump`; szczegóły można znaleźć w ssh_config(5).

### Odwrotny SSH przez przekaźnik

This article or section needs language, wiki syntax or style improvements. See Help:Style for reference.

Reason: The idea of SSH tunneling is classic, so some references for detailed explanation would be nice. E.g. [2] which includes other scenarios. (Discuss in Talk:OpenSSH (Polski))

Koncepcja: klient łączy się z serwerem poprzez przekaźnik, a serwer połączony jest z tym samym przekaźnikiem odwrotnym tunelem SSH. Jest to przydatne, gdy serwer znajduje się za NAT-em, a przekaźnik to publicznie dostępny serwer SSH. Warunkami wstępnymi są: klucze klienta autoryzowane na przekaźniku i serwerze, oraz klucze serwera autoryzowane na przekaźniku dla odwrotnego tunelu SSH

Poniższy przykład konfiguracji zakłada, że `user1` to konto użytkownika na kliencie, `user2` na przekaźniku i `user3` na serwerze. Zakładając użycie portu 2222, serwer musi ustanowić tunel odwrotny za pomocą:

    $ ssh -R 2222:localhost:22 -N user2@relay

Which can also be automated with a startup script, systemd service, autossh or sidedoorAUR.

Po stronie klienta połączenie nawiązywane jest za pomocą:

    $ ssh -t user2@relay ssh user3@localhost -p 2222

Note `ssh user3@relay -p 2222` wymagałoby otwarcia tego portu w zaporze serwera relay, a także zezwolenia na połączenia do tego portu z innych adresów.

Zdalne polecenie do ustanowienia połączenia tunelu odwrotnego można również zdefiniować w pliku `authorized_keys` serwera pośredniczącego, uwzględniając pole `command` w następujący sposób:

    ~/.ssh/authorized_keys

    command="ssh user3@localhost -p 2222" ssh-ed25519 KEY2 user1@client

W tym przypadku połączenie jest nawiązywane za pomocą:

    $ ssh user2@relay

Alternatywnie możesz dodać wpis do konfiguracji SSH, który określa zarówno `RemoteCommand`, jak i `RequestTTY`:

    ~/.ssh/config

    Host jump-destination
        Hostname relay
        User user2
        RemoteCommand ssh user3@localhost -p 2222
        RequestTTY yes

Co zmniejszy liczbę połączeń z:

    $ ssh jump-destination

Note Funkcja autouzupełniania SCP w terminalu klienta nie będzie działać. Nawet same transfery SCP nie będą działać w niektórych konfiguracjach.

### Multiplexing

Demon SSH zazwyczaj nasłuchuje portu 22. Jednak powszechną praktyką wielu publicznych sieci Wi-Fi jest blokowanie całego ruchu na portach innych niż standardowe HTTP/S (odpowiednio 80 i 443), co w praktyce blokuje połączenia SSH. Rozwiązaniem jest skonfigurowanie `sshd` do nasłuchiwania dodatkowo na jednym z portów dozwolonych:

    /etc/ssh/sshd_config

    Port 22
    Port 443

Jednak port 443 jest prawdopodobnie już używany przez serwer web udostępniający zawartość HTTPS. W takim przypadku można użyć multipleksera, takiego jak sslh, który nasłuchuje na porcie multipleksera i może kierować pakiety do wielu usług.

### Przyspieszanie SSH

This article or section needs expansion.

Reason: Changing cipher from default might introduce security implications and must be noted here if applicable (Discuss in Talk:OpenSSH#Trading_security_for_performance?)

Istnieje kilka opcji client configuration, które mogą przyspieszyć połączenia globalnie lub dla określonych hostów. Pełny opis tych opcji można znaleźć w ssh_config(5).

- Użyj szybszego szyfru: na nowoczesnych procesorach z instrukcjami AESNI, `aes128-gcm@openssh.com` i `aes256-gcm@openssh.com` powinny zapewniać znacznie lepszą wydajność od domyślnego szyfru openssh, zwykle `chacha20-poly1305@openssh.com`. Szyfr można wybrać flagą `-c`. Aby uzyskać efekt trwały, umieść opcję `Ciphers` w `~/.ssh/config` z szyframi w żądanej kolejności, np.:

      Ciphers aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

- Włączanie i wyłączanie kompresji kompresja może zwiększyć prędkość na wolnych połączeniach; włącza się za pomocą opcji `Compression yes` lub flagi `-C`. Jednak używany algorytm kompresji to stosunkowo wolny gzip(1), który stanowi wąskie gardło w szybkich sieciach. Aby przyspieszyć połączenie, należy wyłączyć kompresję za pomocą opcji `Compression no` w sieciach lokalnych i szybkich.

- „Udostępnianie połączenia": możesz sprawić, że wszystkie sesje do tego samego hosta współdzielą jedno połączenie, używając poniższych opcji:

      ControlMaster auto
      ControlPersist yes
      ControlPath ~/.ssh/sockets/socket-%r@%h:%p

  gdzie `~/.ssh/sockets` może być dowolnym katalogiem, do którego inni użytkownicy nie mają prawa zapisu.

- `ControlPersist` określa, jak długo master powinien czekać w tle na nowych klientów po zamknięciu początkowego połączenia. Możliwe wartości to:
  - `no`, aby natychmiast zamknąć połączenie po rozłączeniu się ostatniego klienta,
  - czas w sekundach,
  - `yes` aby czekać w nieskończoność, połączenie nigdy nie zostanie zamknięte automatycznie.

- Czas logowania można skrócić poprzez pominięcie wyszukiwania IPv6 za pomocą opcji `AddressFamily inet` lub flagi `-4`.

- Na koniec, jeśli zamierzasz używać SSH do SFTP lub SCP, High Performance SSH/SCP może znacząco zwiększyć przepustowość poprzez dynamiczne zwiększanie rozmiarów buforów SSH. Zainstaluj pakiet openssh-hpnAUR, aby korzystać z poprawionej wersji OpenSSH z tym ulepszeniem.

### Montowanie zdalnego systemu plików za pomocą SSHFS

Zapoznaj się z artykułem SSHFS, aby zamontować zdalny system dostępny przez SSH w katalogu lokalnym. Umożliwi Ci to wykonywanie dowolnych operacji na zamontowanych plikach za pomocą dowolnego narzędzia (kopiowanie, zmiana nazwy, edycja za pomocą vim itd.). sshfs jest generalnie preferowany w stosunku do shfs, które nie było aktualizowane od 2004 roku.

### Keep alive

Domyślnie sesja SSH automatycznie się wylogowuje po upływie określonego czasu braku aktywności. Aby podtrzymać sesję, klient może wysłać do serwera sygnał keep-alive, jeśli przez pewien czas nie odebrano danych, lub serwer może wysyłać komunikaty w regularnych odstępach, jeśli nie otrzyma danych od klienta.

- Po stronie serwera `ClientAliveInterval` ustawia limit czasu w sekundach, po którym, jeśli serwer nie otrzyma żadnych danych od klienta, sshd wyśle żądanie odpowiedzi. Wartość domyślna to 0 (komunikat nie jest wysyłany). Na przykład, aby żądać odpowiedzi od klienta co 60 sekund, ustaw opcję `ClientAliveInterval 60` w konfiguracji serwera. Patrz też opcje `ClientAliveCountMax` i `TCPKeepAlive`.
- Po stronie klienta, `ServerAliveInterval` określa interwał wysyłania żądań o potwierdzenie z klienta do serwera. Na przykład, aby wysyłać potwierdzenie co 120 sekund, dodaj opcję `ServerAliveInterval 120` do client configuration. Patrz również: `ServerAliveCountMax` i `TCPKeepAlive`.

Note Aby zapewnić utrzymanie sesji, tylko jeden z nich — klient lub serwer — musi wysyłać żądania podtrzymania. Jeśli kontrolujesz zarówno serwery, jak i klientów, rozsądnym rozwiązaniem jest skonfigurowanie tylko klientów wymagających stałej sesji z dodatnim parametrem `ServerAliveInterval`, a pozostałe klienty i serwery pozostawić w konfiguracji domyślnej.

### Automatyczne ponowne uruchamianie tuneli SSH za pomocą systemd

systemd może automatycznie nawiązywać połączenia SSH podczas rozruchu/logowania i restartować je w przypadku zerwania. Dzięki temu jest to przydatne narzędzie do obsługi tuneli SSH.

Poniższa usługa może uruchomić tunel SSH po zalogowaniu, korzystając z ustawień połączenia w #Configuration ssh configuration. Jeśli połączenie zostanie zamknięte z jakiegokolwiek powodu, odczeka 10 sekund przed ponownym uruchomieniem:

    ~/.config/systemd/user/tunnel.service

    [Unit]
    Description=SSH tunnel to myserver

    [Service]
    Type=simple
    Restart=always
    RestartSec=10
    ExecStart=/usr/bin/ssh -F %h/.ssh/config -N myserver

Następnie enable i start user unit. Zobacz #Keep alive, aby dowiedzieć się, jak zapobiec przekroczeniu limitu czasu tunelu. Jeśli chcesz uruchomić tunel podczas rozruchu, możesz [systemd#Writing unit files|rewrite the unit]] jako usługę systemową.

### Autossh – automatycznie restartuje sesje i tunele SSH

Jeśli nie można utrzymać sesji lub tunelu, na przykład z powodu złych warunków sieciowych powodujących rozłączenia klientów, można użyć autossh, aby automatycznie je ponownie uruchomić.

Przykłady użycia:

    $ autossh -M 0 -o "ServerAliveInterval 45" -o "ServerAliveCountMax 2" username@example.com

W połączeniu z SSHFS:

    $ sshfs -o reconnect,compression=yes,transform_symlinks,ServerAliveInterval=45,ServerAliveCountMax=2,ssh_command='autossh -M 0' username@example.com: /mnt/example

Łączenie przez proxy SOCKS ustawione w Proxy settings:

    $ autossh -M 0 -o "ServerAliveInterval 45" -o "ServerAliveCountMax 2" -NCD 8080 username@example.com

Za pomocą opcji `-f` można uruchomić autossh jako proces w tle. Jednak uruchomienie go w ten sposób oznacza, że ​​nie można wprowadzić hasła interaktywnie.

Sesja zakończy się w momencie wpisania polecenia `exit` lub gdy proces autossh otrzyma sygnał SIGTERM, SIGINT lub SIGKILL.

#### Uruchom autossh automatycznie podczas rozruchu za pomocą systemd

Jeśli chcesz automatycznie uruchamiać autossh, możesz utworzyć plik jednostki systemd:

    /etc/systemd/system/autossh.service

    [Unit]
    Description=AutoSSH service for port 2222
    After=network.target

    [Service]
    Environment="AUTOSSH_GATETIME=0"
    ExecStart=/usr/bin/autossh -M 0 -NL 2222:localhost:2222 -o TCPKeepAlive=yes foo@bar.com

    [Install]
    WantedBy=multi-user.target

Tutaj `AUTOSSH_GATETIME=0` to zmienna środowiskowa określająca, jak długo ssh musi być aktywne, zanim autossh uzna połączenie za udane. Ustawienie jej na 0 powoduje, że autossh ignoruje również błąd pierwszego uruchomienia ssh. Może to być przydatne przy starcie systemu. Inne zmienne środowiskowe dostępne są w autossh(1). W razie potrzeby można tę jednostkę bardziej skomplikować (szczegóły w dokumentacji systemd), a także użyć własnych opcji dla autossh. Należy jednak pamiętać, że opcja `-f` wraz z `AUTOSSH_GATETIME=0` nie działa z systemd.

Pamiętaj, aby później start i/lub enable usługę.

Może być również konieczne wyłączenie `ControlMaster`:

    ExecStart=/usr/bin/autossh -M 0 -o ControlMaster=no -NL 2222:localhost:2222 -o TCPKeepAlive=yes foo@bar.com

Tip Łatwo jest również utrzymywać kilka procesów autossh, aby utrzymać kilka tuneli aktywnych. Wystarczy utworzyć wiele plików usług o różnych nazwach.

### Usługa alternatywna na wypadek awarii demona SSH

W przypadku serwerów zdalnych lub bezobsługowych, które polegają wyłącznie na protokole SSH, niepowodzenie uruchomienia demona SSH (np. po uaktualnieniu systemu) może uniemożliwić dostęp administracyjny. systemd oferuje proste rozwiązanie za pomocą opcji `OnFailure`.

Załóż, że serwer uruchamia `sshd`, a telnet jest rozwiązaniem awaryjnym. Utwórz następujący plik. Nie enable `telnet.socket`!**

    /etc/systemd/system/sshd.service.d/override.conf

    [Unit]
    OnFailure=telnet.socket

To wszystko. Telnet jest niedostępny, gdy uruchomiony jest `sshd`. Jeśli `sshd` nie uruchomi się, można otworzyć sesję telnet w celu odzyskania połączenia.

### Kolor tła terminala w zależności od hosta

Aby lepiej rozróżniać, kiedy znajdujesz się na różnych hostach, możesz ustawić inny kolor tła w zależności od rodzaju hosta.

To rozwiązanie działa, ale nie jest uniwersalne (tylko ZSH).

### Konfiguracja specyficzna dla sieci

Możesz użyć konfiguracji hosta specyficznej dla sieci, do której jesteś podłączony, używając polecenia `Match exec`.

Na przykład, gdy używane jest nmcli(1), a połączenie jest skonfigurowane (ręcznie lub przez DHCP) z domeną wyszukiwania:

    ~/.ssh/config

    Match exec "nmcli | grep domains: | grep example.com"
      CanonicalDomains example.com
      # Should you use a different username on this network
      #User username
      # Use a different known_hosts file (for private network or synchronisation)
      #UserKnownHostsFile <network>_known_hosts

Inny przykład dla `Match host ... exec "..."`: Weź pod uwagę, że połączenie z `internal.example.com` wymaga bastion/proxy (przez `ProxyJump`), chyba że jesteś już połączony przez VPN. Fragment `!exec "host internal.example.com"` ma zastosowanie tylko wtedy, gdy `internal.example.com` nie da się rozwiązać przez DNS. Różne alternatywy omówiono w [3].

    ~/.ssh/config

    Match host internal.example.com !exec "host internal.example.com"
      ProxyJump bastion.example.com
    Host internal.example.com
      User foobar

### Weryfikacja kluczy hosta sieci prywatnych

Ponieważ różne serwery w różnych sieciach prawdopodobnie korzystają ze wspólnego prywatnego adresu IP, możesz chcieć je obsłużyć w różny sposób.

The factual accuracy of this article or section is disputed.

Reason: Najlepszym rozwiązaniem byłoby takie, które nie wymagałoby ostrzeżenia o użyciu czegoś innego w praktyce. (Discuss in Talk:OpenSSH (Polski))

Najlepszym rozwiązaniem jest użycie #Network specific configuration, aby używać innego pliku `UserKnownHostsFile` w zależności od sieci. Drugim rozwiązaniem, zalecane jako domyślne podczas pracy w nowych/prototypowych sieciach, jest po prostu ignorowanie hostkeys w sieciach prywatnych:

    ~/.ssh/config

    Host 10.* 192.168.*.* 172.31.* 172.30.* 172.2?.* 172.1?.*
        # Disable HostKey verification
        # Trust HostKey automatically
        StrictHostKeyChecking no
        # Do not save the HostKey
        UserKnownHostsFile=/dev/null
        # Do not display: "Warning: Permanently Added ..."
        LogLevel Error

The factual accuracy of this article or section is disputed.

Reason: Plik `known_hosts` rejestruje adres IP nawet wtedy, gdy do uzyskania dostępu do serwera używasz nazwy hosta. (Discuss in Talk:OpenSSH (Polski))
Warning W środowisku produkcyjnym należy upewnić się, że dostęp do hosta odbywa się za pomocą nazwy hosta i/lub że używane są specyficzne dla sieci pliki known_hosts.

### Uruchom polecenie podczas logowania

Jeśli używasz sesji interaktywnej, istnieje kilka sposobów wykonania polecenia po zalogowaniu:

- użyj pliku `authorized_keys` na zdalnym hoście (zobacz sshd(8) § AUTHORIZED_KEYS FILE FORMAT)
- użyj `~/.ssh/rc` na zdalnym hoście, jeśli serwer włączył opcję `PermitUserRC`
- użyj pliku konfiguracyjnego powłoki na zdalnym hoście, np. `.bashrc`

### Przekierowanie agenta

Przekierowanie agenta SSH pozwala na korzystanie z kluczy lokalnych po połączeniu z serwerem. Zaleca się [4] włączenie przekierowania agenta tylko dla wybranych hostów.

    ~/.ssh/config

    Host myserver.com
        ForwardAgent yes

Następnie skonfiguruj SSH agent i dodaj klucz lokalny za pomocą polecenia ssh-add.

Jeśli teraz połączysz się ze zdalnym serwerem, będziesz mógł połączyć się z innymi usługami, korzystając z kluczy lokalnych.

### Generowanie nowych kluczy

Nowe klucze prywatne serwera można wygenerować poprzez:

1. Usuwanie wszystkich kluczy, np.:

       # rm /etc/ssh/ssh_host_*_key*

2. Restart `sshdgenkeys.service` lub uruchomienie `ssh-keygen -A` jako root.

Bardziej elegancką alternatywą jest przejście. Najpierw wygeneruj nowe klucze hosta:

    # ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key.new
    # ssh-keygen -t ecdsa -b 521 -f /etc/ssh/ssh_host_ecdsa_key.new
    # ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key.new

Dodaj stare i nowe klucze do `/etc/ssh/sshd_config.d/10-hostkeys.conf`:

    HostKey /etc/ssh/ssh_host_ecdsa_key
    HostKey /etc/ssh/ssh_host_ecdsa_key.new
    HostKey /etc/ssh/ssh_host_ed25519_key
    HostKey /etc/ssh/ssh_host_ed25519_key.new
    HostKey /etc/ssh/ssh_host_rsa_key
    HostKey /etc/ssh/ssh_host_rsa_key.new

Restart `sshd.service`.

Klienci poznają nowe odciski kluczy hosta i dodadzą je do `~/.ssh/known-hosts` przy następnym połączeniu z serwerem.

Po pewnym czasie stare klucze można usunąć z `/etc/ssh/sshd_config.d/10-hostkeys.conf`, pozostawiając jedynie nowe klucze:

    HostKey /etc/ssh/ssh_host_ecdsa_key.new
    HostKey /etc/ssh/ssh_host_ed25519_key.new
    HostKey /etc/ssh/ssh_host_rsa_key.new

Restart `sshd.service`, a następnie fizycznie usuń stare klucze:

    # rm /etc/ssh/ssh_host_{ecdsa,ed25519,rsa}_key

Klienci automatycznie zaktualizują `~/.ssh/known-hosts`, usuwając odciski palców starych kluczy.

### Uruchom sshd jako użytkownik bez uprawnień

Możesz chcieć uruchomić `sshd` jako użytkownik bez uprawnień w kontenerach lub w celach testowych itd.

Ponieważ użytkownik bez uprawnień nie może odczytać kluczy hosta w `/etc/ssh`, należy wygenerować nowe klucze hosta:

    $ ssh-keygen -q -N "" -t rsa -b 4096 -f /path/to/host/keys/ssh_host_rsa_key
    $ ssh-keygen -q -N "" -t ecdsa -f /path/to/host/keys/ssh_host_ecdsa_key
    $ ssh-keygen -q -N "" -t ed25519 -f /path/to/host/keys/ssh_host_ed25519_key

Utwórz plik `sshd_config`. Poniższy przykład używa portu wyższego niż 1024, podaje nową ścieżkę do kluczy hosta i wyłącza PAM:

    /path/to/sshd_config

    Port 2022
    HostKey /path/to/host/keys/ssh_host_rsa_key
    HostKey /path/to/host/keys/ssh_host_ecdsa_key
    HostKey /path/to/host/keys/ssh/ssh_host_ed25519_key
    UsePAM no

Uruchom „sshd” z utworzoną konfiguracją. Flaga `-D` wyłącza tryb demona, a `-e` przekierowuje wyjście do stderr, aby umożliwić łatwe monitorowanie.

    $ sshd -f /path/to/sshd_config -D -e

## Rozwiązywanie problemów

### Lista kontrolna

Sprawdź te proste kwestie zanim zaczniesz szukać dalej.

1. Katalog konfiguracyjny `~/.ssh` i jego zawartość powinny być dostępne tylko dla użytkownika (należy to sprawdzić zarówno po stronie klienta, jak i serwera), a katalog domowy użytkownika powinien być dostępny do zapisu tylko dla tego użytkownika:

       $ chmod go-w ~
       $ chmod 700 ~/.ssh
       $ chmod 600 ~/.ssh/*
       $ chown -R $USER ~/.ssh

2. Sprawdź, czy klucz publiczny klienta (np. `id_ed25519.pub`) znajduje się w `~/.ssh/authorized_keys` na serwerze.
3. Sprawdź, czy nie ograniczyłeś dostępu SSH za pomocą `AllowUsers` lub `AllowGroups` w server config.
4. Sprawdź, czy użytkownik ustawił hasło. Czasami nowi użytkownicy, którzy jeszcze nie zalogowali się na serwerze, nie mają hasła.
5. Append `LogLevel DEBUG` do `/etc/ssh/sshd_config`.
6. Uruchom `journalctl -xe` jako root, aby sprawdzić możliwe komunikaty (o błędach).
7. Restart `sshd` i wyloguj się/zaloguj zarówno na kliencie, jak i serwerze.

### Odmowa połączenia lub problem z przekroczeniem limitu czasu

#### Przekierowanie portów

Jeśli jesteś za NAT-em/routerem (co jest prawdopodobne, chyba że używasz VPS-a lub hosta z adresem publicznym), upewnij się, że router przekierowuje przychodzące połączenia SSH do Twojej maszyny. Znajdź wewnętrzny adres IP serwera za pomocą `ip addr` i skonfiguruj router do przekierowywania TCP na port SSH na ten adres IP. portforward.com może w tym pomóc.

#### Czy protokół SSH działa i nasłuchuje?

ss wyświetla wszystkie procesy nasłuchające na porcie TCP za pomocą polecenia:

    $ ss --tcp --listening

Jeśli powyższe polecenie nie pokazuje, że system nasłuchuje na porcie `ssh`, SSH nie jest uruchomiony sprawdź journal pod kątem błędów itd.

#### Czy istnieją reguły zapory sieciowej blokujące połączenie?

Iptables może blokować połączenia na porcie `22`. Sprawdź to za pomocą:

    # iptables -nvL

i poszukaj reguł, które mogą powodować odrzucanie pakietów w łańcuchu `INPUT`. Następnie, jeśli to konieczne, odblokuj port poleceniem takim jak:

    # iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT

Aby uzyskać dalszą pomoc w konfigurowaniu zapór sieciowych, zobacz firewalls.

#### Czy ruch w ogóle dociera do Twojego komputera?

Rozpocznij przechwyt ruchu na komputerze, na którym występuje problem:

    # tcpdump -lnn -i any port ssh and tcp-syn

Powinno to wyświetlić podstawowe informacje, a następnie czekać na pasujący ruch sieciowy przed jego wyświetleniem. Przetestuj połączenie. Jeśli nie widzisz żadnych danych wyjściowych podczas próby połączenia, oznacza to, że coś spoza komputera blokuje ruch (np. zapora sprzętowa, router NAT itp.).

#### Twój dostawca usług internetowych lub osoba trzecia blokuje domyślny port?

Note Wypróbuj ten krok, jeśli wiesz, że nie masz żadnych zapór sieciowych i skonfigurowałeś router w trybie DMZ lub przekierowałeś port na swój komputer, a problem nadal nie występuje. Tutaj znajdziesz instrukcje diagnostyczne i możliwe rozwiązania.

W niektórych przypadkach dostawca usług internetowych może blokować domyślny port SSH (port 22), w związku z czym wszelkie próby (otwieranie portów, hartowanie konfiguracji, obrona przed atakami flood, itp.) okazują się bezużyteczne. Aby to potwierdzić, utwórz serwer nasłuchujący na wszystkich interfejsach (0.0.0.0) i połącz się zdalnie.

Jeśli pojawi się komunikat o błędzie podobny do tego:

    ssh: connect to host www.inet.hr port 22: Connection refused

Oznacza to, że port nie jest blokowany przez dostawcę usług internetowych, ale serwer nie uruchamia protokołu SSH na tym porcie (zobacz security through obscurity).

Jeśli jednak pojawi się komunikat o błędzie podobny do tego:

    ssh: connect to host 111.222.333.444 port 22: Operation timed out

Oznacza to, że coś odrzuca ruch TCP na porcie 22. Port jest niewidoczny, albo przez zaporę sieciową, albo przez interwencję strony trzeciej (np. dostawcę usług internetowych blokujący lub odrzucający ruch przychodzący na porcie 22). Jeśli na komputerze nie uruchamiasz zapory sieciowej i routery/przełączniki działają prawidłowo, to dostawca usług internetowych blokuje ruch.

Aby to sprawdzić, możesz uruchomić Wiresharka na serwerze i nasłuchiwać ruch na porcie 22. Ponieważ Wireshark to analizator pakietów warstwy 2, a TCP/UDP to warstwy 3 i wyższe (patrz IP Network stack), jeśli nie otrzymasz żadnych danych podczas połączenia zdalnego, trzecia strona najprawdopodobniej blokuje ruch na tym porcie do Twojego serwera.

##### Diagnosis

Install tcpdump lub Wireshark z pakietem wireshark-cli.

For tcpdump:

    # tcpdump -ni interface "port 22"

W przypadku Wiresharka:

    $ tshark -f "tcp port 22" -i interface

gdzie `interface` to interfejs sieciowy połączenia WAN (sprawdź `ip a`). Jeśli nie odbierasz żadnych pakietów podczas próby połączenia zdalnego, możesz być pewien, że Twój dostawca usług internetowych blokuje ruch przychodzący na porcie 22.

##### Możliwe rozwiązanie

Rozwiązaniem jest po prostu użycie innego portu, którego dostawca usług internetowych nie blokuje. Otwórz plik `/etc/ssh/sshd_config` i skonfiguruj go tak, aby korzystał z innych portów. Na przykład dodaj:

    Port 22
    Port 1234

Upewnij się również, że pozostałe wiersze konfiguracji „Port" w pliku są zakomentowane. Samo zakomentowanie „Port 22" i dodanie „Port 1234" nie rozwiąże problemu, ponieważ wtedy sshd będzie słuchać tylko na porcie 1234. Pozostaw oba wiersze bez komentarza, aby uruchomić serwer SSH na obu portach.

Restart usługę `sshd.service` — prawie gotowe. Pozostaje skonfigurować klienta(ów) do używania innego portu zamiast domyślnego. Istnieje wiele rozwiązań, poniżej omówimy dwa z nich.

#### Read from socket failed: connection reset by peer

Najnowsze wersje OpenSSH czasami powodują błąd i wyświetlają powyższy komunikat o błędzie podczas łączenia się ze starszymi serwerami SSH. Można to obejść, ustawiając różne client options dla danego hosta. Więcej informacji na temat poniższych opcji można znaleźć w ssh_config(5).

Problemem mogą być eliptyczne algorytmy klucza hosta `ecdsa-sha2-nistp*-cert-v01@openssh`. Można je wyłączyć, ustawiając `HostKeyAlgorithms` na listę wykluczającą te algorytmy. Po stronie klienta, `HostKeyAlgorithms`, którego klient chce użyć, można również ustawić, poprzedzając listę `HostKeyAlgorithms` znakiem `-`, aby usunąć określone algorytmy (w tym symbole wieloznaczne) z domyślnego zestawu (patrz ssh_config(5)). Możesz sprawdzić aktualnie używany algorytm klucza hosta za pomocą `ssh -v server_to_connect_to` w wierszu zawierającym `kex: host key algorithm:`.

Jeśli to nie pomoże, przyczyną może być zbyt długa lista szyfrów. Ustaw opcję `Ciphers` na krótszą listę (mniej niż 80 znaków powinno wystarczyć). Możesz również spróbować skrócić listę `MACs`.

Zobacz także dyskusję na forum błędów OpenSSH.

### "[your shell]: No such file or directory" / ssh_exchange_identification problem

Jedną z możliwych przyczyn jest wymóg niektórych klientów SSH, aby znaleźć ścieżkę bezwzględną (na przykład zwracaną przez `whereis -b [your shell]`) w zmiennej `$SHELL`, nawet jeśli plik binarny powłoki znajduje się w jednym z katalogów `$PATH`.

### "Terminal unknown" or "Error opening terminal" error message

Jeżeli podczas logowania otrzymujesz powyższe błędy, oznacza to, że serwer nie rozpoznaje Twojego terminala. Aplikacje ncurses, takie jak nano, mogą przestać działać, wyświetlając komunikat `Error opening terminal`.

Prawidłowym rozwiązaniem jest zainstalowanie pliku terminfo terminala klienta na serwerze. Dzięki temu programy konsolowe na serwerze będą mogły poprawnie wchodzić w interakcję z terminalem. Informacje o bieżącym pliku terminfo można uzyskać za pomocą polecenia `infocmp`, a następnie dowiedzieć się, który pakiet jest jego właścicielem.

Jeżeli nie możesz go install normalnie, możesz skopiować terminfo do katalogu domowego na serwerze:

    $ ssh myserver mkdir -p  ~/.terminfo/${TERM:0:1}
    $ scp /usr/share/terminfo/${TERM:0:1}/$TERM myserver:~/.terminfo/${TERM:0:1}/

Po zalogowaniu się i wylogowaniu z serwera problem powinien zostać rozwiązany.

#### TERM hack

Note Należy z tego rozwiązania korzystać wyłącznie w ostateczności.

Alternatywnie, możesz po prostu ustawić `TERM=xterm` w swoim środowisku na serwerze (np. w `.bash_profile`). To wyciszy błąd i umożliwi ponowne uruchomienie aplikacji ncurses, ale możesz doświadczyć dziwnego zachowania i błędów graficznych, chyba że sekwencje sterujące w Twoim terminalu będą dokładnie takie same jak w xterm.

### Connection closed by x.x.x.x [preauth]

Jeśli widzisz ten błąd w logach sshd, upewnij się, że ustawiłeś prawidłowy `HostKey`:

    /etc/ssh/sshd_config

    HostKey /etc/ssh/ssh_host_ed25519_key

### subsystem request failed

Ponieważ od wersji OpenSSH 8.8 `scp` domyślnie używa protokołu SFTP do przesyłania danych, żądając podsystemu `sftp`. Aby sprawdzić, którego podsystemu używa klient, uruchom `scp -v`. Błędy takie jak `subsystem request failed on channel 0` można naprawić poprzez konfigurację ustawienia sshd_config(5) § Subsystem na serwerze. Konfiguracja serwera powinna przypominać poniższy przykład.

    /etc/ssh/sshd_config

    ...
    Subsystem subsystem-name /path/to/subsystem-executable
    ...

### id_dsa refused

W OpenSSH 7.0 klucze publiczne DSA zostały wycofane ze względów bezpieczeństwa, a OpenSSH 9.8 został domyślnie zbudowany bez obsługi kluczy DSA. Pierwsza wersja OpenSSH w 2025 roku całkowicie usunie obsługę kluczy DSA. Na razie, jeśli absolutnie musisz ich używać, musisz przebudować openssh, przekazując `--enable-dsa-keys` do `configure`.[5]

### No matching key exchange method found by OpenSSH 7.0

W OpenSSH 7.0 algorytm klucza diffie-hellman-group1-sha1 został wycofany ze względu na jego słabość i teoretycznie mieści się w zakresie tzw. ataku Logjam (patrz https://www.openssh.com/legacy.html). Jeśli algorytm klucza jest potrzebny dla konkretnego hosta, SSH wygeneruje komunikat o błędzie podobny do poniższego:

    Unable to negotiate with 127.0.0.1: no matching key exchange method found.
    Their offer: diffie-hellman-group1-sha1

Najlepszym rozwiązaniem tych problemów jest aktualizacja/skonfigurowanie serwera tak, aby nie używał przestarzałych algorytmów. Jeśli to niemożliwe, można wymusić na kliencie ponowne włączenie algorytmu za pomocą client option `KexAlgorithms +diffie-hellman-group1-sha1`.

### tmux/screen session killed when disconnecting from SSH

The factual accuracy of this article or section is disputed.

Reason: The caveat must be solved because `logind` is used by default. (Discuss in Talk:OpenSSH (Polski))

Parafrazując odpowiedź na platformie Unix Stackexchange:

Jeśli procesy są zamykane na koniec sesji SSH, możliwe że używasz aktywacji soketów. Twój proces jest zamykany przez systemd, gdy wykryje, że proces sesji SSH się zakończył. W tym przypadku istnieją dwa rozwiązania:

- Unikaj aktywacji soketów poprzez migrację do `sshd.service` (zalecane, patrz #Socket activation) lub
- Ustaw `KillMode=process` w sekcji `[Service]` w `sshd@.service`.

Choć nie jest to konieczne, ustawienie `KillMode=process` w `sshd.service` może być również przydatne, gdyż pozwala uniknąć zamykania procesu sesji SSH i jego procesu screen lub tmux po zatrzymaniu lub ponownym uruchomieniu serwera.

Należy pamiętać, że ta opcja może nie działać z `logind`.

### Sesja SSH przestaje odpowiadać

SSH reaguje na flow control commands `XON` i `XOFF`. Po naciśnięciu `Ctrl+s` protokół zawiesi się lub przestanie odpowiadać. Użyj `Ctrl+q`, aby wznowić sesję.

### Broken pipe

Jeśli próbujesz utworzyć połączenie, co skutkuje odpowiedzią `Broken pipe` na `packet_write_wait`, powinieneś ponowić próbę nawiązania połączenia w trybie debugowania i sprawdzić, czy dane wyjściowe zakończą się błędem:

    debug3: send packet: type 1
    packet_write_wait: Connection to A.B.C.D port 22: Broken pipe

Powyższy wiersz `send packet` wskazuje, że pakiet odpowiedzi nigdy nie został odebrany. Wynika z tego, że jest to problem z „QoS”. Aby zmniejszyć prawdopodobieństwo utraty pakietu, ustaw `IPQoS`:

    /etc/ssh/ssh_config

    Match all
        IPQoS reliability

Problem powinien zostać rozwiązany przez usługę typu `reliability` (`0x04`), a także przez `0x00` i `throughput` (`0x08`).

### Zakończ nieodpowiadające połączenie SSH

Jeśli sesja klienta nie odpowiada i nie można jej zakończyć, wydając polecenie działającemu programowi (np. shell), nadal można zakończyć sesję, naciskając kolejno `Enter`, `~` i `.`.

`~` to znak ucieczki pseudo-terminala (patrz ssh(1) § ESCAPE CHARACTERS), który można dodać wielokrotnie w zależności od sesji klienta, którą chcesz zakończyć. Na przykład, jeśli połączyłeś się z A do B, a następnie z B do C, a sesja z B do C zawiesi się, możesz ją zakończyć, naciskając `Enter` i wpisując `~~.`, co pozostawi Cię w działającej sesji na B.

### WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

Jeśli klient ostrzega o zmianie klucza serwera SSH, należy zweryfikować, czy nowo udostępniony klucz rzeczywiście należy do operatora serwera, za pośrednictwem uwierzytelnionego (niekoniecznie szyfrowanego) kanału. Następnie należy usunąć stary klucz z pliku `known_hosts` za pomocą polecenia `ssh-keygen -R $SSH_HOST` i zaakceptować nowy klucz tak, jakby był to nowy serwer.

### Łączenie się ze zdalnym komputerem bez odpowiedniego wpisu terminfo

Łącząc się z hostami, które nie mają wpisu terminfo dla Twojego terminala, na przykład podczas korzystania z emulatora terminala, którego wpis terminfo nie jest dostarczany z ncurses (np. kitty i rxvt-unicode), lub łącząc się z hostami z ograniczoną bazą danych terminfo (np. systemami z OpenWrt), mogą pojawić się różne problemy z oprogramowaniem, które opiera się na terminfo(5).

Prawidłowym rozwiązaniem jest umieszczenie odpowiedniego wpisu terminfo na hoście. Jeśli nie jest to możliwe, alternatywą jest ustawienie `TERM` na wartość, która jest obsługiwana przez host zdalny i zgodna z terminalem.

Od OpenSSH 8.7 można przesłać dowolną zmienną środowiskową `TERM` do zdalnych hostów za pomocą prostej konfiguracji:

    ~/.ssh/config

    Host example.com
      SetEnv TERM=xterm-256color

### Connection through jump host fails with "bash: No such file or directory"

Jeśli zmienna środowiskowa `SHELL` nie jest ustawiona na pełną, prawidłową ścieżkę (na serwerze jump), połączenie nie powiedzie się z komunikatem o błędzie podobnym do:

    bash: No such file or directory
    kex_exchange_identification: Connection closed by remote host
    Connection closed by UNKNOWN port 65535

Możesz rozwiązać to, ustawiając `SHELL` na pełną ścieżkę powłoki, która będzie ważna również na jump serverze, lub ustawiając zmienną `SHELL` dla każdego serwera w pliku `~/.ssh/config`.

Categories:

- Secure Shell (Polski)
- Servers (Polski)
- OpenBSD (Polski)

Hidden categories:

- Pages or sections flagged with Template:Expansion
- Pages or sections flagged with Template:Accuracy
- Pages or sections flagged with Template:Out of date
- Pages or sections flagged with Template:Style

OpenSSH (Polski)
Add topic