Folosirea inteligentă a SSH

Modulul 2: SSH și chei · Timp de citire: 10 minute

Obiectivul lecției: După această lecție veți putea folosi SSH comod în fiecare zi, cu propriul fișier de configurare, veți putea copia fișiere cu scp și rsync și veți putea ajunge la o bază de date printr-un tunel, fără ca portul bazei de date să fie deschis către internet.

Noțiuni cheie: ~/.ssh/config, Host, HostName, User, IdentityFile, scp, rsync, sftp, port forwarding, -L, tunel, ProxyJump, ServerAliveInterval, alt număr de port, revocarea unei chei

Mai puțin de tastat cu ~/.ssh/config

După câteva săptămâni veți tasta acest lucru de zeci de ori pe zi:

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

Cu un fișier de configurare pentru client, comanda devine mai scurtă și faceți mai puține greșeli. Fișierul se află pe propriul dumneavoastră calculator: ~/.ssh/config (Windows: C:\Users\anna\.ssh\config, fără extensie).

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

Acum este suficient:

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

Ce fac aceste rânduri?

• Host este porecla pe care o alegeți dumneavoastră. O tastați după ssh, scp și rsync.
• HostName este adresa reală: o adresă IP sau un nume care există în DNS.
• User și Port sunt numele de utilizator și portul, astfel încât nu mai trebuie să le țineți minte.
• IdentityFile indică cheia. Este util dacă aveți mai multe chei; fără acest rând, ssh încearcă cheile dumneavoastră implicite.
• ServerAliveInterval 60 trimite la fiecare 60 de secunde un mic semn de viață. Multe routere de acasă și rețele wifi întrerup o conexiune inactivă după câteva minute; astfel sesiunea dumneavoastră rămâne deschisă.

Și aici contează prima valoare, la fel ca pe server. Așadar, puneți regulile generale precum Host * la sfârșitul fișierului.

Copierea fișierelor: scp, rsync și sftp

scp copiază un fișier, cu aceeași formă ca cp, dar cu host: în față:

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

rsync este mai inteligent pentru directoare și cantități mari: trimite doar ceea ce s-a modificat și poate relua o copiere întreruptă. Trebuie să fie instalat de ambele părți (apt install rsync).

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

Atenție la bara oblică de după ./site/: cu bară, rsync copiază conținutul directorului; fără bară, copiază directorul însuși (veți obține atunci /var/www/example.com/site/). Dacă aveți dubii, încercați mai întâi cu --dry-run și fiți foarte atenți cu --delete, care șterge în partea de destinație tot ce nu există la dumneavoastră.

sftp și programele grafice precum FileZilla sau WinSCP folosesc aceeași conexiune SSH și aceeași cheie. Prin urmare, nu este nevoie de un server FTP separat. Un server FTP de modă veche pe un VPS nu este recomandat: FTP-ul obișnuit trimite parola dumneavoastră necriptată prin rețea.

Un tunel în loc de un port deschis

Acesta este poate cel mai util lucru pe care îl poate face SSH. Să presupunem că pe serverul dumneavoastră rulează o bază de date PostgreSQL. Doriți să o accesați de pe laptop cu un program grafic. Tentația de a deschide portul 5432 către internet este mare. Nu faceți acest lucru: porturile deschise ale bazelor de date sunt una dintre cele mai mari cauze ale scurgerilor de date (lecția 10.2), iar cursul verifică ulterior din exterior că acestea sunt închise (exercițiul Z5.1).

Cu port forwarding local, lăsați SSH să creeze un tunel:

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

Citiți comanda astfel: „ascultă pe laptopul meu pe portul 5432 și trimite tot ce intră acolo prin conexiunea SSH către 127.0.0.1:5432, văzut de pe server”. Cât timp această sesiune este deschisă, conectați programul de baze de date la localhost, portul 5432, pe propriul laptop și ajungeți la baza de date de pe server.

De ce este atât de bună această metodă?

• Baza de date ascultă doar pe 127.0.0.1 pe server și nu poate fi accesată din exterior.
• Conexiunea este criptată de SSH, chiar dacă baza de date însăși nu are criptare.
• Doar cine se poate autentifica prin SSH are acces. Folosiți așadar securitatea puternică pe care o aveți deja.

Dacă pe laptop rulează deja ceva pe 5432, alegeți în stânga un alt număr: -L 15432:127.0.0.1:5432 și conectați-vă la portul 15432. Dacă puneți tunelul în ~/.ssh/config, îl aveți mereu la îndemână:

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

Cu ssh -N web1-db obțineți doar tunelul, fără linie de comandă.

Printr-un server intermediar: ProxyJump

Uneori un server poate fi accesat doar printr-un alt server, de exemplu un server de baze de date fără adresă IP publică, aflat în spatele serverului web. ProxyJump trece prin primul server mai departe, către al doilea:

Host db1
    HostName 10.0.0.5
    User anna
    ProxyJump web1

Diferența față de agent forwarding (lecția 2.1): cu ProxyJump, criptarea merge de la un capăt la altul, între laptopul dumneavoastră și db1. Serverul intermediar doar transmite pachetele mai departe și nu vă poate folosi cheia.

Alt număr de port: da sau nu?

Multe ghiduri recomandă mutarea SSH pe un alt port, de exemplu 2222. Ce face acest lucru în realitate?

• Reduce zgomotul: majoritatea încercărilor automate de ghicire încearcă doar portul 22. Jurnalul dumneavoastră devine mai liniștit.
• Nu este o măsură de securitate. Un scanner care parcurge toate porturile găsește SSH în câteva secunde, după bannerul de versiune.

Cu chei și cu autentificarea prin parolă dezactivată (lecția 2.2), portul contează puțin pentru securitate. Dacă doriți totuși să îl schimbați, procedați în ordinea corectă: deschideți noul port în firewall, lăsați SSH să asculte pe ambele porturi, testați într-o a doua fereastră și abia apoi închideți portul vechi. Pe Ubuntu 24.04 și versiunile ulterioare, acest lucru implică și systemctl daemon-reload și systemctl restart ssh.socket (lecția 2.2). Nu uitați că furnizorul dumneavoastră are, posibil, și el un firewall.

Revocarea accesului

Un fost coleg sau un dezvoltator web avea o cheie pe serverul dumneavoastră și nu mai lucrează pentru dumneavoastră? Revocarea accesului este simplă, dacă țineți evidența:

1. Verificați toate cheile: ssh-keygen -lf ~/.ssh/authorized_keys și faceți acest lucru pentru fiecare utilizator (inclusiv /root/.ssh/authorized_keys).
2. Ștergeți rândul persoanei respective.
3. Dacă folosea un cont de utilizator propriu, blocați-l (lecția 3.1) și verificați dacă făcea parte din grupul sudo (lecția 3.2).
4. Dacă a văzut parole, de exemplu o parolă de bază de date dintr-un fișier de configurare, schimbați-le și pe acestea.

O cheie obișnuită nu are dată de expirare. Ce nu ștergeți continuă să funcționeze, chiar și ani mai târziu. Dacă acordați cuiva acces temporar, puteți pune în fața rândului său din authorized_keys opțiunea expiry-time="20261231"; după acea dată, serverul refuză cheia.

Rezumat

• ~/.ssh/config de pe propriul calculator păstrează pentru fiecare server numele, utilizatorul, portul și cheia; Host * se pune la sfârșit.
• scp pentru fișiere individuale, rsync pentru directoare (atenție la bara oblică și la --delete), sftp în loc de FTP.
• Cu ssh -L ajungeți la o bază de date printr-un tunel criptat, în timp ce portul bazei de date rămâne închis din exterior.
• ProxyJump trece în siguranță printr-un server intermediar; este mai bun decât agent forwarding.
• Un alt număr de port reduce zgomotul, dar nu protejează. Cheile pe care nu le ștergeți continuă să funcționeze.

Test (quiz)

Exercițiu

Exercițiul O2.3: O configurație SSH și un tunel. Creați pe propriul calculator un fișier ~/.ssh/config cu o poreclă pentru serverul dumneavoastră, autentificați-vă doar cu ssh <bijnaam>, copiați un fișier cu scp sau rsync și creați un tunel cu -L către un serviciu care pe server ascultă doar pe 127.0.0.1 (dacă nu aveți încă o bază de date, folosiți portul 22 al serverului însuși: ssh -L 2200:127.0.0.1:22 <bijnaam> și apoi ssh -p 2200 anna@localhost). Răspundeți la întrebările despre ce face tunelul și de ce portul nu trebuie deschis.

Lecturi suplimentare

Pașii din aceste articole se aplică VPS-urilor și panourilor WebOké; la alți furnizori, procedura este similară.

• Autentificarea pe VPS prin SSH (și crearea unei chei SSH)
• Manualul ssh_config (setările clientului): https://man.openbsd.org/ssh_config
• Manualul ssh (opțiunile -L, -J, -N): https://man.openbsd.org/ssh