Configurarea sigură a serverului SSH

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

Obiectivul lecției: După această lecție veți putea dezactiva autentificarea cu parolă și autentificarea root cu parolă, veți putea verifica ce setare se aplică cu adevărat și veți face acest lucru fără să vă blocați singur accesul.

Noțiuni cheie: sshd, sshd_config, sshd_config.d, contează prima valoare, PasswordAuthentication, KbdInteractiveAuthentication, PermitRootLogin, AuthenticationMethods, AllowUsers, sshd -t, sshd -T, a doua sesiune, cloud-init, ssh.socket

Mai întâi plasa de siguranță

Această lecție închide o ușă prin care trebuie să treceți chiar dumneavoastră. O greșeală de tastare poate însemna că nu mai puteți intra. De aceea, înainte de a începe, asigurați-vă întotdeauna de următoarele:

1. Două chei funcționează (lecția 2.1) și ați verificat într-o fereastră nouă că autentificarea cu cheie reușește.
2. Un snapshot al VPS-ului dumneavoastră. La WebOké îl creați în ecranul VPS, iar la alți furnizori se numește tot snapshot sau image. Dacă ceva nu merge, îl restaurați.
3. Consola furnizorului dumneavoastră vă este cunoscută: prin ea intrați fără SSH.
4. Sesiunea SSH curentă rămâne deschisă până la final. O sesiune activă continuă să funcționeze când modificați setările sau reîncărcați serviciul. Testați fiecare modificare într-o a doua fereastră.

Unde se află setările

Serverul SSH se numește sshd. Setările sale se află în /etc/ssh/sshd_config. Pe Debian și Ubuntu, în partea de sus a acestui fișier se află următoarea linie:

Include /etc/ssh/sshd_config.d/*.conf

Toate fișierele cu .conf din directorul sshd_config.d sunt deci citite înaintea restului fișierului principal, în ordine alfabetică. Acest lucru este practic: vă puneți setările proprii într-un fișier separat și lăsați fișierul principal neatins, astfel încât o actualizare a pachetului să nu vă afecteze modificările.

Are însă o consecință care îi surprinde pe mulți. În sshd_config se aplică regula: pentru fiecare setare contează prima valoare pe care o întâlnește sshd. Liniile ulterioare cu aceeași setare sunt ignorate. Cine scrie PasswordAuthentication no la sfârșitul fișierului sshd_config nu câștigă, așadar, în fața unui fișier din sshd_config.d care spune yes.

Capcana cloud-init

Multe imagini VPS sunt configurate la prima pornire de cloud-init. În funcție de modul în care sunt configurate imaginea și instalarea, cloud-init scrie un fișier precum /etc/ssh/sshd_config.d/50-cloud-init.conf, care conține de exemplu:

PasswordAuthentication yes

Deoarece acest fișier este citit înaintea fișierului principal, autentificarea cu parolă rămâne activă, indiferent ce scrieți în sshd_config. Nu presupuneți, ci verificați:

root@web1:~# grep -ri passwordauthentication /etc/ssh/sshd_config /etc/ssh/sshd_config.d/
/etc/ssh/sshd_config:#PasswordAuthentication yes
/etc/ssh/sshd_config.d/50-cloud-init.conf:PasswordAuthentication yes

Există două soluții curate: modificați acel fișier la no sau puneți setările dumneavoastră într-un fișier care vine mai devreme în ordinea alfabetică, de exemplu 00-beveiliging.conf. Un fișier 99-mijn.conf tocmai că nu funcționează, deoarece cloud-init a câștigat deja.

Setările care contează

Creați propriul fișier:

root@web1:~# nano /etc/ssh/sshd_config.d/00-beveiliging.conf

cu acest conținut:

# Autentificare doar cu cheie
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password

Ce înseamnă fiecare linie?

• PasswordAuthentication no: serverul nu mai acceptă parole. Valoarea implicită în OpenSSH este yes.
• KbdInteractiveAuthentication no: "keyboard-interactive" este o a doua modalitate de a cere o parolă, prin PAM. Dacă o lăsați activă, cineva poate încerca totuși o parolă, chiar dacă PasswordAuthentication este setat la no. În ghidurile mai vechi această setare se numește ChallengeResponseAuthentication; începând cu OpenSSH 8.7, acesta este un nume alternativ învechit pentru același lucru. Debian o setează implicit deja la no, dar scrieți-o totuși: astfel este clar și corect și pe alte sisteme.
• PermitRootLogin prohibit-password: root se poate autentifica, dar numai cu o cheie. Aceasta este valoarea implicită începând cu OpenSSH 7.0. Mai strict este PermitRootLogin no: root nu mai poate intra deloc prin SSH, vă autentificați ca utilizator obișnuit și folosiți sudo (lecția 3.2). Setați no abia când sunteți sigur că autentificarea ca acel utilizator și sudo funcționează.

Opțional, pentru cine dorește mai mult:

AllowUsers anna
AuthenticationMethods publickey

AllowUsers permite accesul doar utilizatorilor menționați; orice alt nume este refuzat, chiar dacă are o cheie validă. Este util, dar nu uitați să vă includeți pe dumneavoastră și nu uitați să completați lista când adăugați un al doilea administrator. AuthenticationMethods publickey spune într-o singură linie că sunt acceptate doar cheile.

Testare, aplicare, verificare

Mai întâi lăsați sshd să verifice fișierul. Această comandă nu pornește nimic și nu modifică nimic:

root@web1:~# sshd -t
root@web1:~#

Lipsa oricărui rezultat înseamnă: nicio eroare. În cazul unei greșeli de tastare vedeți linia și fișierul. Abia apoi reîncărcați serviciul:

root@web1:~# systemctl reload ssh

Pe Debian și Ubuntu serviciul se numește ssh, pe AlmaLinux și Rocky Linux sshd.

Apoi verificați ce valoare se aplică cu adevărat. sshd -T afișează configurația completă, calculată, cu toate fișierele Include procesate:

root@web1:~# sshd -T | grep -Ei 'passwordauth|kbdinteractive|permitrootlogin'
permitrootlogin without-password
passwordauthentication no
kbdinteractiveauthentication no

(without-password este vechiul nume pentru prohibit-password. Versiunile OpenSSH anterioare 10.1, precum cele de pe Debian 13 și Ubuntu 24.04, afișează încă vechiul nume; cele mai noi afișează prohibit-password. Înseamnă același lucru.)

Și acum partea cea mai importantă: testați într-o a doua fereastră, în timp ce prima rămâne deschisă.

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

Dacă funcționează, încercați intenționat să vă autentificați cu o parolă. Acest lucru trebuie să eșueze:

anna@laptop:~$ ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no anna@192.0.2.10
anna@192.0.2.10: Permission denied (publickey).

După Permission denied apar între paranteze metodele de autentificare pe care serverul le mai oferă. Dacă acolo apare doar publickey, totul este în regulă. Dacă apare și password sau keyboard-interactive, undeva se aplică încă o altă valoare: verificați din nou cu sshd -T.

Exact această listă o verifică și exercițiul din curs, din exterior. Clientul SSH întreabă la fiecare conexiune mai întâi ce metode sunt permise, printr-o cerere de tip "none". Serverul răspunde cu lista, fără să se încerce vreo parolă sau cheie.

Ubuntu 24.04 și versiunile ulterioare: ssh.socket

Pe Ubuntu, începând cu 22.10, pe portul 22 nu ascultă sshd însuși, ci systemd, prin ssh.socket. Abia când sosește o conexiune, systemd pornește serviciul SSH. Pentru setările din această lecție acest lucru nu contează: systemctl reload ssh sau restart ssh este suficient.

Contează însă când modificați portul sau adresa de ascultare (Port, ListenAddress). Începând cu Ubuntu 24.04, systemd citește aceste valori din sshd_config, dar numai după:

root@web1:~# systemctl daemon-reload
root@web1:~# systemctl restart ssh.socket

Dacă uitați acest lucru, serverul ascultă în continuare pe vechiul port. Mai rău: dacă setați mai întâi firewall-ul pe un port nou și SSH rămâne pe cel vechi, vă blocați singur accesul. Verificați întotdeauna cu ss -tlnp | grep ssh pe ce se ascultă cu adevărat (lecția 5.1) și deschideți noul port în firewall înainte de a-l închide pe cel vechi. Dacă un alt port are sens, aflați în lecția 2.3.

Dacă totuși ceva nu merge

Dacă nu mai puteți intra, deschideți consola furnizorului, vă autentificați ca root (cu parola, deoarece consola este o "tastatură conectată la server" și nu SSH) și anulați modificările din fișier:

root@web1:~# mv /etc/ssh/sshd_config.d/00-beveiliging.conf /root/
root@web1:~# systemctl reload ssh

Dacă nici asta nu reușește, restaurați snapshot-ul. La WebOké puteți seta și o parolă root nouă în ecranul VPS; alți furnizori au adesea un buton similar sau un mod de salvare (rescue).

Pe AlmaLinux și Rocky Linux

Serviciul se numește sshd (systemctl reload sshd). Și acolo se află un Include /etc/ssh/sshd_config.d/*.conf în partea de sus, iar sistemul livrează propriile fișiere în acel director; se aplică aceeași regulă "contează prima valoare". Dacă modificați portul, SELinux trebuie să permită și el acel port (semanage port -a -t ssh_port_t -p tcp 2222), iar firewalld trebuie să îl deschidă.

Rezumat

• În sshd_config contează prima valoare; fișierele din sshd_config.d sunt citite primele. Puneți setările dumneavoastră într-un fișier precum 00-beveiliging.conf.
• Setați PasswordAuthentication no și KbdInteractiveAuthentication no; root doar cu cheie (prohibit-password) sau deloc (no).
• Verificați cu sshd -t înainte de reîncărcare și cu sshd -T ce valoare se aplică cu adevărat; atenție la un 50-cloud-init.conf.
• Testați într-o a doua fereastră și păstrați prima sesiune deschisă. Cunoașteți consola și creați în prealabil un snapshot.
• Pe Ubuntu 24.04+ un alt port necesită systemctl daemon-reload și systemctl restart ssh.socket.

Test (quiz)

Exercițiu

Exercițiul Z2.2: Autentificarea cu parolă este dezactivată. Dezactivați autentificarea cu parolă și keyboard-interactive așa cum s-a arătat în această lecție, apoi lăsați programul să verifice din exterior. Introduceți adresa IP sau numele de gazdă al serverului dumneavoastră, portul SSH (implicit 22) și numele de utilizator cu care vă autentificați dumneavoastră (de exemplu anna, nu root sau un nume inventat). Programul nu se autentifică: întreabă doar, la fel ca orice client SSH înainte de autentificare, ce metode de autentificare oferă serverul dumneavoastră pentru acel utilizator. Rezultatul corect este: doar publickey.

Lecturi suplimentare

Pașii din aceste articole se aplică ecranului VPS de la WebOké; la alți furnizori funcționează în mod similar.

• Securizarea VPS-ului: primele cinci minute
• Nu mai aveți acces la VPS: ce faceți?
• Snapshoturi și backupuri pentru VPS
• Manualul sshd_config: https://man.openbsd.org/sshd_config
• Ubuntu: SSHd now uses socket-based activation: https://discourse.ubuntu.com/t/sshd-now-uses-socket-based-activation-ubuntu-22-10-and-later/30189