Acces SSH: Ghidul Tehnic Complet pentru Gestionarea Securizată a Serverelor de la Distanță

SSH (Secure Shell) este un protocol de rețea criptografic care stabilește un tunel criptat între două gazde conectate în rețea, permițând execuția autentificată a comenzilor, transferul de fișiere și redirecționarea porturilor prin rețele nesigure. Funcționează implicit pe portul TCP 22 și înlocuiește predecesorii în text simplu — Telnet, rsh și FTP — cu un protocol care oferă confidențialitate, integritate și autentificare mutuală într-un singur handshake.

Pentru orice administrator care gestionează un VPS sau un server dedicat, SSH nu este o infrastructură opțională — este planul principal de control. Fiecare decizie de configurare pe care o luați în jurul SSH afectează direct suprafața de atac a serverului dvs., fiabilitatea operațională și postura de conformitate.

Cum funcționează SSH: Arhitectura protocolului

Înțelegerea SSH la nivelul protocolului este ceea ce îi separă pe administratorii care îl configurează corect de cei care lasă lacune exploatabile.

Modelul cu trei straturi

SSH este definit de RFC 4251–4254 și funcționează pe trei substraturi distincte stivuite deasupra TCP:

• Protocolul stratului de transport SSH — gestionează autentificarea serverului, schimbul de chei, negocierea criptării și configurarea MAC (codul de autentificare a mesajelor). Aici are loc handshake-ul criptografic.
• Protocolul de autentificare a utilizatorului SSH — rulează deasupra stratului de transport și gestionează autentificarea client-server folosind metode precum publickey, password, keyboard-interactive sau gssapi-with-mic.
• Protocolul de conexiune SSH — multiplexează tunelul criptat în canale logice, fiecare transportând o sesiune shell, un subsistem SFTP, un port redirecționat sau o conexiune agent.

Handshake-ul în detaliu

Când rulați ssh user@host, următoarea secvență se execută înainte de a vedea un prompt:

1. Conexiunea TCP este stabilită la server pe portul configurat.
2. Schimbul de versiuni — clientul și serverul schimbă șiruri de versiuni ale protocolului (SSH-2.0-OpenSSH_9.x).
3. Negocierea algoritmului (SSH_MSG_KEXINIT) — ambele părți anunță algoritmii de schimb de chei suportați, tipurile de chei gazdă, cifrurile, MAC-urile și metodele de compresie. Prima opțiune suportată mutual din fiecare listă câștigă.
4. Schimbul de chei (KEX) — de obicei Diffie-Hellman sau Elliptic Curve Diffie-Hellman (ECDH). Ambele părți derivă un secret partajat fără a-l transmite. Aceasta produce chei de sesiune.
5. Verificarea cheii gazdă a serverului — serverul semnează o valoare cu cheia sa privată gazdă. Clientul verifică această semnătură față de fișierul său ~/.ssh/known_hosts. O nepotrivire declanșează un avertisment și blochează conexiunea implicit.
6. Criptarea activată — tot traficul ulterior este criptat și protejat ca integritate folosind cifrul negociat (de ex., chacha20-poly1305) și MAC.
7. Autentificarea utilizatorului — clientul încearcă autentificarea folosind metoda negociată. Cu autentificarea publickey, clientul semnează o provocare cu cheia sa privată; serverul verifică folosind cheia publică stocată.
8. Deschiderea canalului — un canal shell, subsistem SFTP sau exec este deschis și sesiunea începe.

Întregul proces se finalizează de obicei în mai puțin de 100 de milisecunde pe o rețea locală.

Criptografie simetrică vs. asimetrică în SSH

O concepție greșită comună este că SSH „folosește criptarea cu cheie publică” pentru tot traficul. Nu este cazul. Rolurile sunt distincte:

SSH vs. protocoalele de acces la distanță moștenite

Generarea perechilor de chei SSH

Perechile de chei SSH sunt fundamentul accesului securizat și scalabil la server. Autentificarea prin parolă este vulnerabilă la atacuri de forță brută și umplerea credențialelor; autentificarea bazată pe chei nu este.

Alegerea algoritmului de cheie potrivit

Ed25519 este cea mai bună practică actuală. Folosește criptografia cu curbă eliptică Curve25519, produce chei compacte de 256 de biți, este mai rapidă decât RSA la niveluri de securitate echivalente și este suportată de OpenSSH 6.5+ (lansat în 2014).

ssh-keygen -t ed25519 -C "admin@yourhost.example.com"

Folosiți RSA doar când aveți nevoie de compatibilitate cu sisteme moștenite care nu suportă Ed25519:

ssh-keygen -t rsa -b 4096 -C "admin@yourhost.example.com"

Nu folosiți DSA (limitat la 1024 de biți, compromis) sau ECDSA cu curbe NIST (îngrijorări privind proveniența parametrilor curbei NIST). Ed25519 este alegerea neechivocă pentru implementările noi.

Ghid de generare a cheilor

ssh-keygen -t ed25519 -C "ops-team-key-2025"

Vi se va solicita:

• Locația fișierului — implicit este ~/.ssh/id_ed25519. Acceptați implicit sau specificați o cale personalizată pentru medii cu mai multe chei.
• Fraza de acces — setați întotdeauna una. O frază de acces criptează cheia privată în repaus folosind AES-256-CBC (sau bcrypt cu OpenSSH mai nou). Dacă fișierul cheii private este furat, fraza de acces este ultima linie de apărare.

Aceasta produce două fișiere:

~/.ssh/id_ed25519 — cheia privată. Nu o partajați niciodată. Permisiunile trebuie să fie 600.
~/.ssh/id_ed25519.pub — cheia publică. Aceasta este ceea ce distribuiți serverelor.

Gestionarea mai multor chei cu ~/.ssh/config
Când gestionați mai multe servere sau conturi, folosiți un fișier de configurare SSH pentru a evita specificarea marcajelor la fiecare conexiune:
# ~/.ssh/config

Host prod-web
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519_prod
    Port 2222

Host staging
    HostName 203.0.113.20
    User ubuntu
    IdentityFile ~/.ssh/id_ed25519_staging
Cu aceasta în vigoare, ssh prod-web se extinde automat la parametrii completi de conexiune.
Implementarea cheii publice pe un server
Metoda 1: ssh-copy-id (Recomandat pentru configurarea inițială)
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your_server_ip
Aceasta adaugă cheia publică la ~/.ssh/authorized_keys pe gazda la distanță și setează automat permisiunile corecte.
Metoda 2: Implementare manuală (când ssh-copy-id nu este disponibil)
cat ~/.ssh/id_ed25519.pub | ssh user@your_server_ip 
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && 
   cat >> ~/.ssh/authorized_keys && 
   chmod 600 ~/.ssh/authorized_keys"
Metoda 3: Consola sau API-ul furnizorului cloud
Majoritatea furnizorilor cloud și panourilor de control de găzduire vă permit să injectați chei publice în timpul provizionării instanței. Aceasta este abordarea corectă pentru infrastructura automatizată — cheia este prezentă înainte ca instanța să pornească, eliminând problema oul-găina a necesității SSH pentru a implementa chei SSH.
Formatul fișierului authorized_keys
Fiecare linie din ~/.ssh/authorized_keys este o cheie publică, opțional prefixată cu opțiuni:
restrict,command="/usr/local/bin/backup.sh" ssh-ed25519 AAAA... backup-key
from="192.168.1.0/24" ssh-ed25519 AAAA... ops-key
Opțiunea restrict dezactivează redirecționarea porturilor, redirecționarea agentului și alocarea PTY pentru acea cheie — utilă pentru cheile de implementare sau conturile de automatizare a backup-urilor care nu ar trebui să aibă acces interactiv la shell.
Întărirea serverului SSH: /etc/ssh/sshd_config
O instalare implicită OpenSSH este funcțională, dar nu întărită. Următoarea configurație reprezintă o linie de bază de nivel producție. Aplicați modificările la /etc/ssh/sshd_config, apoi validați și reîncărcați:
sshd -t && systemctl reload sshd
Rulați întotdeauna sshd -t înainte de reîncărcare — o eroare de sintaxă în sshd_config nu va bloca daemonul care rulează, dar va împiedica repornirea acestuia după o repornire a sistemului, blocându-vă accesul.
Bloc de întărire recomandat pentru sshd_config
# /etc/ssh/sshd_config - Production hardening baseline

Port 2222
AddressFamily inet
ListenAddress 0.0.0.0

# Host keys - prefer Ed25519
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

# Cryptographic hardening
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

# Authentication
PermitRootLogin no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM yes

# Session hardening
LoginGraceTime 30
MaxAuthTries 3
MaxSessions 5
ClientAliveInterval 300
ClientAliveCountMax 2
TCPKeepAlive no

# Disable unused features
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no
GatewayPorts no

# Restrict access
AllowUsers deploy ops-user
Banner /etc/ssh/banner.txt
Decizii critice de întărire explicate
PermitRootLogin no — Autentificarea root prin SSH este o țintă de mare valoare. Folosiți un utilizator obișnuit și escaladați cu sudo. Dacă aveți absolut nevoie de acces echivalent root printr-o cheie specifică (de ex., pentru automatizare), folosiți PermitRootLogin prohibit-password pentru a permite autentificarea root numai prin cheie, blocând în același timp tentativele cu parolă.
AllowTcpForwarding no — Dacă serverul dvs. nu este un bastion sau un host de salt, dezactivați redirecționarea TCP. Un atacator cu o sesiune SSH validă ar putea altfel folosi serverul dvs. ca proxy pentru a accesa resursele rețelei interne.
TCPKeepAlive no cu ClientAliveInterval — TCPKeepAlive funcționează la stratul TCP și este vizibil pentru intermediarii de rețea. ClientAliveInterval trimite mesaje keepalive prin canalul SSH criptat, ceea ce este atât mai fiabil, cât și mai privat.
LoginGraceTime 30 — Reduce fereastra în care o conexiune neautentificată ocupă un slot de server. Valoarea implicită de 120 de secunde este excesivă.
AllowUsers — Includeți în lista albă doar conturile care au nevoie legitimă de acces SSH. Aceasta este o poartă dură care funcționează înainte de orice tentativă de autentificare.
Schimbarea portului SSH implicit
Mutarea SSH de pe portul 22 nu îmbunătățește securitatea împotriva unui atacator țintit — orice scanare de porturi îl va găsi. Ceea ce face este să elimine volumul enorm de boți automatizați, oportuniști de forță brută care atacă exclusiv portul 22. Aceasta reduce semnificativ zgomotul din jurnale și sarcina serverului.
# In /etc/ssh/sshd_config
Port 2222
Înainte de reîncărcare, deschideți noul port în firewall-ul dvs.:
# UFW
ufw allow 2222/tcp
ufw delete allow 22/tcp

# firewalld
firewall-cmd --permanent --add-port=2222/tcp
firewall-cmd --permanent --remove-service=ssh
firewall-cmd --reload

# iptables
iptables -A INPUT -p tcp --dport 2222 -j ACCEPT
iptables -D INPUT -p tcp --dport 22 -j ACCEPT
Dacă serverul dvs. rulează SELinux, trebuie să actualizați și contextul portului SELinux:
semanage port -a -t ssh_port_t -p tcp 2222
Conectarea la un server
Conexiune de bază
ssh user@your_server_ip
Conectarea la un port non-implicit
ssh -p 2222 user@your_server_ip
Conectarea cu o cheie specifică
ssh -i ~/.ssh/id_ed25519_prod user@your_server_ip
Modul verbose pentru depanare
ssh -vvv user@your_server_ip
Marcajul -vvv afișează fiecare pas al handshake-ului, tentativei de autentificare și negocierii canalului. Este primul instrument la care să apelați când o conexiune eșuează în mod neașteptat.
Transferuri securizate de fișiere prin SSH
SCP (Secure Copy Protocol)
SCP este un instrument simplu, neinteractiv de copiere a fișierelor. Este rapid și disponibil pe scară largă, dar nu are capacitate de reluare și gestionare limitată a erorilor.
Copiați un fișier local pe un server la distanță:
scp -P 2222 /local/path/file.tar.gz user@your_server_ip:/remote/path/
Copiați un fișier de la distanță local:
scp -P 2222 user@your_server_ip:/remote/path/file.tar.gz /local/path/
Copiere recursivă a directorului:
scp -rp -P 2222 /local/directory/ user@your_server_ip:/remote/directory/
Notă: Proiectul OpenSSH a depreciat protocolul SCP moștenit în OpenSSH 9.0. Modernul scp folosește acum protocolul SFTP implicit. Interfața de comandă rămâne aceeași, dar transportul de bază este mai robust.
SFTP (SSH File Transfer Protocol)
SFTP este un subsistem de transfer de fișiere cu funcționalitate completă, cu listare de directoare, gestionarea permisiunilor și suport pentru reluare. Este alegerea corectă pentru gestionarea interactivă a fișierelor.
sftp -P 2222 user@your_server_ip
Comenzi SFTP comune în cadrul sesiunii interactive:
sftp> ls -la                          # List remote directory
sftp> lls                             # List local directory
sftp> put localfile.txt /remote/path/ # Upload file
sftp> get /remote/file.txt ./         # Download file
sftp> mput *.log /remote/logs/        # Upload multiple files
sftp> mkdir /remote/newdir            # Create remote directory
sftp> chmod 640 /remote/file.txt      # Change remote permissions
sftp> bye                             # Exit
rsync prin SSH (Recomandare pentru producție)
Pentru sincronizarea directoarelor, backup-uri incrementale sau seturi mari de date, rsync prin SSH este semnificativ mai eficient decât SCP sau SFTP. Transferă doar blocurile modificate, nu fișierele întregi.
rsync -avz --progress -e "ssh -p 2222 -i ~/.ssh/id_ed25519" 
  /local/data/ user@your_server_ip:/remote/data/
Marcajul -z activează compresia în tranzit. Pentru datele deja comprimate (arhive, imagini), omiteți-l — compresia datelor comprimate irosește CPU fără a reduce dimensiunea transferului.
Redirecționarea porturilor SSH și tunelarea
Redirecționarea porturilor este una dintre cele mai puternice și subutilizate capabilități ale SSH. Vă permite să accesați în siguranță servicii care nu sunt expuse direct la internet.
Redirecționarea portului local
Redirecționați un port local către un serviciu la distanță. Exemplu: accesați o instanță MySQL la distanță (portul 3306) care este legată la localhost pe server:
ssh -L 3307:127.0.0.1:3306 user@your_server_ip -N
Acum mysql -h 127.0.0.1 -P 3307 pe mașina dvs. locală se conectează prin tunelul criptat la MySQL-ul de la distanță.
Redirecționarea portului la distanță
Expuneți un serviciu local serverului la distanță. Util pentru testarea webhook-urilor sau partajarea unui server de dezvoltare local:
ssh -R 8080:127.0.0.1:3000 user@your_server_ip -N
Redirecționarea dinamică a portului (proxy SOCKS)
Transformați conexiunea SSH într-un proxy SOCKS5, rutând traficul TCP arbitrar prin server:
ssh -D 1080 user@your_server_ip -N
Configurați browserul sau aplicația să folosească SOCKS5 127.0.0.1:1080.
Agentul SSH și redirecționarea agentului
ssh-agent păstrează cheile private decriptate în memorie, astfel încât să nu trebuiască să reintroduceți fraza de acces la fiecare conexiune.
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
Redirecționarea agentului (ssh -A) permite unui server la distanță să folosească agentul dvs. local pentru a se autentifica la un al treilea server. Aceasta este utilă pentru arhitecturile de host bastion, dar prezintă riscuri: un utilizator root pe serverul intermediar poate folosi socket-ul agentului dvs. redirecționat. Preferați ProxyJump în schimb:
ssh -J bastion.example.com user@internal-server.example.com
ProxyJump rutează conexiunea TCP prin bastion fără a vă expune agentul la acesta.
Depanarea problemelor comune SSH
Conexiune refuzată (ssh: connect to host ... port 22: Connection refused)
Diagnostic sistematic:

Verificați că daemonul SSH rulează: systemctl status sshd

• Confirmați portul de ascultare: ss -tlnp | grep sshd
• Verificați regulile firewall-ului: ufw status sau iptables -L -n | grep 22
• Verificați că serverul este accesibil la nivel de rețea: ping your_server_ip
• Dacă folosiți un furnizor cloud, verificați regulile grupului de securitate sau ACL-urile de rețea în consola furnizorului.

Permisiune refuzată (publickey)

Aceasta este cea mai frecventă eroare SSH. Parcurgeți această listă de verificare:

# On the server, check authorized_keys permissions
ls -la ~/.ssh/
stat ~/.ssh/authorized_keys

# Fix permissions if wrong
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh

# Verify the public key is actually present
cat ~/.ssh/authorized_keys

# Check sshd logs for the specific rejection reason
journalctl -u sshd -n 50 --no-pager
# or
tail -50 /var/log/auth.log

Cauze comune dincolo de permisiuni:

• Fișierul authorized_keys conține cheia greșită (de ex., ați copiat cheia privată în loc de fișierul .pub).

StrictModes yes în sshd_config (implicit) respinge conexiunile dacă permisiunile directorului home sunt prea deschise — chmod 755 ~ este maximul permis.
AllowUsers sau AllowGroups în sshd_config exclude utilizatorul care se conectează.
SELinux blochează accesul la ~/.ssh/ — verificați ausearch -m avc -ts recent.

Timeout la conexiunea SSH
# In /etc/ssh/sshd_config (server side)
ClientAliveInterval 60
ClientAliveCountMax 3

# In ~/.ssh/config (client side)
Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3
ClientAliveInterval trimite un pachet nul prin canalul SSH criptat la fiecare 60 de secunde. După ClientAliveCountMax răspunsuri ratate consecutive, serverul termină conexiunea. Aceasta previne acumularea sesiunilor zombie.
Verificarea cheii gazdă a eșuat
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
Acest avertisment înseamnă că cheia gazdă a serverului nu mai corespunde cu ceea ce este stocat în ~/.ssh/known_hosts. Cauzele legitime includ reinstalarea serverului sau reasignarea adresei IP. Cauzele malițioase includ un atac man-in-the-middle. Investigați înainte de a continua.
Dacă ați confirmat că serverul a fost reinstalat în mod legitim:
ssh-keygen -R your_server_ip
Apoi reconectați-vă și verificați amprenta noii chei gazdă față de consola serverului sau tabloul de bord al furnizorului înainte de a o accepta.
Autentificarea cu mai mulți factori pentru SSH
Autentificarea bazată pe chei este puternică, dar adăugarea unui al doilea factor TOTP (Parolă unică bazată pe timp) creează apărare în profunzime. Chiar dacă o cheie privată și fraza sa de acces sunt compromise, un atacator nu se poate autentifica fără tokenul TOTP.
Instalați și configurați libpam-google-authenticator pe server:
apt install libpam-google-authenticator
google-authenticator
Apoi configurați PAM și sshd_config:
# /etc/pam.d/sshd - add this line
auth required pam_google_authenticator.so

# /etc/ssh/sshd_config
UsePAM yes
ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive
Cu AuthenticationMethods publickey,keyboard-interactive, un utilizator trebuie să furnizeze o cheie validă ȘI un cod TOTP. Aceasta este configurația corectă de producție pentru serverele de mare valoare.
Autoritatea de certificare SSH: Scalarea gestionării cheilor
În mediile cu zeci de servere și mai mulți administratori, gestionarea intrărilor individuale authorized_keys devine operațional nesustenabilă. Certificatele SSH rezolvă această problemă.
O Autoritate de Certificare (CA) SSH semnează cheile utilizatorilor și gazdelor. Serverele au încredere în cheia publică a CA mai degrabă decât în cheile individuale ale utilizatorilor. Adăugarea unui nou administrator necesită doar semnarea cheii lor publice — fără modificări la fișierul authorized_keys al niciunui server.
# Create a CA key pair (store the private key offline or in a secrets manager)
ssh-keygen -t ed25519 -f /etc/ssh/ca_key -C "infrastructure-ca-2025"

# Sign a user's public key, valid for 7 days, for specific principals
ssh-keygen -s /etc/ssh/ca_key 
  -I "alice-ops-cert" 
  -n alice,deploy 
  -V +7d 
  ~/.ssh/id_ed25519.pub
Pe fiecare server, configurați încrederea pentru CA:
# /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/ca_key.pub
Acesta este modul în care infrastructura la scară largă (inclusiv furnizorii cloud și întreprinderile) gestionează accesul SSH fără gestionarea cheilor per-server.
Matricea de decizie practică: Configurarea SSH pe caz de utilizare



Caz de utilizare
Tip de cheie
Port
Autentificare prin parolă
Autentificare root
Redirecționare
MFA








—
—
—
—
—
—
—








VPS personal
Ed25519
2222+
Dezactivată
Interzisă
Dezactivată
Opțional








Server web de producție
Ed25519
Non-implicit
Dezactivată
Nu
Dezactivată
Obligatoriu








Bastion / host de salt
Ed25519
22 sau personalizat
Dezactivată
Nu
Controlată
Obligatoriu








Automatizare CI/CD
Ed25519 (cheie de implementare)
Non-implicit
Dezactivată
Nu
Dezactivată
Nu (doar cheie)








Server de baze de date
Ed25519
Non-implicit
Dezactivată
Nu
Doar local
Obligatoriu








Server de dezvoltare
Ed25519
Implicit sau personalizat
Opțională
Nu
Opțională
Opțional





Configurarea SSH pe infrastructura AlexHost
Când provizionați un VPS sau un server dedicat prin AlexHost, accesul SSH este configurat implicit. Parola root inițială este livrată prin e-mailul de provizionare, iar prima acțiune recomandată este să:

Vă autentificați ca root, să creați un utilizator administrativ non-root și să adăugați cheia dvs. publică la ~/.ssh/authorized_keys al acelui utilizator.
Aplicați linia de bază de întărire sshd_config documentată mai sus.
Dezactivați autentificarea prin parolă și autentificarea root.
Configurați firewall-ul dvs. pentru a restricționa accesul SSH la intervalele IP cunoscute, acolo unde este fezabil operațional.

Dacă preferați un strat de gestionare grafică alături de SSH, opțiunile VPS cu cPanel și Panouri de control VPS ale AlexHost oferă o interfață web pentru sarcini comune, lăsând SSH disponibil pentru control administrativ complet.
Pentru mediile în care trebuie să securizați aplicațiile web care rulează pe același server, combinarea întăririi SSH cu un certificat SSL configurat corespunzător acoperă atât straturile de transport administrativ, cât și cel al aplicației.
Listă de verificare a punctelor cheie tehnice
Înainte de a considera configurația SSH pregătită pentru producție, verificați fiecare dintre următoarele:
Gestionarea cheilor

Cheile private folosesc Ed25519 sau RSA-4096 minimum
Toate cheile private sunt protejate cu o frază de acces puternică
Directorul ~/.ssh/ are permisiuni 700; authorized_keys are 600

• Cheile de implementare folosesc opțiunile restrict și command= unde este aplicabil
• Programul de rotație a cheilor este documentat și aplicat

Configurarea serverului

PasswordAuthentication no este setat și activ
PermitRootLogin no sau prohibit-password este aplicat
SSH rulează pe un port non-implicit cu regulile firewall-ului actualizate
AllowUsers sau AllowGroups restricționează accesul la conturile nominalizate
LoginGraceTime este setat la 30 de secunde sau mai puțin
sshd -t trece fără erori după fiecare modificare de configurare

Întărire criptografică

KexAlgorithms exclude diffie-hellman-group1-sha1 și diffie-hellman-group14-sha1

• Ciphers exclude 3des-cbc, arcfour și blowfish-cbc
• MACs folosește doar variante -etm (encrypt-then-MAC)

Securitate operațională

• Jurnalele de autentificare SSH sunt monitorizate (/var/log/auth.log sau journalctl -u sshd)
• fail2ban sau echivalentul este configurat pentru a bloca eșecurile repetate de autentificare
• Amprentele cheilor gazdă sunt înregistrate și stocate în afara benzii pentru verificare
• MFA este activat pentru toate sesiunile interactive ale utilizatorilor pe sistemele de producție
• CA SSH este utilizat pentru mediile cu mai mult de cinci servere sau trei administratori

Întrebări frecvente

Care este diferența dintre cheile SSH și certificatele SSH?

Cheile SSH necesită ca fiecare server să stocheze cheia publică a utilizatorului în authorized_keys. Certificatele SSH sunt semnate de o Autoritate de Certificare; serverele au încredere în CA mai degrabă decât în cheile individuale. Certificatele se scalează la flote mari fără gestionarea cheilor per-server și suportă timpuri de expirare, făcând revocarea simplă.

De ce apare Permission denied (publickey) chiar și când cheia este corectă?

Cele mai frecvente cauze sunt permisiunile incorecte ale fișierelor pe ~/.ssh/ (trebuie să fie 700) sau authorized_keys (trebuie să fie 600), un director home care este accesibil tuturor (blocat de StrictModes) sau o directivă AllowUsers în sshd_config care exclude contul care se conectează. Verificați journalctl -u sshd pe server pentru motivul specific al respingerii.

Este schimbarea portului SSH de la 22 o măsură reală de securitate?

Elimină atacurile automate oportuniste care vizează portul 22, ceea ce reduce semnificativ zgomotul din jurnale și tentativele de autentificare eșuate. Nu protejează împotriva unui atacator țintit care efectuează o scanare de porturi. Ar trebui combinat cu fail2ban, autentificarea numai prin cheie și lista albă IP a firewall-ului pentru o îmbunătățire semnificativă a securității.

Pot folosi SSH fără o adresă IP statică pe partea clientului?

Da. Autentificarea bazată pe chei nu necesită un IP fix al clientului. Dacă doriți să restricționați prin IP, folosiți opțiunea from= în authorized_keys sau regulile firewall-ului. Pentru IP-uri dinamice, luați în considerare un VPN pentru a stabili o identitate de rețea stabilă înainte de conectare, în loc să deschideți SSH la întregul internet.

Care este cel mai sigur mod de a recupera accesul SSH dacă sunt blocat?

Accesați serverul prin consola out-of-band a furnizorului dvs. de găzduire (VNC, IPMI sau KVM over IP). De acolo, montați sistemul de fișiere, corectați problema sshd_config sau authorized_keys și reporniți daemonul SSH. Pe planurile de VPS și server dedicat AlexHost, consola furnizorului este disponibilă prin portalul clientului și nu depinde de funcționalitatea SSH.