SSH od środka

Wstęp

Masz czterdzieści serwerów. Do każdego inne hasło, bo przecież jesteś odpowiedzialny. Rano wpisujesz hasło dwadzieścia razy, po południu kolejne dwadzieścia, a wieczorem śni Ci się Permission denied, please try again.

Admini tak nie pracują. Wpisują ssh web i są w środku. Bez hasła, bez adresu, bez nazwy użytkownika. A do bazy, która stoi za dwiema zaporami, wchodzą jedną komendą. Dziś zrobimy z Ciebie takiego admina: klucze, plik konfiguracyjny klienta, bezpieczne ustawienia serwera i tunele, czyli prywatne korytarze w cudzej sieci.

Klucz zamiast hasła

Pamiętasz analogię z początku kursu? Klucz SSH to kłódka na serwerze i kluczyk w kieszeni. Robisz komplet: kłódkę, czyli klucz publiczny, i kluczyk, czyli klucz prywatny. Kłódkę możesz rozdać całemu światu, przypiąć na każdym serwerze, wywiesić na płocie. Kluczyka nie dajesz nikomu, nigdy. Serwer z Twoją kłódką wpuszcza każdego, kto ją otworzy, czyli tylko Ciebie.

Robimy komplet, w nowoczesnym typie ed25519:

ssh-keygen -t ed25519 -C "marek@laptop"

Generating public/private ed25519 key pair.
Your identification has been saved in /home/marek/.ssh/id_ed25519
Your public key has been saved in /home/marek/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:sAOgsDc1Sc3ox1fzQKd0IVkVNCQiHwFmKD4UFX840xY marek@laptop

Po drodze pyta o hasło do klucza, passphrase. Ustaw je. Bez niego ktoś, kto ukradnie Ci laptopa, ma kluczyki do wszystkich czterdziestu serwerów. Z nim ma bezużyteczny plik. -C to tylko komentarz, żeby za rok wiedzieć, czyj to klucz.

ls -l ~/.ssh

-rw------- 1 marek marek 399 Nov  3 15:31 id_ed25519
-rw-r--r-- 1 marek marek  94 Nov  3 15:31 id_ed25519.pub

.pub to kłódka, jedna linijka tekstu. Bez .pub to kluczyk, uprawnienia 600, tylko dla Ciebie.

Przypięcie kłódki: ssh-copy-id

Kłódkę trzeba zawiesić na serwerze. Ręcznie się da, ale po co:

ssh-copy-id kuba@10.0.0.10

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/marek/.ssh/id_ed25519.pub"
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'kuba@10.0.0.10'"
and check to make sure that only the key(s) you wanted were added.

Ostatni raz podajesz hasło. ssh-copy-id łączy się, dopisuje Twoją kłódkę na koniec pliku ~/.ssh/authorized_keys użytkownika kuba i ustawia uprawnienia. Sprawdzamy:

ssh kuba@10.0.0.10 "ls -la ~/.ssh; cat ~/.ssh/authorized_keys"

drwx------ 2 kuba kuba 4096 Nov  3 16:31 .
-rw------- 1 kuba kuba   94 Nov  3 16:31 authorized_keys
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDjeJSn9OBJZKqp9UUGFYUNzgsuROI6wFL7LuKwgk5SW marek@laptop

Bez hasła. authorized_keys to lista kłódek, które ten użytkownik akceptuje, jedna w linijce. Odebranie komuś dostępu? Usuwasz jego linijkę.

Przy pierwszym połączeniu z nowym serwerem zobaczysz jeszcze to:

The authenticity of host '10.0.0.10 (10.0.0.10)' can't be established.
ED25519 key fingerprint is SHA256:eSWaHBKjUKaSPQXK17i6p/rlkIhJA0ZyNnny93ktJTI.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Teraz to serwer pokazuje Ci swój dowód osobisty. Porządny admin porównuje odcisk z tym, co mówi sam serwer, na przykład z konsoli:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

256 SHA256:eSWaHBKjUKaSPQXK17i6p/rlkIhJA0ZyNnny93ktJTI root@vm (ED25519)

Zgadza się, więc yes. Klient zapisze ten odcisk w ~/.ssh/known_hosts i przy każdym kolejnym połączeniu będzie sprawdzał, czy serwer to wciąż ten sam serwer.

Agent, czyli hasło do klucza raz na sesję

Hasło do klucza przy każdym ssh szybko znudzi. Od tego jest ssh-agent: pomocnik, który trzyma odblokowany klucz w pamięci. Na pulpicie zwykle działa sam, na serwerze uruchamiasz go ręcznie:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/klucz_z_haslem
ssh-add -l

Agent pid 32084
Identity added: /home/marek/.ssh/klucz_z_haslem (test)
256 SHA256:njvnFuoz+mKyNneboFR0xnx+VziBn4DRXPwXIUooxtY test (ED25519)

Hasło wpisujesz raz, przy ssh-add. [macOS] Na Macu agent działa od razu i potrafi trzymać hasło w pęku kluczy systemu.

~/.ssh/config: książka adresowa

Zamiast ssh -i ~/.ssh/id_ed25519 -p 22 kuba@10.0.0.10 robimy wpis w ~/.ssh/config:

Host web
    HostName 10.0.0.10
    User kuba
    IdentityFile ~/.ssh/id_ed25519

Host baza
    HostName 10.1.0.2
    User kuba
    ProxyJump web

chmod 600 ~/.ssh/config
ssh web hostname -I

10.0.0.10 10.1.0.1

Host to Twoja ksywka dla serwera. HostName to prawdziwy adres. User, Port, IdentityFile mówią same za siebie. Ksywka działa wszędzie: w ssh, scp, sftp, rsync. Co klient naprawdę z tego zrozumiał, pokaże ssh -G:

ssh -G baza | grep -E '^(hostname|user|port|proxyjump) '

user kuba
hostname 10.1.0.2
port 22
proxyjump web

Skok przez serwer: -J

Wpis baza ma ProxyJump web. Baza stoi w sieci, do której laptop nie ma drogi:

ssh -o ConnectTimeout=3 kuba@10.1.0.2

ssh: connect to host 10.1.0.2 port 22: Network is unreachable

A przez skok:

ssh baza 'echo jestem na: $(hostname -I)'
ssh -J web kuba@10.1.0.2 'hostname -I'

jestem na: 10.1.0.2
10.1.0.2

-J, jump, to wejście do bazy przez serwer web, który robi za przedsionek. Wygodne, a przy tym bezpieczne: Twój kluczyk nigdy nie ląduje na web. Przedsionek tylko przekazuje zaszyfrowaną rozmowę dalej, jak kurier, który niesie zaklejoną kopertę.

scp i sftp: przenoszenie plików

scp raport.txt web:/tmp/              # z laptopa na serwer
scp -r projekt web:                   # cały folder do domowego na serwerze
scp web:/etc/hostname ./              # z serwera do laptopa

Dwukropek to granica: po lewej nazwa serwera, po prawej ścieżka na nim. Sam dwukropek bez ścieżki to folder domowy. Zapomnisz dwukropka, a scp grzecznie skopiuje plik lokalnie do pliku o nazwie web. Brawo, właśnie zrobiłeś kopię raportu obok raportu.

sftp to rozmowa z serwerem plików, z komendami jak w terminalu:

sftp web

sftp> pwd
Remote working directory: /home/kuba
sftp> ls
projekt
sftp> put raport.txt
sftp> get /etc/os-release
sftp> bye

put wysyła, get pobiera, ls i cd działają na serwerze, lls i lcd u Ciebie. Do dużych folderów lepszy jest rsync, o nim w następnej lekcji.

Tunele: -L i -R

Teraz magia. Na bazie danych działa panel, który słucha tylko na 127.0.0.1:5432. Z zewnątrz nie dojdziesz, i bardzo dobrze. Ale Ty musisz do niego zajrzeć.

Tunel lokalny, -L: „otwórz u mnie port 15432, a wszystko, co do niego wpadnie, przenieś przez SSH i wypuść na serwerze do localhost:5432”.

ssh -f -N -L 15432:localhost:5432 baza
curl http://localhost:15432/

panel bazy (tylko localhost)

To jak prywatny korytarz wykopany pod ulicą: wchodzisz drzwiami w swojej piwnicy, wychodzisz w piwnicy serwera. -N znaczy „nie otwieraj powłoki, tylko tunel”, -f znaczy „schowaj się w tło”. Ważne: localhost w tej komendzie oznacza localhost serwera, nie Twojego laptopa.

Tunel odwrotny, -R, działa w drugą stronę. Na laptopie masz aplikację na porcie 3000 i chcesz ją pokazać na serwerze:

ssh -f -N -R 8000:localhost:3000 web
# na serwerze:
curl http://localhost:8000/

aplikacja z laptopa

Serwer otworzył u siebie port 8000, który prowadzi do Twojego laptopa. Domyślnie tylko na 127.0.0.1 serwera, żeby nie wystawić laptopa całemu światu.

sshd_config: drzwi od strony serwera

Do tej pory był klient. Serwer, czyli usługa sshd, ma swój plik /etc/ssh/sshd_config, a na nowych systemach dodatkowo folder /etc/ssh/sshd_config.d/. Zamiast grzebać w głównym pliku, robisz własny:

# /etc/ssh/sshd_config.d/50-hardening.conf
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers kuba
MaxAuthTries 3

Uwaga, teraz najważniejsza zasada lekcji. Zanim wyłączysz hasła, sprawdź, że logujesz się kluczem. Zanim zrestartujesz usługę, sprawdź składnię. I trzymaj drugą sesję SSH otwartą, dopóki nowa nie wejdzie.

sudo sshd -t

Cisza znaczy „w porządku”. Literówka wygląda tak:

/etc/ssh/sshd_config.d/50-hardening.conf: line 2: Bad configuration option: PasswordAuthentcation
/etc/ssh/sshd_config.d/50-hardening.conf: terminating, 1 bad configuration options

A sshd -T wypisze ustawienia, które naprawdę obowiązują:

sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|allowusers|maxauthtries) '

maxauthtries 3
permitrootlogin no
passwordauthentication no
allowusers kuba

Dopiero teraz przeładowanie:

sudo systemctl reload ssh     # [Ubuntu]
sudo systemctl reload sshd    # [RHEL]

Tak, usługa nazywa się inaczej. [Ubuntu] Na Ubuntu 24.04 SSH startuje przez gniazdo systemd (ssh.socket). Zmiana portu wymaga więc sudo systemctl daemon-reload i sudo systemctl restart ssh.socket. [RHEL] Na Red Hacie zmiana portu to jeszcze zgoda SELinuksa (semanage port -a -t ssh_port_t -p tcp 2222) i otwarcie portu w firewalld. Logi logowań: /var/log/auth.log [Ubuntu] i /var/log/secure [RHEL], albo journalctl -u ssh / journalctl -u sshd.

Jak to działa pod spodem

Połączenie SSH to trzy etapy. Najpierw klient i serwer uzgadniają wspólny tajny klucz sesji metodą wymiany kluczy, więc dalej wszystko leci zaszyfrowane, nawet hasło. Potem serwer udowadnia, kim jest, kluczem hosta, a klient porównuje go z known_hosts. Na końcu klient udowadnia, kim jest. Przy kluczu wygląda to tak:

ssh -v web true 2>&1 | grep -E 'Offering|accepts|Authenticated'

debug1: Offering public key: /home/marek/.ssh/id_ed25519 ED25519 SHA256:sAOgsDc1Sc3ox1fzQKd0IVkVNCQiHwFmKD4UFX840xY explicit
debug1: Server accepts key: /home/marek/.ssh/id_ed25519 ED25519 SHA256:sAOgsDc1Sc3ox1fzQKd0IVkVNCQiHwFmKD4UFX840xY explicit
Authenticated to 10.0.0.10 ([10.0.0.10]:22) using "publickey".

Klient mówi: „mam kłódkę taką i taką”. Serwer sprawdza authorized_keys: „znam, udowodnij”. Klient podpisuje kluczem prywatnym dane z tej konkretnej sesji, serwer sprawdza podpis kłódką. Kluczyk prywatny nigdy nie opuszcza laptopa. Wysłany zostaje tylko podpis, ważny jeden raz.

sshd jest przy tym podejrzliwy. Opcja StrictModes, domyślnie włączona, odrzuca klucze, jeśli authorized_keys, folder .ssh albo folder domowy mogą być zmieniane przez kogoś innego. Bo jak ktoś obcy może dopisać kłódkę, to cała zabawa nie ma sensu.

Ściąga flag