SSH megerősítés 2026-ban: OpenSSH 10, posztkvantum titkosítás és modern védelmi stratégiák

Bevezetés

Az SSH (Secure Shell) protokoll több mint két évtizede a Linux rendszerek távoli elérésének és adminisztrációjának alapköve. 2026-ban szinte minden szerver, felhőinfrastruktúra és DevOps munkafolyamat az SSH-ra támaszkodik — legyen szó egyetlen VPS-ről vagy több ezer csomópontot számláló Kubernetes-klaszterről. Ezzel együtt viszont az SSH az egyik leggyakrabban támadott szolgáltatás is: a statisztikák szerint a Linux-végpontok elleni támadások mintegy 89%-a brute force módszerrel, jellemzően SSH-n keresztül történik.

Ez elég ijesztő szám, nem?

2025-ben mintegy 16 milliárd kiszivárgott hitelesítő adatot tartalmazó adatbázis került nyilvánosságra, amit a támadók automatizált credential stuffing eszközökkel használnak ki nap mint nap. A jelszavak 94%-a újra felhasználásra kerül különböző szolgáltatásoknál, és a biztonsági incidensek 22%-ában ellopott vagy gyenge jelszó volt a belépési pont. Ezek fényében az SSH megerősítése nem opcionális — hanem alapvető szükséglet.

Ebben az útmutatóban végigmegyünk az SSH biztonságának minden fontos aspektusán a 2026-os állapotnak megfelelően: az OpenSSH 10.x újításaitól a posztkvantum kriptográfián át a tanúsítványalapú hitelesítésig, a FIDO2 hardverkulcsokig, a CrowdSec kollektív védelemig és a Fail2Ban konfigurációig. Gyakorlati kódrészletek és konfigurációs példák is lesznek, szóval azonnal hasznosíthatod a tudást.

Az OpenSSH 10.x: paradigmaváltás a kriptográfiában

2025 áprilisában jelent meg az OpenSSH 10.0, és őszintén szólva ez nem egy szokásos verziófrissítés volt — hanem alapvető architekturális és kriptográfiai váltás. Nézzük, mit hozott az új korszak.

Posztkvantum kulcscsere alapértelmezettként

Az OpenSSH 10.0 talán legjelentősebb újítása, hogy a mlkem768x25519-sha256 algoritmust tette alapértelmezett kulcscsere-mechanizmussá. Ez egy hibrid megoldás, ami két algoritmust kombinál:

• ML-KEM (mlkem768) — a NIST által 2024-ben szabványosított posztkvantum kulcskapszulázási mechanizmus, ami ellenáll a kvantumszámítógépes támadásoknak
• X25519 — széles körben elfogadott elliptikus görbe Diffie-Hellman módszer a klasszikus rendszerekkel való kompatibilitás biztosítására

Ez az első alkalom, hogy posztkvantum hibrid mechanizmus alapértelmezettként aktív egy mainstream SSH-implementációban. A gyakorlati jelentősége hatalmas: még ha egy támadó ma rögzíti a titkosított SSH-forgalmat, a jövőben sem lesz képes kvantumszámítógéppel visszafejteni azt. Ez az úgynevezett „harvest now, decrypt later" támadási stratégia elleni védekezés — és hidd el, ez valós fenyegetés, nem sci-fi.

A DSA támogatás végleges eltávolítása

Az OpenSSH 10.0 véglegesen eltávolította a DSA (Digital Signature Algorithm) támogatását. A DSA kulcsok maximálisan 1024 bitesek lehettek, ami a mai szabványok szerint elfogadhatatlanul gyenge. Ha még mindig DSA-kulcsokat használsz valahol, itt az ideje átállni Ed25519-re vagy legalább RSA-3072-re. Komolyan.

OpenSSH 10.1: figyelmeztetések gyenge algoritmusokra

Az OpenSSH 10.1 bevezette a gyenge kriptográfiai algoritmusokra vonatkozó figyelmeztetési rendszert. Ha egy SSH-kapcsolat nem használ posztkvantum kulcscsere-algoritmust, a kliens figyelmeztetést jelenít meg. Ezt a viselkedést a WarnWeakCrypto opcióval szabályozhatod az ssh_config-ban:

# Figyelmeztetés engedélyezése gyenge kriptográfia használata esetén
# ~/.ssh/config vagy /etc/ssh/ssh_config
Host *
    WarnWeakCrypto yes

Az ssh-agent socket áthelyezése

Egy fontos (és könnyen észrevétlen) változás az OpenSSH 10.1-ben, hogy az ssh-agent socketeket a /tmp-ből a ~/.ssh/agent könyvtárba helyezték át. Ez növeli az izolációt és megakadályozza, hogy korlátozott fájlrendszeri hozzáféréssel rendelkező folyamatok hozzáférjenek a kulcsokhoz. Új kapcsolók (-U, -u, -uu, -T) segítenek a régi socketek takarításában.

Az sshd_config megerősítése: átfogó konfiguráció

Az SSH szerver konfigurációja (/etc/ssh/sshd_config) az első és legfontosabb védelmi vonal. Álljon itt egy produkciós környezethez ajánlott, átfogó konfiguráció magyarázatokkal.

Alapvető biztonsági beállítások

# /etc/ssh/sshd_config — Megerősített konfiguráció 2026

# Port megváltoztatása (security through obscurity, de csökkenti a bot-forgalmat)
Port 2222

# Csak IPv4 használata, ha IPv6 nem szükséges
AddressFamily inet

# Protokoll verzió (SSH-2 az egyetlen biztonságos opció)
Protocol 2

# Root bejelentkezés tiltása
PermitRootLogin no

# Jelszavas hitelesítés tiltása — csak kulcsalapú
PasswordAuthentication no
PermitEmptyPasswords no

# Challenge-response hitelesítés tiltása
KbdInteractiveAuthentication no

# Csak meghatározott felhasználók/csoportok engedélyezése
AllowGroups ssh-users
# AllowUsers admin deployer

# Maximális hitelesítési kísérletek
MaxAuthTries 3

# Maximális egyidejű nem hitelesített kapcsolatok
MaxStartups 10:30:60

# Hitelesítési időkorlát (másodpercben)
LoginGraceTime 30

# Munkamenet időtúllépés
ClientAliveInterval 300
ClientAliveCountMax 2

# X11 forwarding tiltása (ha nem szükséges)
X11Forwarding no

# Agent forwarding tiltása (biztonsági kockázat)
AllowAgentForwarding no

# TCP forwarding tiltása (hacsak nem szükséges)
AllowTcpForwarding no

# Banner megjelenítése
Banner /etc/ssh/banner.txt

Na, az alapbeállítások megvannak. De ez csak a fele a történetnek.

Kriptográfiai beállítások megerősítése

A kriptográfiai algoritmusok helyes beállítása kritikus fontosságú. 2026-ban az alábbi konfigurációt ajánlom:

# Kulcscsere-algoritmusok — posztkvantum hibridek és erős klasszikus módszerek
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256,[email protected],diffie-hellman-group16-sha512,diffie-hellman-group18-sha512

# Titkosítók — kizárólag 256 bites AES és ChaCha20
Ciphers [email protected],[email protected],aes256-ctr

# MAC algoritmusok — kizárólag erős hash függvények
MACs [email protected],[email protected]

# Host kulcs algoritmusok
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256

# Minimális RSA kulcsméret
RequiredRSASize 3072

A RequiredRSASize 3072 beállítás különösen fontos: a 2048 bites RSA kulcsok ma még elfogadhatóak, de a kvantumszámítógépes fenyegetések fényében a 3072 bit az ajánlott minimum. Az Ed25519 kulcsok természetesen ennél is jobbak (és az a személyes tapasztalatom, hogy gyorsabbak is érezhetően).

A konfiguráció érvényesítése

Mielőtt újraindítanánk az SSH szolgáltatást, mindig ellenőrizzük a konfigurációt. Volt már, hogy egy elgépelés miatt kizártam magam a szerverről — ne járj úgy, mint én.

# Szintaktikai ellenőrzés
sudo sshd -t

# Ha nincs hiba, újraindítás
sudo systemctl reload sshd

# Fontos: NE használj restart-ot, ha éppen SSH-n keresztül vagy bejelentkezve!
# A reload a meglévő kapcsolatokat nem szakítja meg.

SSH kulcskezelés: a modern megközelítés

A kulcsalapú hitelesítés az SSH biztonság alapja, de nem mindegy, milyen kulcsokat használunk és hogyan kezeljük őket.

Ed25519 kulcsok generálása

2026-ban az Ed25519 az ajánlott kulcstípus a legtöbb felhasználási esetben. Gyors, biztonságos, és a kulcsok rövidebbek, mint az RSA-nál:

# Ed25519 kulcspár generálása erős jelszóvédelemmel
ssh-keygen -t ed25519 -a 100 -C "felhasznalo@szerver - 2026-02"

# Az -a 100 kapcsoló 100 KDF (Key Derivation Function) iterációt állít be,
# ami megnehezíti a jelszó brute force-olását, ha a privát kulcs kiszivárog

# RSA kulcs generálása (ha kompatibilitási okokból szükséges)
ssh-keygen -t rsa -b 4096 -a 100 -C "felhasznalo@szerver - 2026-02"

A kulcsok biztonságos telepítése

# Publikus kulcs másolása a távoli szerverre
ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]

# A fájlengedélyek manuális ellenőrzése a szerveren
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R felhasznalo:felhasznalo ~/.ssh

SSH konfiguráció a kliens oldalon

A kliens oldali ~/.ssh/config fájl használata rengeteget egyszerűsít az életeden. Ha még nem használsz ilyet, most érdemes elkezdeni:

# ~/.ssh/config — Kliens oldali konfiguráció

# Globális beállítások
Host *
    # Posztkvantum kulcscsere preferálása
    KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256
    # Erős titkosítók
    Ciphers [email protected],[email protected]
    # Szerverhitelesítés ellenőrzése
    StrictHostKeyChecking ask
    # Kulcs azonosítók
    IdentitiesOnly yes
    # Agent forwarding alapértelmezetten tiltva
    ForwardAgent no
    # Figyelmeztetés gyenge kriptográfiára
    WarnWeakCrypto yes

# Példa: Produkciós szerver bastion host-on keresztül
Host prod-web
    HostName 10.0.1.50
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_prod
    ProxyJump bastion.cegem.hu

# Bastion host konfiguráció
Host bastion.cegem.hu
    User bastion-user
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_bastion

FIDO2 hardverkulcsok: a fizikai biztonság ereje

A FIDO2 (Fast Identity Online 2) hardverkulcsok — mint a YubiKey — 2026-ban az SSH-hitelesítés aranystandardjának számítanak. A lényeg egyszerű: a privát kulcs soha nem hagyja el a hardvereszközt, és minden művelethez fizikai érintés (plusz opcionálisan PIN) szükséges.

Saját tapasztalatból mondom: amióta YubiKey-t használok, sokkal nyugodtabban alszom.

FIDO2 SSH kulcs generálása

# Ed25519-SK kulcs generálása YubiKey-jel (nem rezidens)
ssh-keygen -t ed25519-sk -C "felhasznalo@szerver FIDO2"

# Rezidens kulcs (a YubiKey-en tárolva, hordozható)
ssh-keygen -t ed25519-sk -O resident -O verify-required -C "felhasznalo FIDO2 rezidens"

# A verify-required kapcsoló PIN-kódot is megkövetel minden használatkor
# Ez a legbiztonságosabb mód: fizikai érintés + PIN

A rezidens és nem rezidens kulcsok közötti különbség:

• Nem rezidens (alapértelmezett) — A hardverkulcs privát kulcsára mutató handle a lemezen tárolódik (~/.ssh/id_ed25519_sk). A kulcs használatához szükséges a fájl és a hardvereszköz is.
• Rezidens (-O resident) — A teljes kulcs a hardvereszközön tárolódik. Bármelyik gépről használható, ahol csatlakoztatod a YubiKey-t. Több munkaállomás esetén ez az ideális megoldás.

Fontos gyakorlati tanácsok

• Vásárolj két hardverkulcsot — egy elsődlegest és egy tartalékot (hidd el, nem akarsz kulcs nélkül maradni)
• Mindkettővel generálj kulcspárt és telepítsd mindkét publikus kulcsot a szerverekre
• Használj erős, egyedi PIN-kódot a FIDO2 kulcsokhoz
• Kerüld az ssh -A (agent forwarding) opciót, hacsak nem feltétlenül szükséges

SSH tanúsítványalapú hitelesítés: vállalati szintű megoldás

A hagyományos authorized_keys fájlok kezelése néhány szerver felett még működik, de százas vagy ezres nagyságrendnél egyszerűen fenntarthatatlan. Az SSH tanúsítványalapú hitelesítés megoldja ezt a problémát egy belső Certificate Authority (CA) segítségével.

A koncepció

A működési elv meglepően egyszerű: létrehozunk egy CA kulcspárt, amellyel aláírjuk a felhasználók és hosztok nyilvános kulcsait. A szerverek a CA nyilvános kulcsát ismerik, és bármely, a CA által aláírt érvényes tanúsítványt elfogadják. Nincs szükség az egyes felhasználói kulcsok manuális telepítésére, ami mondjuk 200 szerverre egyenként elég nyűgös lenne.

CA létrehozása és tanúsítványok kiállítása

# 1. lépés: Külön CA létrehozása felhasználókhoz és hosztokhoz
ssh-keygen -t ed25519 -f /etc/ssh/ca/user_ca -C "SSH User CA"
ssh-keygen -t ed25519 -f /etc/ssh/ca/host_ca -C "SSH Host CA"

# A CA privát kulcsait rendkívül biztonságosan kell tárolni!
chmod 600 /etc/ssh/ca/user_ca /etc/ssh/ca/host_ca

# 2. lépés: Felhasználói tanúsítvány kiállítása (1 napig érvényes)
ssh-keygen -s /etc/ssh/ca/user_ca \
    -I "felhasznalo_janos_20260222" \
    -n janos \
    -V +1d \
    /home/janos/.ssh/id_ed25519.pub

# Paraméterek magyarázata:
# -s: aláíró (CA) privát kulcs
# -I: tanúsítvány azonosító (naplózáshoz)
# -n: principal (felhasználónév, amellyel bejelentkezhet)
# -V: érvényességi idő (+1d = 1 nap, +1h = 1 óra, +52w = 1 év)

# 3. lépés: Hoszt tanúsítvány kiállítása (1 évig érvényes)
ssh-keygen -s /etc/ssh/ca/host_ca \
    -I "web-szerver-01" \
    -h \
    -n web-szerver-01.cegem.hu \
    -V +52w \
    /etc/ssh/ssh_host_ed25519_key.pub

Szerver konfigurálása a CA megbízhatóságához

# /etc/ssh/sshd_config kiegészítése

# Felhasználói CA megbízhatósága
TrustedUserCAKeys /etc/ssh/ca/user_ca.pub

# Hoszt tanúsítvány megadása
HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub

# Opcionális: AuthorizedPrincipalsFile a finomhangolt hozzáférés-szabályozáshoz
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

# /etc/ssh/auth_principals/deploy fájl tartalma:
# Meghatározza, mely principal-ok léphetnek be a "deploy" felhasználóként
web-deploy
ci-cd-pipeline

Kliens konfigurálása hoszt-tanúsítvány ellenőrzéséhez

# ~/.ssh/known_hosts fájlba a CA nyilvános kulcsa
@cert-authority *.cegem.hu ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIxyz... SSH Host CA

# Ezzel minden *.cegem.hu hoszt automatikusan megbízhatóvá válik,
# ha a CA által aláírt érvényes tanúsítvánnyal rendelkezik.
# Nincs többé "Are you sure you want to continue connecting?" kérdés!

Automatizálás HashiCorp Vault segítségével

Nagyobb környezetekben a HashiCorp Vault SSH Secrets Engine kitűnő megoldás a tanúsítványkiállítás automatizálására. Ha már használod a Vault-ot más célokra, ez szinte magától adódik:

# Vault SSH CA motor engedélyezése
vault secrets enable -path=ssh-client-signer ssh

# CA konfigurálása
vault write ssh-client-signer/config/ca generate_signing_key=true

# Szerep létrehozása
vault write ssh-client-signer/roles/admin-role <<EOH
{
  "algorithm_signer": "rsa-sha2-256",
  "allow_user_certificates": true,
  "allowed_users": "deploy,admin",
  "default_extensions": {
    "permit-pty": ""
  },
  "key_type": "ca",
  "default_user": "deploy",
  "ttl": "30m",
  "max_ttl": "24h"
}
EOH

# Tanúsítvány igénylése (a felhasználó hajtja végre)
vault write ssh-client-signer/sign/admin-role \
    public_key=@$HOME/.ssh/id_ed25519.pub

Behatolásvédelem: Fail2Ban és CrowdSec

Még a legjobban megerősített SSH konfiguráció mellett is fontos az aktív behatolásvédelem. Mert ugye hiába van vasalt ajtód, ha nem figyeled, ki kopogtat rajta. 2026-ban két fő megoldás áll rendelkezésünkre: a veterán Fail2Ban és a modern CrowdSec.

Fail2Ban: az egyszerű és bevált megoldás

A Fail2Ban 2004 óta védi a szervereket, és még mindig remekül működik az egyszerű SSH brute force elleni védelemhez:

# Telepítés
sudo apt install -y fail2ban    # Debian/Ubuntu
sudo dnf install -y fail2ban    # RHEL/AlmaLinux

# Egyedi konfiguráció létrehozása (soha ne szerkeszd a jail.conf-ot!)
sudo tee /etc/fail2ban/jail.local <<JAILEOF
[DEFAULT]
# Kitiltási idő (10 perc)
bantime = 600
# Figyelési ablak
findtime = 600
# Maximális próbálkozások
maxretry = 3
# Kitiltás módja
banaction = nftables-multiport
banaction_allports = nftables-allports

[sshd]
enabled = true
port = 2222
logpath = %(sshd_log)s
backend = systemd
maxretry = 3
bantime = 3600

# Visszaeső támadók hosszabb kitiltása
[sshd-aggressive]
enabled = true
port = 2222
logpath = %(sshd_log)s
backend = systemd
maxretry = 1
findtime = 86400
bantime = 604800
filter = sshd[mode=aggressive]
JAILEOF

# Szolgáltatás indítása
sudo systemctl enable --now fail2ban

# Állapot ellenőrzése
sudo fail2ban-client status sshd

A Fail2Ban korlátai viszont 2026-ban már nyilvánvalóak. A jelszópermetezés (password spraying) technika esetén a támadók IP-nként mindössze 1-2 próbálkozást végeznek, és sok forrás-IP használatával simán a Fail2Ban küszöbértéke alatt maradnak. Ez az, ahol a CrowdSec belép a képbe.

CrowdSec: kollektív intelligencia a védelemben

A CrowdSec egy modern, közösségiadat-vezérelt behatolásvédelmi rendszer, ami alapvetően más megközelítést alkalmaz:

• Közösségi blokkolási listák — Ha egy CrowdSec-felhasználó észlel egy támadót, az IP-cím automatikusan megosztásra kerül a közösséggel. Így a többi felhasználó proaktívan blokkolhatja, még mielőtt nála is próbálkozna.
• Fejlett viselkedéselemzés — YAML-alapú forgatókönyvek, amelyek a Fail2Ban egyszerű mintaillesztésénél lényegesen kifinomultabb detekciót tesznek lehetővé
• Szétválasztott felismerés és végrehajtás — A detekció és a blokkolás különálló komponensekben fut, akár különböző szervereken

# CrowdSec telepítése
curl -s https://install.crowdsec.net | sudo sh
sudo apt install -y crowdsec crowdsec-firewall-bouncer-nftables

# SSH-specifikus forgatókönyv telepítése
sudo cscli scenarios install crowdsecurity/ssh-bf
sudo cscli scenarios install crowdsecurity/ssh-slow-bf
sudo cscli scenarios install crowdsecurity/ssh-cve-2024-6387

# Közösségi blokkolási lista engedélyezése
sudo cscli console enroll [A-TE-ENROLLMENT-KULCSOD]

# Aktuális döntések (blokkolások) megtekintése
sudo cscli decisions list

# Metrikák ellenőrzése
sudo cscli metrics

Szóval melyiket válaszd? Új telepítéseknél egyértelműen a CrowdSec a jobb választás a közösségi intelligencia miatt. Meglévő, jól működő Fail2Ban-konfiguráció esetén nincs sürgős migrációs kényszer, de érdemes a CrowdSec-et is bevezetni mellé — a két eszköz gond nélkül futhat párhuzamosan, amíg különböző naplófájlokat figyelnek.

Kétfaktoros hitelesítés (2FA) SSH-hoz

A kulcsalapú hitelesítés és a FIDO2 mellett a hagyományos TOTP-alapú kétfaktoros hitelesítés is hasznos védelmi réteg, különösen ott, ahol a hardverkulcsok nem praktikusak. Gondolj például fejlesztői környezetekre, ahol a csapat egy része még nem szerzett be YubiKey-t.

Google Authenticator PAM modul beállítása

# Telepítés
sudo apt install -y libpam-google-authenticator    # Debian/Ubuntu
sudo dnf install -y google-authenticator           # RHEL/AlmaLinux

# Felhasználói beállítás (minden felhasználónak egyénileg kell futtatnia)
google-authenticator -t -d -f -r 3 -R 30 -w 3

# Paraméterek:
# -t: TOTP mód
# -d: tiltja a kód többszöri felhasználását
# -f: felülírja a meglévő konfigurációt
# -r 3 -R 30: 30 másodpercenként max 3 próbálkozás
# -w 3: 3 szomszédos kód elfogadása (időcsúszás kompenzáció)

# /etc/pam.d/sshd módosítása
# Hozzáadás a fájl végéhez:
auth required pam_google_authenticator.so nullok

# A "nullok" opció lehetővé teszi a 2FA nélküli bejelentkezést
# azon felhasználók számára, akik még nem konfigurálták
# Produkciós környezetben ezt érdemes eltávolítani

# /etc/ssh/sshd_config módosítása a 2FA engedélyezéséhez
# Kulcsalapú hitelesítés + TOTP kombinálása
AuthenticationMethods publickey,keyboard-interactive
KbdInteractiveAuthentication yes

# A ChallengeResponseAuthentication régi név az újabb verziókban
# KbdInteractiveAuthentication-ra változott

Bastion host architektúra: a biztonságos belépési pont

A bastion host (vagy ugródoboz, ahogy sokan hívják) koncepciója egyszerű: egyetlen, megerősített szerveren keresztül érhető el a belső hálózat, így a belső szerverek SSH-portja soha nem kerül ki közvetlenül az internetre. Ez egy olyan architekturális döntés, amit ha egyszer bevezetsz, csodálkozni fogsz, hogyan éltél nélküle.

Bastion host tervezési elvek

• Minimális telepítés — Csak az SSH és a naplózáshoz szükséges eszközök
• Nincs helyi tárolás — Nincs shell history, nincs ideiglenes fájl
• Teljes audit naplózás — Minden parancs és munkamenet rögzítve
• Automatikus javítás — Unattended-upgrades vagy hasonló megoldás
• Hálózati szegmentáció — Tűzfalszabályok az engedélyezett belső célokra

ProxyJump konfiguráció

A modern SSH kliens ProxyJump direktívája egyszerűvé teszi a bastion használatát. Már rég nincs szükség a régi, kényelmetlen ProxyCommand-os megoldásokra:

# ~/.ssh/config — Bastion host konfiguráció

# Bastion host definíció
Host bastion
    HostName bastion.cegem.hu
    User bastion-user
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_bastion
    # Időtúllépés a bastion-on
    ServerAliveInterval 60
    ServerAliveCountMax 3

# Belső szerver — automatikusan a bastion-on keresztül
Host db-master
    HostName 10.0.2.10
    User dbadmin
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_db
    ProxyJump bastion

# Több szerver mintaillesztéssel
Host 10.0.2.*
    User deploy
    Port 2222
    ProxyJump bastion

# Parancssorból közvetlenül is használható:
ssh -J [email protected]:2222 [email protected] -p 2222

SSH audit és megfelelőség-ellenőrzés

A konfiguráció megerősítése csak az első lépés — rendszeres auditálásra és ellenőrzésre is szükség van, hogy a beállítások valóban megfelelőek maradjanak. Mert sajnos az „egyszer beállítom és elfelejthetom" megközelítés a biztonságban nem működik.

Az ssh-audit eszköz használata

Az ssh-audit egy kiváló nyílt forráskódú eszköz az SSH szerver és kliens konfigurációjának elemzésére:

# Telepítés
pip3 install ssh-audit

# Szerver auditálása
ssh-audit szerver.cegem.hu:2222

# A kimenet színkódokkal jelzi:
# - ZÖLD: biztonságos algoritmus
# - SÁRGA: elfogadható, de nem ideális
# - PIROS: nem biztonságos, el kell távolítani

# Részletes policy ellenőrzés
ssh-audit --policy /etc/ssh/ssh-audit-policy.json szerver.cegem.hu:2222

Automatizált SSH audit szkript

Rendszeres auditáláshoz íme egy egyszerű, cron-nal futtatható szkript:

#!/bin/bash
# /usr/local/bin/ssh-security-audit.sh
# Rendszeres SSH biztonsági audit

LOG_DIR="/var/log/ssh-audit"
DATUM=$(date +%Y-%m-%d_%H%M)
RIPORT="${LOG_DIR}/audit_${DATUM}.log"

mkdir -p "${LOG_DIR}"

echo "=== SSH Biztonsági Audit Riport ===" > "${RIPORT}"
echo "Dátum: $(date)" >> "${RIPORT}"
echo "Hoszt: $(hostname -f)" >> "${RIPORT}"

# 1. sshd konfiguráció ellenőrzése
echo "--- SSHD Konfiguráció ---" >> "${RIPORT}"
sshd -T 2>&1 | grep -E "^(passwordauthentication|permitrootlogin|permitemptypasswords|x11forwarding|maxauthtries|kexalgorithms|ciphers|macs)" | sort >> "${RIPORT}"

# 2. Hoszt kulcsok ellenőrzése
echo "--- Hoszt Kulcsok ---" >> "${RIPORT}"
for kulcs in /etc/ssh/ssh_host_*_key.pub; do
    ssh-keygen -l -f "${kulcs}" 2>/dev/null >> "${RIPORT}"
done

# 3. Aktív SSH munkamenetek
echo "--- Aktív SSH Munkamenetek ---" >> "${RIPORT}"
ss -tnp | grep ":2222" | grep ESTAB >> "${RIPORT}"

# 4. Legutóbbi sikertelen bejelentkezések
echo "--- Sikertelen Bejelentkezések (24 óra) ---" >> "${RIPORT}"
journalctl -u sshd --since "24 hours ago" --no-pager 2>/dev/null | grep -c "Failed" >> "${RIPORT}"

CIS Benchmark SSH-ellenőrzőlista

A CIS (Center for Internet Security) benchmark az alábbi SSH-beállításokat követeli meg. Érdemes ezt az ellenőrzőlistát rendszeresen végigfutnod:

• Az SSH szolgáltatás a legújabb stabil verzióra van frissítve
• A PermitRootLogin értéke no
• A PasswordAuthentication értéke no
• A PermitEmptyPasswords értéke no
• A MaxAuthTries értéke legfeljebb 4
• A X11Forwarding értéke no (ha nem szükséges)
• A LoginGraceTime értéke legfeljebb 60 másodperc
• Az AllowUsers vagy AllowGroups direktíva használatban van
• Csak erős kriptográfiai algoritmusok engedélyezettek
• Az SSH naplózás bekapcsolt állapotban van (LogLevel VERBOSE vagy INFO)
• A /etc/ssh/sshd_config fájl jogosultságai: 600, tulajdonos: root:root

Nftables tűzfalszabályok az SSH védelméhez

A tűzfal az SSH védelem külső rétege. Az nftables — az iptables modern utódja — hatékony szűrést tesz lehetővé. Ha még iptables-t használsz, nem baj, de az nftables felé érdemes elmozdulni:

#!/usr/sbin/nft -f
# /etc/nftables.d/ssh-protection.nft

table inet ssh_protection {
    # Kapcsolódási sebességkorlátozás
    set ssh_meter {
        type ipv4_addr
        flags dynamic,timeout
        timeout 10m
    }

    # Ismert megbízható IP-címek (fehérlista)
    set trusted_ssh {
        type ipv4_addr
        flags interval
        elements = {
            192.168.1.0/24,     # Belső hálózat
            10.0.0.5            # VPN szerver
        }
    }

    chain input {
        type filter hook input priority 0; policy drop;

        # Megbízható IP-k — korlátlan SSH hozzáférés
        ip saddr @trusted_ssh tcp dport 2222 accept

        # Sebességkorlátozás: max 3 új kapcsolat 60 másodpercenként
        tcp dport 2222 ct state new \
            add @ssh_meter { ip saddr limit rate 3/minute burst 5 packets } \
            accept

        # Minden más SSH kísérlet eldobása
        tcp dport 2222 drop
    }
}

Összefoglalás és ellenőrzőlista

Az SSH megerősítése 2026-ban többrétegű védekezést igényel. Tudom, sok mindent érintettünk — szóval itt egy gyors összefoglaló a legfontosabb lépésekről:

1. Frissíts OpenSSH 10.x-re — Használd ki a posztkvantum kulcscserét és a gyenge algoritmusokra vonatkozó figyelmeztetéseket
2. Tiltsd le a jelszavas hitelesítést — Kizárólag kulcsalapú (Ed25519) vagy FIDO2 hardverkulcsos hitelesítést engedélyezz
3. Megerősített kriptográfiai beállítások — Posztkvantum kulcscsere-algoritmusok, 256 bites AES/ChaCha20, erős MAC-ek
4. Tanúsítványalapú hitelesítés — Vállalati környezetben SSH CA-val és rövid élettartamú tanúsítványokkal
5. Behatolásvédelem telepítése — CrowdSec a kollektív intelligenciáért, Fail2Ban az egyszerű védelemért
6. Bastion host architektúra — A belső szerverek SSH-portja soha ne legyen közvetlenül elérhető az internetről
7. Tűzfalszabályok — Nftables sebességkorlátozás és IP-fehérlisták
8. Rendszeres audit — Automatizált szkriptek és ssh-audit rendszeres futtatása
9. 2FA bevezetése — TOTP vagy FIDO2 a kulcsalapú hitelesítés mellé második faktorként
10. Naplózás és monitorozás — Az auditd keretrendszer integrálása az SSH események követésére

Az SSH biztonság nem egy egyszeri beállítás, hanem folyamatos munka. A fenyegetések fejlődnek — a kvantumszámítógépek egyre közelebb kerülnek, az AI-vezérelt támadók egyre kifinomultabbak, és az ellopott hitelesítő adatok milliárdjai keringenek a darkweben.

De ne ijedj meg. A fentebb bemutatott technikák és eszközök kombinálásakor egy robusztus, többrétegű védelmi rendszert építesz, ami megfelel a 2026-os fenyegetési környezet kihívásainak. Nem kell mindent egyszerre bevezetni — kezdd a legkritikusabb elemekkel (jelszavas hitelesítés tiltása, kulcsalapú auth, Fail2Ban/CrowdSec), és lépésről lépésre haladj a többi felé.

Végül egy gondolat, amit érdemes észben tartani: a biztonság nem a tökéletességről szól, hanem arról, hogy a támadás költségét annyira megnöveld, hogy ne érje meg. Minden egyes védelmi réteg exponenciálisan megnehezíti a támadó dolgát.