Sprawne korzystanie z SSH

Moduł 2: SSH i klucze · Czas czytania: 10 min

Cel lekcji: Po tej lekcji będą Państwo sprawnie korzystać z SSH na co dzień dzięki własnemu plikowi konfiguracyjnemu, kopiować pliki za pomocą scp i rsync oraz łączyć się z bazą danych przez tunel, bez otwierania portu bazy danych na internet.

Kluczowe pojęcia: ~/.ssh/config, Host, HostName, User, IdentityFile, scp, rsync, sftp, port forwarding, -L, tunel, ProxyJump, ServerAliveInterval, inny numer portu, odebranie klucza

Mniej pisania dzięki ~/.ssh/config

Po kilku tygodniach wpisują Państwo to polecenie dziesiątki razy dziennie:

anna@laptop:~$ ssh -i ~/.ssh/id_ed25519 anna@192.0.2.10

Dzięki plikowi konfiguracyjnemu klienta polecenie staje się krótsze, a błędów jest mniej. Plik znajduje się na Państwa własnym komputerze: ~/.ssh/config (Windows: C:\Users\anna\.ssh\config, bez rozszerzenia).

Host web1
    HostName 192.0.2.10
    User anna
    IdentityFile ~/.ssh/id_ed25519
    ServerAliveInterval 60

Host test
    HostName test.example.com
    User anna
    Port 2222

Teraz wystarczy:

anna@laptop:~$ ssh web1
anna@web1:~$

Co oznaczają poszczególne wiersze?

• Host to wybrana przez Państwa nazwa skrócona (alias). Wpisują ją Państwo po ssh, scp i rsync.
• HostName to prawdziwy adres: adres IP lub nazwa zapisana w DNS.
• User i Port to nazwa użytkownika i port, dzięki czemu nie trzeba ich już pamiętać.
• IdentityFile wskazuje klucz. Przydaje się, gdy mają Państwo kilka kluczy; bez tego wiersza ssh próbuje kluczy domyślnych.
• ServerAliveInterval 60 co 60 sekund wysyła drobny sygnał podtrzymania. Wiele domowych routerów i sieci Wi-Fi zrywa bezczynne połączenie po kilku minutach; dzięki temu sesja pozostaje otwarta.

Tu również, podobnie jak na serwerze, liczy się pierwsza wartość. Ogólne reguły, takie jak Host *, należy więc umieścić na końcu pliku.

Kopiowanie plików: scp, rsync i sftp

scp kopiuje plik, używając tej samej formy co cp, ale z host: przed nią:

anna@laptop:~$ scp backup.sql web1:/home/anna/
anna@laptop:~$ scp web1:/var/log/nginx/error.log .

rsync lepiej radzi sobie z katalogami i dużą ilością danych: przesyła tylko to, co się zmieniło, i potrafi wznowić przerwane kopiowanie. Musi być zainstalowany po obu stronach (apt install rsync).

anna@laptop:~$ rsync -avz --progress ./site/ web1:/var/www/example.com/

Proszę zwrócić uwagę na ukośnik po ./site/: z ukośnikiem rsync kopiuje zawartość katalogu, bez ukośnika sam katalog (otrzymują Państwo wtedy /var/www/example.com/site/). W razie wątpliwości najpierw proszę spróbować z --dry-run i zachować dużą ostrożność przy --delete, która po stronie odbiorczej usuwa wszystko, czego nie ma u Państwa.

sftp oraz programy graficzne, takie jak FileZilla czy WinSCP, korzystają z tego samego połączenia SSH i tego samego klucza. Osobny serwer FTP nie jest więc potrzebny. Odradzamy staromodny serwer FTP na VPS: zwykłe FTP przesyła hasło przez sieć bez szyfrowania.

Tunel zamiast otwartego portu

To być może najbardziej przydatna funkcja SSH. Załóżmy, że na Państwa serwerze działa baza danych PostgreSQL i chcą się Państwo z nią łączyć z laptopa za pomocą programu graficznego. Kusi, by otworzyć port 5432 na internet. Prosimy tego nie robić: otwarte porty baz danych to jedna z najczęstszych przyczyn wycieków danych (lekcja 10.2), a kurs później sprawdzi z zewnątrz, czy są zamknięte (zadanie Z5.1).

Dzięki lokalnemu przekierowaniu portów (local port forwarding) SSH tworzy tunel:

anna@laptop:~$ ssh -L 5432:127.0.0.1:5432 web1

Należy to czytać tak: „nasłuchuj na moim laptopie na porcie 5432 i przesyłaj wszystko, co tam trafi, przez połączenie SSH do 127.0.0.1:5432, widzianego z perspektywy serwera”. Dopóki ta sesja jest otwarta, łączą Państwo program bazodanowy z localhost, port 5432, na własnym laptopie i trafiają do bazy danych na serwerze.

Dlaczego to takie dobre rozwiązanie?

• Baza danych nasłuchuje na serwerze tylko na 127.0.0.1 i jest niedostępna z zewnątrz.
• Połączenie jest szyfrowane przez SSH, nawet jeśli sama baza danych nie ma szyfrowania.
• Dostęp ma tylko ten, kto może zalogować się przez SSH. Korzystają więc Państwo z silnych zabezpieczeń, które już mają.

Jeśli na laptopie coś już działa na porcie 5432, proszę wybrać po lewej inny numer: -L 15432:127.0.0.1:5432, i połączyć się z portem 15432. Po zapisaniu tunelu w ~/.ssh/config mają go Państwo zawsze pod ręką:

Host web1-db
    HostName 192.0.2.10
    User anna
    LocalForward 15432 127.0.0.1:5432

Z ssh -N web1-db otrzymują Państwo sam tunel, bez wiersza poleceń.

Przez serwer pośredni: ProxyJump

Czasem do serwera można dotrzeć tylko przez inny, na przykład do serwera bazy danych bez publicznego adresu IP, ukrytego za serwerem WWW. ProxyJump przeskakuje przez pierwszy serwer do drugiego:

Host db1
    HostName 10.0.0.5
    User anna
    ProxyJump web1

Różnica w porównaniu z agent forwarding (lekcja 2.1): przy ProxyJump szyfrowanie obejmuje całą drogę między Państwa laptopem a db1. Serwer pośredni jedynie przekazuje pakiety i nie może użyć Państwa klucza.

Inny numer portu: tak czy nie?

Wiele poradników zaleca przeniesienie SSH na inny port, na przykład 2222. Co to faktycznie daje?

• Zmniejsza szum: większość zautomatyzowanych prób odgadnięcia hasła dotyczy tylko portu 22. Log staje się spokojniejszy.
• Nie jest zabezpieczeniem. Skaner sprawdzający wszystkie porty w ciągu kilku sekund rozpozna SSH po banerze z wersją.

Przy kluczach i wyłączonym logowaniu hasłem (lekcja 2.2) port ma niewielkie znaczenie dla bezpieczeństwa. Jeśli mimo to chcą go Państwo zmienić, prosimy zachować właściwą kolejność: otworzyć nowy port w zaporze, ustawić SSH tak, aby nasłuchiwał na obu portach, przetestować w drugim oknie i dopiero wtedy zamknąć stary port. W Ubuntu 24.04 i nowszych należą do tego systemctl daemon-reload oraz systemctl restart ssh.socket (lekcja 2.2). Proszę pamiętać, że dostawca może mieć również własną zaporę.

Odbieranie dostępu

Były współpracownik lub twórca stron miał klucz na Państwa serwerze i już dla Państwa nie pracuje? Odebranie dostępu jest proste, jeśli prowadzą Państwo ewidencję:

1. Proszę przejrzeć wszystkie klucze: ssh-keygen -lf ~/.ssh/authorized_keys, i zrobić to dla każdego użytkownika (także /root/.ssh/authorized_keys).
2. Proszę usunąć wiersz tej osoby.
3. Jeśli korzystała z własnego konta użytkownika, proszę je zablokować (lekcja 3.1) i sprawdzić, czy należała do grupy sudo (lekcja 3.2).
4. Jeśli widziała hasła, na przykład hasło do bazy danych w pliku konfiguracyjnym, proszę je również zmienić.

Zwykły klucz nie ma daty ważności. To, czego Państwo nie usuną, będzie działać nawet po latach. Jeśli przyznają Państwo komuś dostęp tymczasowy, można przed jego wierszem w authorized_keys dodać opcję expiry-time="20261231"; po tej dacie serwer odrzuci klucz.

Podsumowanie

• ~/.ssh/config na własnym komputerze przechowuje dla każdego serwera nazwę, użytkownika, port i klucz; Host * należy umieścić na końcu.
• scp do pojedynczych plików, rsync do katalogów (uwaga na ukośnik i na --delete), sftp zamiast FTP.
• Z ssh -L łączą się Państwo z bazą danych przez szyfrowany tunel, a port bazy danych pozostaje zamknięty z zewnątrz.
• ProxyJump bezpiecznie przeskakuje przez serwer pośredni; jest lepszy niż agent forwarding.
• Inny numer portu zmniejsza szum, ale nie zabezpiecza. Klucze, których Państwo nie usuną, nadal działają.

Quiz

Zadanie

Zadanie O2.3: Konfiguracja SSH i tunel. Proszę utworzyć na własnym komputerze plik ~/.ssh/config z aliasem dla serwera, zalogować się, wpisując tylko ssh <bijnaam>, skopiować plik za pomocą scp lub rsync oraz utworzyć tunel z -L do usługi, która na serwerze nasłuchuje tylko na 127.0.0.1 (jeśli nie mają Państwo jeszcze bazy danych, proszę użyć portu 22 samego serwera: ssh -L 2200:127.0.0.1:22 <bijnaam>, a następnie ssh -p 2200 anna@localhost). Proszę odpowiedzieć na pytania o to, co robi tunel i dlaczego port nie musi być otwarty.

Przeczytaj więcej

Kroki opisane w tych artykułach dotyczą serwerów VPS i paneli WebOké; u innych dostawców działa to podobnie.

• Logowanie do VPS przez SSH (i tworzenie klucza SSH)
• Dokumentacja ssh_config (ustawienia klienta): https://man.openbsd.org/ssh_config
• Dokumentacja ssh (opcje -L, -J, -N): https://man.openbsd.org/ssh