SSH сигурност и удостоверяване 17 мин четене

Укрепване на SSH през 2026: Пост-квантова криптография, сертификати и пълна защита на OpenSSH

Практическо ръководство за SSH укрепване през 2026 г. — пост-квантова криптография с OpenSSH 10.0, SSH сертификати, Fail2Ban, 2FA, bastion хостове и Ansible автоматизация. Всичко стъпка по стъпка.

Editorial Team

Пълно ръководство за укрепване на SSH в ерата на пост-квантовата криптография

SSH е гръбнакът на отдалеченото администриране на Linux системи — това не е просто фраза, а ежедневна реалност за милиони администратори. Всеки ден през този протокол се управляват сървъри, разгръщат приложения и прехвърлят файлове. Но точно тази повсеместност го прави и една от най-атакуваните услуги. Данните на Shadowserver Foundation показват, че средностатистическият публичен сървър получава над 10 000 опита за SSH brute-force на ден. Да, на ден.

С излизането на OpenSSH 10.0 през април 2025 г. нещата се промениха доста сериозно. Пост-квантовият алгоритъм mlkem768x25519-sha256 стана стандарт по подразбиране за обмяна на ключове, DSA беше окончателно премахнат, а удостоверяването получи допълнително укрепване. През 2026 г. вече не е достатъчно просто да забраните root достъпа и да си мислите, че сте защитени — необходим е цялостен подход, който включва модерна криптография, удостоверяване със сертификати, ограничаване на достъпа и проактивно наблюдение.

В това ръководство ще изградим укрепена SSH конфигурация стъпка по стъпка — от генериране на подходящи ключове до настройка на Fail2Ban и одит на конфигурацията. Всички примери са тествани на Ubuntu 24.04 LTS и RHEL 9 с OpenSSH 9.9+.

1. Какво ново в OpenSSH 10.0: Пост-квантова защита по подразбиране

Преди да се хвърлим в конфигурацията, нека разберем какво точно промени OpenSSH 10.0 и защо тези промени имат значение за вашата сигурност.

Пост-квантова обмяна на ключове

Квантовите компютри все още не могат да разбиват RSA или ECDH — поне не с практическа скорост. Но атаките от типа „събирай сега, дешифрирай после" (harvest now, decrypt later) вече са напълно реални. Организации и държави прихващат и съхраняват криптиран трафик с надеждата, че в бъдеще ще разполагат с квантови ресурси за дешифрирането му.

Честно казано, това е плашеща перспектива.

OpenSSH 10.0 отговори на тази заплаха, като направи хибридния алгоритъм mlkem768x25519-sha256 стандарт по подразбиране. Той комбинира:

  • ML-KEM 768 (Module-Lattice-Based Key-Encapsulation Mechanism) — пост-квантов алгоритъм, стандартизиран от NIST
  • X25519 — класически елиптично-кривов алгоритъм за обмяна на ключове

Хибридният подход означава, че дори ако единият компонент бъде компрометиран, другият продължава да осигурява защита. Най-доброто от двата свята — доказана класическа криптография плюс защита от бъдещи квантови атаки.

Премахване на DSA

DSA (Digital Signature Algorithm) е официално премахнат в OpenSSH 10.0, след десетилетие на постепенно отхвърляне. Ако все още имате DSA ключове някъде из инфраструктурата си — сега е моментът да ги замените. Сериозно, не отлагайте. Проверете с:

# Намиране на DSA ключове в системата
find /etc/ssh/ -name "*dsa*" -type f
find ~/.ssh/ -name "*dsa*" -type f

# Проверка на типа на съществуващи ключове
for key in /etc/ssh/ssh_host_*_key.pub; do
    echo "$key: $(ssh-keygen -lf $key)"
done

Предупреждения за слаба криптография

OpenSSH 10.1 вече предупреждава потребителите, когато се използва алгоритъм за обмяна на ключове, който не е пост-квантов. Тези предупреждения се контролират чрез опцията WarnWeakCrypto в ssh_config(5), но моят съвет е да ги оставите активни — те са ранната ви индикация за потенциален проблем.

2. Генериране на силни SSH ключове

Основата на всяка SSH защита започва с правилния тип ключ. През 2026 г. имате три добри варианта и нека ги разгледаме един по един.

Ed25519 — препоръчителният избор

Ed25519 е базиран на елиптична крива Edwards 25519 и предлага компактни ключове (256 бита) с 128-битово ниво на сигурност. Бърз е, устойчив на атаки по страничен канал и се поддържа почти навсякъде. Ако ме питате мен — това е ключът, който трябва да използвате по подразбиране.

# Генериране на Ed25519 ключ
ssh-keygen -t ed25519 -a 64 -C "admin@server01-$(date +%Y%m%d)"

# Параметърът -a 64 задава 64 рунда на KDF за по-силна защита
# на паролата (passphrase) на ключа

RSA 4096 — за обратна съвместимост

Ако трябва да поддържате стари системи (а знаем, че такива винаги има), RSA с 4096 бита остава приемлив. Но не използвайте нищо под 3072 бита.

# Генериране на RSA-4096 ключ
ssh-keygen -t rsa -b 4096 -a 64 -C "admin@legacy-system"

ECDSA-SK и Ed25519-SK — хардуерни ключове

Ако използвате хардуерни токени за сигурност (YubiKey, SoloKey и подобни), FIDO2-базираните ключове добавят допълнителен слой защита. Дори ако частният ключ бъде откраднат от файловата система, без физическия токен той е напълно безполезен.

# Генериране на Ed25519-SK ключ (изисква FIDO2 токен)
ssh-keygen -t ed25519-sk -C "admin@fido2-key"

# С опция за потвърждение с докосване на токена при всяка употреба
ssh-keygen -t ed25519-sk -O resident -O verify-required -C "admin@yubikey"

Защита на частните ключове

Генерирането на силен ключ е само началото. Не по-малко важно е как го съхранявате:

# Задаване на правилни разрешения
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

# Промяна на паролата на съществуващ ключ
ssh-keygen -p -f ~/.ssh/id_ed25519

# Използване на SSH агент за удобство без компромиси
eval "$(ssh-agent -s)"
ssh-add -t 3600 ~/.ssh/id_ed25519  # Ключът ще изтече от агента след 1 час

3. Укрепване на sshd_config — стъпка по стъпка

Конфигурационният файл /etc/ssh/sshd_config е сърцето на SSH сигурността. Нека го изградим методично, секция по секция. Тук е мястото, където нещата стават наистина интересни.

Базови настройки за сигурност

# /etc/ssh/sshd_config — Укрепена конфигурация 2026

# Използвай само SSH протокол версия 2
Protocol 2

# Слушай само на необходимите интерфейси
# (заменете с вашия IP адрес)
ListenAddress 0.0.0.0
Port 22

# Забрани директен root достъп
PermitRootLogin no

# Задай кратък период за удостоверяване
LoginGraceTime 30s

# Максимум 3 опита за удостоверяване на сесия
MaxAuthTries 3

# Максимум 2 едновременни неудостоверени сесии
MaxStartups 2:50:10

# Покажи последното успешно влизане
PrintLastLog yes

Удостоверяване — само с ключове

# Активирай удостоверяване с публичен ключ
PubkeyAuthentication yes

# ЗАБРАНИ удостоверяване с парола
PasswordAuthentication no

# Забрани challenge-response (включва keyboard-interactive)
KbdInteractiveAuthentication no

# Забрани удостоверяване с GSSAPI (освен ако не използвате Kerberos)
GSSAPIAuthentication no

# Забрани хост-базирано удостоверяване
HostbasedAuthentication no

# Не позволявай празни пароли (за всеки случай)
PermitEmptyPasswords no

Криптографски алгоритми

Ето препоръчителните настройки за криптография, актуални за OpenSSH 9.9+ и 10.0. Обърнете специално внимание на реда на алгоритмите — той определя приоритета при договаряне:

# Алгоритми за обмяна на ключове — пост-квантов хибрид + силни класически
KexAlgorithms mlkem768x25519-sha256,[email protected],curve25519-sha256,[email protected],diffie-hellman-group16-sha512,diffie-hellman-group18-sha512

# Шифри — само AEAD (удостоверено криптиране)
Ciphers [email protected],[email protected],[email protected]

# MAC алгоритми — само Encrypt-then-MAC варианти
MACs [email protected],[email protected]

# Хост ключове — предпочитайте Ed25519
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

# Алгоритми за публичен ключ за удостоверяване
PubkeyAcceptedAlgorithms ssh-ed25519,[email protected],[email protected],rsa-sha2-512,rsa-sha2-256

Важно: Преди да приложите тези настройки, проверете дали вашата версия на OpenSSH ги поддържа. Алгоритъмът mlkem768x25519-sha256 е наличен от OpenSSH 9.9. За по-стари версии използвайте [email protected] като пост-квантова алтернатива.

# Проверка на поддържаните алгоритми
ssh -Q kex       # Алгоритми за обмяна на ключове
ssh -Q cipher    # Шифри
ssh -Q mac       # MAC алгоритми
ssh -Q key       # Типове ключове

Контрол на достъпа

# Разреши достъп САМО на определени потребители или групи
AllowUsers adminuser deploybot
# ИЛИ (по-добър подход — чрез група)
AllowGroups sshusers

# Изрично забрани определени потребители
DenyUsers root guest test

# Ограничи SSH за конкретна мрежа чрез Match блок
Match Address 10.0.0.0/8,192.168.1.0/24
    PubkeyAuthentication yes
    MaxAuthTries 5

Match Address *
    PubkeyAuthentication yes
    MaxAuthTries 2

Допълнителни настройки за укрепване

# Забрани X11 препращане (освен ако не е необходимо)
X11Forwarding no

# Забрани пренасочване на TCP тунели (ако не са нужни)
AllowTcpForwarding no
AllowStreamLocalForwarding no

# Забрани SSH агент препращане
AllowAgentForwarding no

# Не показвай банер с версия на ОС
DebianBanner no

# Деактивирай тунелно устройство
PermitTunnel no

# Задай интервал за проверка на активността
ClientAliveInterval 300
ClientAliveCountMax 2

# Логвай повече информация за по-добър одит
LogLevel VERBOSE

# Използвай строг режим за проверка на разрешенията
StrictModes yes

# Ограничи средата на потребителя
PermitUserEnvironment no

# Използвай привилегирано разделяне (sandbox)
UsePrivilegeSeparation sandbox

Проверка и прилагане на конфигурацията

# ЗАДЪЛЖИТЕЛНО: Проверете конфигурацията преди рестартиране!
sudo sshd -t

# Ако няма грешки, рестартирайте SSH
sudo systemctl restart sshd

# Проверете дали услугата работи
sudo systemctl status sshd

# КРИТИЧНО: НЕ затваряйте текущата SSH сесия!
# Отворете НОВА сесия, за да проверите дали можете да се свържете.
# Едва тогава затворете старата.

Съвет от практиката: Винаги дръжте поне една активна SSH сесия, докато тествате промени в конфигурацията. Ако нещо се обърка и се заключите — ще ви трябва физически или конзолен достъп до машината. Повярвайте ми, да разчитате на конзолния достъп на облачния си доставчик в три сутринта не е нещо, което искате да преживеете. Случвало ми се е.

4. Удостоверяване с SSH сертификати — следващото ниво

Публичните ключове са страхотен метод за удостоверяване, но имат съществен проблем при мащабиране: всеки нов ключ трябва да бъде копиран на всеки сървър, а оттеглянето на ключ изисква обхождане на всички authorized_keys файлове. При два-три сървъра е поносимо. При петдесет — кошмар.

SSH сертификатите решават тези проблеми по елегантен начин.

Как работят SSH сертификатите

Идеята е проста: вместо да копирате публичния ключ на всеки сървър, имате Сертифициращ орган (Certificate Authority — CA), който подписва ключа и издава сертификат с определен срок на валидност, ограничения за потребителско име и допълнителни разрешения. Сървърите доверяват на CA и автоматично приемат всеки валиден сертификат.

Стъпка 1: Създаване на CA

# Създайте CA ключ на защитена, офлайн машина
mkdir -p /etc/ssh/ca
ssh-keygen -t ed25519 -f /etc/ssh/ca/user_ca -C "SSH User CA - $(hostname)"
ssh-keygen -t ed25519 -f /etc/ssh/ca/host_ca -C "SSH Host CA - $(hostname)"

# Задайте строги разрешения
chmod 600 /etc/ssh/ca/user_ca /etc/ssh/ca/host_ca
chmod 644 /etc/ssh/ca/user_ca.pub /etc/ssh/ca/host_ca.pub

Стъпка 2: Подписване на потребителски ключове

# Подписване на потребителски ключ с ограничения
ssh-keygen -s /etc/ssh/ca/user_ca \
    -I "adminuser-cert-$(date +%Y%m%d)" \
    -n adminuser,deploybot \
    -V +8h \
    -O clear \
    -O permit-pty \
    -O permit-user-rc \
    /path/to/user_id_ed25519.pub

# Обяснение на параметрите:
# -s  : CA частен ключ за подписване
# -I  : Идентификатор на сертификата (за логовете)
# -n  : Разрешени потребителски имена (principals)
# -V  : Срок на валидност (+8h = 8 часа)
# -O clear : Изчиства всички разрешения по подразбиране
# -O permit-pty : Разрешава PTY (терминал)
# -O permit-user-rc : Разрешава ~/.ssh/rc

Стъпка 3: Подписване на хост ключове

# Подписване на хост ключа на сървъра
ssh-keygen -s /etc/ssh/ca/host_ca \
    -I "webserver01.example.com" \
    -h \
    -n webserver01.example.com,10.0.1.50 \
    -V +365d \
    /etc/ssh/ssh_host_ed25519_key.pub

# Параметърът -h указва, че това е хост сертификат

Стъпка 4: Конфигурация на сървъра

# Добавете в /etc/ssh/sshd_config:

# Доверявай на потребителския CA
TrustedUserCAKeys /etc/ssh/ca/user_ca.pub

# Използвай хост сертификат
HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub

# Задай файл с разрешени principals
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u
# Създайте principals файл за потребител
sudo mkdir -p /etc/ssh/auth_principals
echo "adminuser" | sudo tee /etc/ssh/auth_principals/adminuser
echo "deploybot" | sudo tee /etc/ssh/auth_principals/deploybot

Стъпка 5: Конфигурация на клиента

# Добавете в ~/.ssh/known_hosts или /etc/ssh/ssh_known_hosts:
@cert-authority *.example.com ssh-ed25519 AAAA... (съдържанието на host_ca.pub)

# В ~/.ssh/config:
Host *.example.com
    CertificateFile ~/.ssh/id_ed25519-cert.pub
    IdentityFile ~/.ssh/id_ed25519

Предимства на сертификатите

  • Автоматично изтичане: Сертификатите изтичат сами — без нужда от ръчно оттегляне в повечето случаи
  • Централизирано управление: Един CA може да обслужва хиляди сървъри без промяна на authorized_keys
  • Одит: Идентификаторът на сертификата (-I) се записва в логовете, което улеснява проследяването
  • Гранулирани разрешения: Може да ограничите какво точно може да прави даден сертификат — PTY, порт-форуърдинг, конкретни команди

5. Защита от Brute-Force атаки с Fail2Ban

Дори при удостоверяване само с ключове, brute-force опитите генерират ненужно натоварване и запълват логовете. Fail2Ban е задължителен инструмент за всеки публично достъпен SSH сървър. Няма извинение да не го имате.

Инсталация

# Debian/Ubuntu
sudo apt update && sudo apt install fail2ban -y

# RHEL/Fedora
sudo dnf install fail2ban -y

# Активирай и стартирай
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Конфигурация за SSH

Никога не модифицирайте jail.conf директно — промените се губят при обновяване. Вместо това създайте jail.local:

# /etc/fail2ban/jail.local

[DEFAULT]
# Време на забрана — 1 час
bantime = 3600

# Прозорец за наблюдение — 10 минути
findtime = 600

# Максимум неуспешни опити
maxretry = 3

# Прогресивно увеличаване на забраната за рецидивисти
bantime.increment = true
bantime.factor = 2
bantime.maxtime = 604800
# Първа забрана: 1 час, втора: 2 часа, трета: 4 часа... до 7 дни

# Действие — забрана + изпращане на имейл (по избор)
action = %(action_)s

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
# За RHEL/CentOS: logpath = /var/log/secure
maxretry = 3
bantime = 3600

Recidive jail — за упорити нарушители

# Добавете в /etc/fail2ban/jail.local

[recidive]
enabled = true
filter = recidive
logpath = /var/log/fail2ban.log
bantime = 604800   # 1 седмица
findtime = 86400    # 24 часа
maxretry = 3        # 3 забрани за 24 часа = 1 седмица бан

Управление на Fail2Ban

# Преглед на статуса
sudo fail2ban-client status sshd

# Списък на забранени IP адреси
sudo fail2ban-client get sshd banned

# Ръчна забрана на IP
sudo fail2ban-client set sshd banip 203.0.113.100

# Ръчно премахване на забрана
sudo fail2ban-client set sshd unbanip 203.0.113.100

# Проверка на конфигурацията
sudo fail2ban-client -t

# Наблюдение на логовете в реално време
sudo tail -f /var/log/fail2ban.log

6. Двуфакторно удостоверяване (2FA) за SSH

За максимална защита може да комбинирате SSH ключове с втори фактор чрез Google Authenticator PAM модула. Това означава, че дори при откраднат частен ключ, нападателят ще трябва да притежава и вашия TOTP код. Допълнителна стъпка? Да. Струва ли си? Абсолютно.

Инсталация и настройка

# Инсталиране на PAM модула
sudo apt install libpam-google-authenticator  # Debian/Ubuntu
sudo dnf install google-authenticator         # RHEL/Fedora

# Като потребител (НЕ root), стартирайте конфигурацията
google-authenticator

# Отговорете на въпросите:
# - Базирани на време токени: Да (y)
# - Обновяване на .google_authenticator: Да (y)
# - Забрана на многократна употреба: Да (y)
# - Прозорец от 30 секунди: Не (n) — по подразбиране
# - Ограничаване на опитите: Да (y)

Конфигурация на PAM

# Добавете в /etc/pam.d/sshd (след @include common-auth или auth substack):
auth required pam_google_authenticator.so nullok

# Параметърът 'nullok' позволява на потребители без 2FA да влязат
# Премахнете го, когато всички потребители са конфигурирали 2FA

Конфигурация на SSH демона

# В /etc/ssh/sshd_config:
ChallengeResponseAuthentication yes
# Или за по-новите версии:
KbdInteractiveAuthentication yes

# Изисквай И ключ, И 2FA код
AuthenticationMethods publickey,keyboard-interactive

# Рестартирай SSH
sudo systemctl restart sshd

Внимание: Тествайте 2FA конфигурацията с нова сесия, преди да затворите текущата. И моля ви — запазете резервните кодове на сигурно място. Те са единственият ви начин за достъп, ако изгубите устройството си за 2FA.

7. SSH Bastion Host (Jump Server) — централизиран достъп

Bastion сървърът (известен още като jump server) е укрепена входна точка, през която преминава целият SSH трафик към вътрешната мрежа. Вместо да излагате SSH портовете на всеки сървър, единствено bastion сървърът е достъпен отвън. Простичко и ефективно.

Архитектура

Интернет → [Bastion Host :22] → [Вътрешна мрежа]
                                    ├── Web Server (10.0.1.10)
                                    ├── DB Server (10.0.1.20)
                                    └── App Server (10.0.1.30)

Конфигурация на клиента

# ~/.ssh/config

# Bastion Host
Host bastion
    HostName bastion.example.com
    User adminuser
    Port 22
    IdentityFile ~/.ssh/id_ed25519
    ForwardAgent no

# Вътрешни сървъри — автоматично през bastion
Host web-server
    HostName 10.0.1.10
    User deploy
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519

Host db-server
    HostName 10.0.1.20
    User dbadmin
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519

# Общо правило за всички вътрешни машини
Host 10.0.1.*
    User adminuser
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519

Укрепване на Bastion сървъра

# sshd_config на bastion сървъра — минимални привилегии

# Забрани абсолютно всичко освен TCP forwarding
AllowTcpForwarding yes        # Необходимо за ProxyJump
AllowAgentForwarding no
X11Forwarding no
PermitTunnel no
GatewayPorts no

# Забрани интерактивна сесия за jump-only потребители
Match User jumpuser
    ForceCommand /usr/sbin/nologin
    AllowTcpForwarding yes
    PermitOpen 10.0.1.0/24:22
    # Разреши forwarding САМО към SSH портове на вътрешната мрежа

Между другото, командата ProxyJump (въведена в OpenSSH 7.3) е далеч по-удобна от стария ProxyCommand с nc. По-проста, по-сигурна и поддържа верижно свързване на множество jump хостове.

8. Одит и наблюдение на SSH достъпа

Укрепването без наблюдение е като заключване на вратата без камера — няма да знаете кога някой опитва да влезе. Ефективният SSH одит не е лукс, а жизненоважна част от цялостната сигурност.

Структурирано логване

# В sshd_config задайте подробно логване:
LogLevel VERBOSE

# Това ще записва допълнителна информация включително:
# - Тип на използвания ключ
# - Fingerprint на ключа
# - Номер на сертификата (ако се използва CA)
# - IP адрес и порт на клиента

Полезни команди за анализ на логове

# Успешни влизания за последните 24 часа
journalctl -u sshd --since "24 hours ago" | grep "Accepted"

# Неуспешни опити
journalctl -u sshd --since "24 hours ago" | grep "Failed"

# Топ 10 IP адреса с неуспешни опити
journalctl -u sshd --since "24 hours ago" | grep "Failed" | \
    awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -10

# Проверка за успешни влизания от необичайни IP адреси
last -i | head -20

# Активни SSH сесии
who | grep pts
ss -tnp | grep ":22"

Автоматизирано наблюдение с auditd

# Добавете правила в /etc/audit/rules.d/ssh.rules

# Наблюдавай промени в sshd_config
-w /etc/ssh/sshd_config -p wa -k sshd_config_change

# Наблюдавай промени в authorized_keys файловете
-w /home/ -p wa -k authorized_keys_change -F path=*/.ssh/authorized_keys

# Наблюдавай промени в CA ключовете
-w /etc/ssh/ca/ -p wa -k ssh_ca_change

# Наблюдавай стартиране на ssh-keygen
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/ssh-keygen -k ssh_keygen_usage

# Приложи правилата
sudo augenrules --load
sudo systemctl restart auditd

Проверка на конфигурацията с ssh-audit

Инструментът ssh-audit е един от любимите ми — анализира SSH сървъра и дава подробен отчет за силата на криптографията. Нещо като рентген за вашата SSH конфигурация:

# Инсталация
pip install ssh-audit

# Или чрез пакетния мениджър
sudo apt install ssh-audit  # Debian/Ubuntu

# Одит на вашия сървър
ssh-audit localhost
ssh-audit --port 22 your-server.example.com

# Пример за изхода:
# (gen) banner: SSH-2.0-OpenSSH_9.9p2
# (kex) mlkem768x25519-sha256        -- [info] available since OpenSSH 9.9
# (key) ssh-ed25519                   -- [info] available since OpenSSH 6.5
# (enc) [email protected] -- [info] available since OpenSSH 6.5
# (mac) [email protected] -- [info] available since OpenSSH 6.2

9. Автоматизация с Ansible — укрепване в мащаб

Ръчната конфигурация на всеки сървър не е практична при управление на десетки или стотици машини. Тук на помощ идва Ansible. Ето минимална роля за автоматизирано SSH укрепване:

# roles/ssh-hardening/tasks/main.yml
---
- name: Инсталирай последната версия на OpenSSH
  ansible.builtin.package:
    name: openssh-server
    state: latest

- name: Приложи укрепена sshd конфигурация
  ansible.builtin.template:
    src: sshd_config.j2
    dest: /etc/ssh/sshd_config
    owner: root
    group: root
    mode: '0600'
    validate: '/usr/sbin/sshd -t -f %s'
  notify: Рестартирай sshd

- name: Увери се, че само Ed25519 и RSA хост ключове съществуват
  ansible.builtin.file:
    path: "/etc/ssh/ssh_host_{{ item }}_key"
    state: absent
  loop:
    - dsa
    - ecdsa
  notify: Рестартирай sshd

- name: Генерирай Ed25519 хост ключ ако липсва
  ansible.builtin.command:
    cmd: ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""
    creates: /etc/ssh/ssh_host_ed25519_key

- name: Инсталирай Fail2Ban
  ansible.builtin.package:
    name: fail2ban
    state: present

- name: Приложи Fail2Ban SSH конфигурация
  ansible.builtin.template:
    src: jail.local.j2
    dest: /etc/fail2ban/jail.local
    owner: root
    group: root
    mode: '0644'
  notify: Рестартирай Fail2Ban

# handlers/main.yml
- name: Рестартирай sshd
  ansible.builtin.service:
    name: sshd
    state: restarted

- name: Рестартирай Fail2Ban
  ansible.builtin.service:
    name: fail2ban
    state: restarted

10. Контролен списък за SSH укрепване

За удобство, ето обобщен контролен списък, който можете да следвате при укрепване на всеки нов сървър. Принтирайте го, закачете го на стената — каквото ви върши работа:

  1. Актуализирайте OpenSSH до последната стабилна версия (9.9+ или 10.0)
  2. Генерирайте Ed25519 ключове за потребители и хостове
  3. Забранете удостоверяване с парола — PasswordAuthentication no
  4. Забранете root достъп — PermitRootLogin no
  5. Ограничете разрешените потребители — AllowUsers или AllowGroups
  6. Конфигурирайте силна криптография — пост-квантови KexAlgorithms, AEAD шифри, ETM MAC
  7. Премахнете DSA и ECDSA хост ключове
  8. Настройте Fail2Ban с прогресивно увеличаващи се забрани
  9. Активирайте 2FA за критични системи
  10. Настройте Bastion Host за вътрешни мрежи
  11. Активирайте подробно логване — LogLevel VERBOSE
  12. Конфигурирайте auditd за наблюдение на SSH конфигурационни промени
  13. Стартирайте ssh-audit и коригирайте всички предупреждения
  14. Забранете ненужните функции — X11, TCP forwarding, Agent forwarding
  15. Документирайте и автоматизирайте — с Ansible, Puppet или подобен инструмент

11. Отстраняване на чести проблеми

При укрепване на SSH винаги изникват проблеми. Не се притеснявайте, случва се на всички. Ето най-честите и как да ги решите:

Проблем: Не мога да се свържа след промяна на конфигурацията

# Свържете се чрез конзолен достъп на облачния доставчик
# Проверете синтаксиса:
sudo sshd -t

# Проверете дали услугата работи:
sudo systemctl status sshd

# Вижте логовете за грешки:
sudo journalctl -u sshd -n 50 --no-pager

# Стартирайте sshd в дебъг режим на алтернативен порт:
sudo /usr/sbin/sshd -d -p 2222

Проблем: „Permission denied (publickey)"

# На клиента — подробен дебъг:
ssh -vvv user@server

# Проверете разрешенията на сървъра:
ls -la ~/.ssh/
# Директорията трябва да е 700, файловете — 600

# Проверете SELinux контекста (RHEL/Fedora):
ls -laZ ~/.ssh/
restorecon -Rv ~/.ssh/

Проблем: Бавна SSH връзка

# Обикновено причината е DNS — деактивирайте обратна DNS проверка:
# В sshd_config:
UseDNS no

# Или GSSAPI (ако не използвате Kerberos):
GSSAPIAuthentication no

Заключение

SSH сигурността през 2026 г. изисква многопластов подход. Вече не е достатъчно просто да забраните root достъпа и да използвате ключове — трябва да приемете пост-квантовата криптография на OpenSSH 10.0, да обмислите преминаване към удостоверяване със сертификати за по-мащабни среди, да укрепите защитата с Fail2Ban и двуфакторно удостоверяване, и да осигурите постоянно наблюдение.

Всяка от техниките, описани тук, добавя отделен слой защита. Заедно те създават устойчива система за отбрана в дълбочина, която защитава не само от днешните заплахи, но и от бъдещите квантови атаки.

Моят съвет? Започнете с основните настройки от раздел 3, добавете Fail2Ban от раздел 5, и постепенно внедрявайте останалото. Не е нужно да правите всичко наведнъж — важното е да започнете.

И помнете — сигурността е непрекъснат процес, не еднократно събитие. Редовно обновявайте OpenSSH, одитирайте конфигурациите си и следете за нови уязвимости. Инструменти като ssh-audit и автоматизацията с Ansible превръщат тази задача от тежко бреме в рутинна практика.

За Автора Editorial Team

Our team of expert writers and editors.