Ubuntu 24.04: UFW заблокував SSH — безпечно відновіть доступ через консоль

January 1, 2026 • February 3, 2026 • Читання: 6 хв • Views: 6

Було корисно?

Ви ввімкнули UFW (або «посилили налаштування»), ваша SSH-сесія упала, і тепер порт 22 ніби пішов у тиху відпустку. Сервер ще доступний через консоль гіпервізора, послідовну консоль хмари, KVM/iDRAC або будь-який інший канал поза мережею. Добре. Це достатньо.

Це метод, який працює лише з консолі й безпечно для продакшну — відновити SSH без перетворення файрвола на серветку. Ми спочатку діагностуємо, змінюємо по одному пункту й залишимо систему надійнішою, ніж була спочатку. Бо повернутися — це лише половина завдання; не повторити інцидент — інша половина.

Загальні правила: не погіршуйте ситуацію

Коли ви опинилися поза доступом, хочеться «просто вимкнути файрвол». Іноді це правильний аварійний важіль. Але в продакшні треба діяти обдумано, бо та сама помилка, яка заблокувала SSH, може випадково відкрити бази даних, панелі адміністрування або сервіси тільки для внутрішньої мережі в інтернет.

Ось набір правил, якими я користуюся:

Консоль — ваша контрольна площина. Тримайте одну консольну сесію відкритою, поки не отримаєте підтверджений новий SSH-сеанс. Не закривайте єдиний запасний парашут посеред стрибка.
Віддавайте перевагу додатковим змінам. Додайте вузько спрямоване правило allow перед тим, як видаляти deny-правила або скидати UFW.
Перевіряйте маршрут мережі. Файрвол може бути ні в чому не винен. Неправильний інтерфейс, невірна IP-адреса, sshd не запущено, проблеми з маршрутизацією, групи безпеки провайдера — підозрюваних багато.
Робіть зміни відкатними. Використовуйте коментарі, зафіксуйте час, зберігайте копію виводу до і після змін.

Одна цитата, яку я тримаю на ментальній панелі: «Надія — це не стратегія.» — General Gordon R. Sullivan. Вона стосується роботи з файрволами більше, ніж комусь хочеться визнавати.

Цікаві факти та історичний контекст (так, це важливо)

Файрволи — стара технологія в нових обгортках. Розуміння того, що лежить під UFW, допоможе уникнути ненаукових помилок при налагодженні.

UFW — це фронтенд, а не сам файрвол. Він пише правила в пакетний фільтр ядра — історично iptables, дедалі частіше nftables на сучасних Ubuntu.
iptables довго був дефолтним рішенням. Багато «класичних» мануалів припускають iptables-ланцюги й виводи, які не відповідають системам на базі nft.
nftables з’явився, щоб уніфікувати IPv4/IPv6 і спростити управління правилами. Він вже не «новий», але багато експлуатаційних рукописів іще цього не врахували.
Стандартний порт SSH (22) — це конвенція, а не закон. «Сховання по порту» скоріше зменшує логи, ніж забезпечує реальний контроль доступу.
За замовчуванням політики UFW — заряджена рушниця. «Default deny incoming» — правильний вибір для серверів, але він може відкидати існуючі патерни трафіку, про які ви забули.
Блокування по IPv6 — часте явище. Люди дозволяють IPv4 на 22 і забувають про IPv6; клієнти, які вважають за краще IPv6, «провалюються» загадково.
Хмарні файрволи передують UFW у шляху запиту. Security groups/NACLs можуть блокувати вас ще до того, як пакет дійде до ядра.
Становий фільтр дозволяє існуючим сесіям інколи виживати. Conntrack може підтримувати встановлену SSH-сесію живою, тоді як нові підключення не проходять — і так до моменту, поки ви не від’єднаєтесь і не пошкодуєте.
UFW може бути увімкнений без правил, які ви очікували. Інструмент не читає думки; він охоче застосує «deny», поки ви ще вводите «allow».

Швидкий план діагностики

Це найшвидший шлях до вузького місця. Дотримуйтеся порядку. Сенс — не міняти неправильний шар.

Перш за все: підтвердьте, що sshd живий і слухає там, де ви думаєте

Is sshd running?
Is it listening on the expected port and on the expected addresses (0.0.0.0 vs a single IP)?
Did you accidentally bind it to localhost or an internal interface?

По-друге: підтвердьте, що мережа хоста в порядку

Correct IP on the correct interface?
Default route present?
Can you reach your gateway?

По-третє: визначте, який саме шар файрволу відкидає пакети

Cloud security group / provider firewall changes?
UFW status and active rules?
Underlying nftables/iptables rules consistent with UFW output?

По-четверте: виправляйте з мінімальною «зоною ураження»

Add a temporary allow from your management IP (or subnet) to SSH.
Verify you can open a new SSH session.
Then clean up and harden.

Сухо і з гумором #1: Файрвол ніколи «не ненавидить вас особисто»; він просто виконує те, що ви йому наказали, включно з тим, чого ви не мали на увазі.

Відновлення через консоль: безпечне відновлення SSH

Працюємо з припущенням, що у вас є доступ до консолі (фізичної, IPMI/iDRAC, консоль гіпервізора, послідовна консоль хмари). Ви увійшли як користувач з sudo або як root.

Найбезпечніший підхід:

Confirm sshd is running and listening.
Confirm what address/port you intend to allow (often port 22, sometimes a non-standard port).
Add the narrowest possible UFW allow rule for SSH from a trusted source.
Verify with logs and a real SSH attempt.
Only then remove emergency allowances or broader rules.

Якщо ви не знаєте свій IP керування (таке трапляється), використайте тимчасове широке allow для внутрішньої мережі або діапазону VPN, а не 0.0.0.0/0, і встановіть нагадування звузити його. «Тимчасовий» без подальших дій породжує тикети безпеки.

Практичні завдання (команди, виводи, рішення)

Нижче — реальні виконувані команди. Кожне завдання включає: що ви виконуєте, що означає вивід і яке рішення приймаєте далі. Виконуйте їх із консолі на ураженому хості.

Завдання 1: Переконайтеся, що ви на тому хості, який вважаєте

cr0x@server:~$ hostnamectl
 Static hostname: server
       Icon name: computer-server
         Chassis: server
      Machine ID: 7e3c0f0d3a1c4b3a9c1d2f3a4b5c6d7e
         Boot ID: 2b1d2c3e4f5a6b7c8d9e0f1a2b3c4d5e
Operating System: Ubuntu 24.04.1 LTS
          Kernel: Linux 6.8.0-36-generic
    Architecture: x86-64

Значення: Підтверджує версію ОС і ядра; Ubuntu 24.04 може використовувати nftables як бекенд для UFW, залежно від пакету/конфігурації.

Рішення: Продовжуйте, припускаючи, що сучасні nft-інструменти можуть бути релевантні; не вставляйте сліпо старі iptables-команди 2016 року.

Завдання 2: Перевірте, чи працює SSH

cr0x@server:~$ systemctl status ssh --no-pager
● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/usr/lib/systemd/system/ssh.service; enabled; preset: enabled)
     Active: active (running) since Sat 2025-12-28 09:07:12 UTC; 21min ago
       Docs: man:sshd(8)
             man:sshd_config(5)
   Main PID: 1123 (sshd)
      Tasks: 1 (limit: 18763)
     Memory: 3.6M (peak: 4.2M)
        CPU: 72ms
     CGroup: /system.slice/ssh.service
             └─1123 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups

Значення: sshd запущено. Якби він був inactive/failed, файрвол не був би основною проблемою.

Рішення: Якщо inactive — виправте sshd спочатку (конфіг, ключі, порт). Якщо активний — переходьте до перевірки сокетів.

Завдання 3: Переконайтеся, на якому порту/адресі слухає sshd

cr0x@server:~$ ss -ltnp | grep -E '(:22|:2222)\s'
LISTEN 0      128          0.0.0.0:22        0.0.0.0:*    users:(("sshd",pid=1123,fd=3))
LISTEN 0      128             [::]:22           [::]:*    users:(("sshd",pid=1123,fd=4))

Значення: SSH слухає порт 22 і на IPv4, і на IPv6. Якщо ви бачите тільки 127.0.0.1:22 або конкретну IP-адресу інтерфейсу, віддалений доступ може відмовляти незалежно від UFW.

Рішення: Якщо прослуховування в порядку — зосередьтеся на файрволі та upstream-фільтрах. Якщо ні — виправляйте /etc/ssh/sshd_config (наприклад, ListenAddress, Port) і перезавантажте.

Завдання 4: Підтвердьте вашу IP та маршрут за замовчуванням

cr0x@server:~$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
ens3             UP             203.0.113.10/24 2001:db8:1234:5678::10/64

cr0x@server:~$ ip route
default via 203.0.113.1 dev ens3 proto static
203.0.113.0/24 dev ens3 proto kernel scope link src 203.0.113.10

Значення: Інтерфейс увімкнено, IP присутній, маршрут за замовчуванням є.

Рішення: Якщо бракує default route — виправляйте мережу спершу; UFW не виправить «немає маршруту до хоста».

Завдання 5: Подивіться, чи UFW взагалі увімкнений

cr0x@server:~$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp                     DENY IN     Anywhere
22/tcp (v6)                DENY IN     Anywhere (v6)

Значення: UFW активний і явно забороняє SSH. Це і є ваше блокування.

Рішення: Не скидайте все одразу. Додайте вузьке allow правило вище цього deny або видаліть deny, якщо воно було випадковим (після перевірки, хто його створив).

Завдання 6: Перегляньте номеровані правила, щоб зробити точковий ремонт

cr0x@server:~$ sudo ufw status numbered
Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     DENY IN     Anywhere
[ 2] 22/tcp (v6)                DENY IN     Anywhere (v6)

Значення: Можна видаляти по номеру правила без вгадувань синтаксису.

Рішення: Якщо deny очевидно помилкове — видаліть його. Якщо не впевнені — спершу додайте allow від IP керування, потім видаляйте.

Завдання 7: Додайте тимчасовий allow з вашого IP керування (рекомендовано)

cr0x@server:~$ sudo ufw allow from 198.51.100.25 to any port 22 proto tcp comment 'TEMP: restore SSH from mgmt IP'
Rule added

Значення: Це створює більш конкретне правило allow. UFW зазвичай упорядковує правила так, що конкретніші правила мають пріоритет.

Рішення: Спробуйте SSH з 198.51.100.25. Якщо вдасться — ви відновили доступ з мінімальним ризиком.

Завдання 8: Перевірте порядок правил та ефективну політику

cr0x@server:~$ sudo ufw status numbered
Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     ALLOW IN    198.51.100.25
[ 2] 22/tcp                     DENY IN     Anywhere
[ 3] 22/tcp (v6)                DENY IN     Anywhere (v6)

Значення: Allow перевіряється перед deny для IPv4. IPv6 все ще глобально заборонено, що нормально, якщо ваш шлях керування — тільки IPv4.

Рішення: Якщо клієнти підключаються по IPv6, потрібно також дозволити IPv6 з вашого префіксу або тимчасово вимкнути пріоритет IPv6 на клієнті, доки ви не виправите правила.

Завдання 9: Перевірте лог UFW на заблоковані SSH-пакети

cr0x@server:~$ sudo journalctl -k -g 'UFW BLOCK' --since '10 minutes ago' --no-pager | tail -n 5
Dec 28 09:26:03 server kernel: [UFW BLOCK] IN=ens3 OUT= MAC=aa:bb:cc:dd:ee:ff SRC=203.0.113.50 DST=203.0.113.10 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=54321 DF PROTO=TCP SPT=51514 DPT=22 WINDOW=64240 RES=0x00 SYN URGP=0

Значення: Пакети доходять до хоста і блокуються UFW. Це хороша новина: upstream маршрутизація та файрволи провайдера, швидше за все, не є вузьким місцем.

Рішення: Виправляйте правила UFW, а не групи безпеки в хмарі.

Завдання 10: Підтвердьте, який бекенд активний (nftables проти iptables) та перегляньте сирі правила

cr0x@server:~$ sudo ufw show raw | head -n 25
*filter
:ufw-user-input - [0:0]
:ufw-user-output - [0:0]
:ufw-user-forward - [0:0]
:ufw-before-input - [0:0]
:ufw-before-output - [0:0]
:ufw-before-forward - [0:0]
:ufw-after-input - [0:0]
:ufw-after-output - [0:0]
:ufw-after-forward - [0:0]
:ufw-logging-deny - [0:0]
:ufw-logging-allow - [0:0]
:ufw-reject-input - [0:0]
:ufw-reject-output - [0:0]
:ufw-reject-forward - [0:0]
-A ufw-user-input -p tcp --dport 22 -s 198.51.100.25 -j ACCEPT
-A ufw-user-input -p tcp --dport 22 -j DROP
COMMIT

Значення: Ви бачите фактичну логіку accept потім drop. Це «істина» на диску.

Рішення: Якщо сирий вигляд не відповідає ufw status, може бути часткове застосування або інший менеджер файрволу заважає. Розбирайтеся перед тим, як додавати нові правила.

Завдання 11: Видаліть випадкове deny-правило (точковий ремонт)

cr0x@server:~$ sudo ufw delete 2
Deleting:
 allow 22/tcp
Proceed with operation (y|n)? y
Rule deleted

Значення: Ви видалили правило #2 за поточним нумерацією. (Так, нумерація змінюється при додаванні/видаленні. Завжди перевіряйте ще раз.)

Рішення: Якщо ви плануєте загалом дозволити SSH, замініть deny на allow для вашого адмінського CIDR, VPN або bastion — не робіть allow для «Anywhere», якщо немає вагомих причин і додаткових контролів.

Завдання 12: Встановіть розумну політику SSH (виберіть підхід)

Опція A: дозволити SSH лише з підмережі керування (найкраще для більшості продакшн-серверів):

cr0x@server:~$ sudo ufw allow from 198.51.100.0/24 to any port 22 proto tcp comment 'SSH from mgmt subnet'
Rule added

Опція B: дозволити SSH з будь-де (прийнятно для bastion з сильною автентифікацією і моніторингом):

cr0x@server:~$ sudo ufw allow 22/tcp comment 'SSH'
Rule added

Значення: Ви фіксуєте намір. UFW «щасливий», коли правила відображають реальні шаблони доступу.

Рішення: Якщо ви обрали «Anywhere», компенсуйте це сильною SSH-конфігурацією (тільки ключі, заборона root, можливі fail2ban-подібні механізми та хороший логінг).

Завдання 13: Обробіть IPv6 явно (бо ваш клієнт це зробить)

cr0x@server:~$ sudo ufw status verbose | grep -E 'IPv6|v6'
22/tcp (v6)                DENY IN     Anywhere (v6)

cr0x@server:~$ sudo ufw allow from 2001:db8:9999::/48 to any port 22 proto tcp comment 'SSH from mgmt IPv6'
Rule added

Значення: IPv6-правила — це окремі записи. Якщо ви використовуєте IPv6, ставте його в один ряд із IPv4.

Рішення: Якщо ви взагалі не використовуєте IPv6, не залишайте напівналаштовану політику. Або відключіть IPv6 на ОС/мережі цілеспрямовано (з планом впровадження), або заблокуйте його послідовно.

Завдання 14: Перевірте реальним SSH-підключенням, потім логи

cr0x@server:~$ sudo journalctl -u ssh --since '10 minutes ago' --no-pager | tail -n 8
Dec 28 09:31:44 server sshd[1890]: Connection from 198.51.100.25 port 55312 on 203.0.113.10 port 22 rdomain ""
Dec 28 09:31:45 server sshd[1890]: Accepted publickey for admin from 198.51.100.25 port 55312 ssh2: ED25519 SHA256:Zk1...
Dec 28 09:31:45 server sshd[1890]: pam_unix(sshd:session): session opened for user admin(uid=1000) by (uid=0)

Значення: Підключення дійшло до sshd і пройшло автентифікацію. Ви знову в ділі.

Рішення: Лише тепер видаляйте тимчасові винятки і фіналізуйте політику.

Завдання 15: Якщо потрібно — контрольоване відключення/повторне ввімкнення UFW

cr0x@server:~$ sudo ufw disable
Firewall stopped and disabled on system startup

cr0x@server:~$ sudo ufw enable
Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup

Значення: Це «великий важіль». Він може врятувати вас, але також може на короткий час відкрити весь хост, залежно від інших шарів.

Рішення: Використовуйте лише коли розумієте експозицію і маєте компенсуючі контроли (хмарний файрвол, приватна мережа, вікно техобслуговування). Краще — точкові виправлення правил.

Завдання 16: Підтвердіть збереження та інтеграцію з systemd

cr0x@server:~$ systemctl is-enabled ufw
enabled

cr0x@server:~$ sudo ufw status
Status: active

Значення: UFW буде застосовуватись при завантаженні і зараз активний.

Рішення: Якщо він вимкнений, вирішіть, чи це навмисна позиція. «Ми вимкнули його, щоб відновити доступ, і забули» — це не стратегія, це майбутній інцидент.

Три корпоративні історії з практики

1) Інцидент через помилкове припущення: «Allow SSH» не означало те, що вони думали

Середня компанія мала флот Ubuntu-серверів, розділених між публічними та приватними підмережами. Команда дотримувалась практики: тримати SSH відкритим лише для корпоративного VPN-діапазону. Розумно. Одного дня під час хвилі оновлень інженер вирішив «уніфікувати правила файрволу» і розгорнув зміни UFW через автоматизацію.

Зміна виглядала безпечно в code review: додавали ufw allow 22/tcp, а потім правило deny-all. Припускали, що «deny-all» вплине лише на невказані порти, а SSH залишиться відкритим. Пропустили одне: старіша роль також додавала deny 22/tcp на хостах, які мали доступ лише через bastion. Два джерела істини. Одне дружнє, інше — ворожне.

Під час розгортання існуючі SSH-сесії залишалися активними через state tracking, тож ніхто не помітив. Потім скрипт техпідтримки закрив неактивні сесії. Раптом нові сесії зупинилися по всій групі серверів. NOC побачив «SSH down» і став трактувати це як мережевий збій. Це не був збій мережі. Це був ідеально працюючий софт, що примусово застосував суперечливу політику.

Відновлення було повільним, бо команда намагалася лізти з власних ноутів. Вони не могли зайти. Зрештою використали консолі провайдера, щоб додати allow з IP керування, саме як описано вище. Фактичне виправлення було нудним: видалити дубль deny, додати коментарі і зробити один модуль відповідальним за правила SSH. Постмортем навчив ще одній нудній істині: «припущення — це не тести».

2) Оптимізація, що повернулась бумерангом: скорочення набору правил без розуміння порядку оцінки

Інша організація мала сек’юріті-команду, яка не любила «захаращені правила». Вони попросили платформенну команду «зменшити кількість записів у файрволі» і прибрати «зайві» IPv6-дозволи. Платформа погодилась швидко. Надто швидко.

Вони видалили явні IPv6-allow, з ідеєю, що «ніхто не використовує IPv6», щоб зменшити шум у аудиті. Але частина корпоративних ноутбуків мала пріоритет IPv6, і їхній VPN-клієнт пролівав IPv6-маршрути так, що клієнти намагалися підключатися по v6 першими. Результат: переривчасті відмови SSH залежно від ОС клієнта, мережі й порядку DNS-відповідей. Тикети були шедевром плутанини.

Потім з’явилася «оптимізація»: щоб зменшити кількість правил, хтось замінив специфічне allow-правило на широкий allow і поклався на обмеження SSH на рівні програми. Це зменшило кількість правил. Також це підвищило експозицію і обсяг логів, і зробило brute-force спроби більш помітними для всіх нижчих шарів.

Виправлення було не менш прозаїчним: відновити явні IPv6-правила, тримати allow-листи вузькими і використовувати логування UFW на low/medium плюс централізовану агрегацію логів. Команда зрозуміла, що «менше правил» не завжди краще. Правильні правила — кращі.

3) Нудна, але правильна практика, що врятувала день: доступ по консолі та поетапні розгортання

Фінансова компанія мала звичку, якої я бажаю для всіх: кожен продсервер мав перевірений позамережевий доступ, а кожна зміна файрволу виконувалась у три етапи. Крок перший: додати нове allow-правило. Крок другий: перевірити зв’язок з принаймні двох мереж. Крок третій: видалити старе правило. Порядок звучить педантично. Але саме завдяки цьому вони спокійно спали.

Одного вечора інженер посилив дефолт UFW на групі хостів і випадково видалив підмережу керування з allow-листа. Вони помітили за кілька хвилин, бо їхній smoke test (простість перевірки підключення SSH) упав у стейджингу. Та сама автоматизація могла б вдарити по продакшну далі.

Навіть якби вона потрапила в продакшн, плейбук вимагав тримати консоль відкритою і мати готову команду відкату. Їм не довелося її використовувати, бо поетапне розгортання зупинило ураження на «кількох тестових боксах». Ніяких геройств. Ніякої паніки. Ніякого керівника, що питає, чому «зміна файрволу може зупинити дохід».

Вони виправили конфіг, перезапустили тест і продовжили роботу. Найцікавіше було, наскільки нецікавою була сама подія. Це і є мета.

Чеклісти / покроковий план

Чекліст для відновлення (з консолі, мінімальний ризик)

Тримайте консоль відкритою. Не закривайте її, поки не отримаєте новий SSH-сеанс.
Підтвердьте, що sshd запущено: systemctl status ssh.
Підтвердьте прослуховування: ss -ltnp | grep sshd.
Перевірте мережу хоста: ip -br addr, ip route.
Перевірте статус UFW: ufw status verbose.
Додайте вузький allow: ufw allow from <mgmt-ip> to any port 22 proto tcp.
Перевірте порядок правил: ufw status numbered.
Спробуйте SSH з IP керування.
Переконайтесь у логах: journalctl -u ssh і за потреби kernel UFW blocks.
Видаліть випадкові deny-правила.
Визначте остаточну політику SSH: allow-list проти anywhere; врахуйте IPv6.
Видаліть TEMP-винятки і додайте коментарі до постійних правил.

Чекліст стабілізації (після відновлення)

Занотуйте «до/після» вивід UFW у вашому тикеті.
Переконайтесь, що хмарні групи безпеки відповідають вашим намірам.
Перевірте жорсткість SSH: лише ключі, заборона root, сенсні методи автентифікації.
Переконайтесь, що ви можете дістатися машини позамережевим каналом (і що облікові дані працюють).
Заплануйте follow-up, щоб звузити будь-які тимчасові широкі allow-правила.

Сухо і з гумором #2: Нічого так не кричить «корпорація», як правило файрвола з назвою TEMP від двох кварталів тому, яке ніхто не наважується видалити.

Типові помилки: симптом → корінь → виправлення

Симптом: SSH таймаут; UFW показує «active», але є «allow 22/tcp».
Корінь: Ви дозволили IPv4, але підключаєтесь через IPv6 (або навпаки), або дозволили неправильний інтерфейс/IP-діапазон.
Виправлення: Додайте явні v6-allow для префіксу керування або переконайтесь, що клієнт використовує IPv4; перевіряйте ss і ufw status verbose.
Симптом: SSH «No route to host» або миттєвий відмов; UFW не показує нічого.
Корінь: Блокування вгорі по ланцюгу (cloud security group, NACL), проблема маршрутизації або неправильний публічний IP/DNS.
Виправлення: Перевірте файрвол провайдера і IP інстансу; дивіться ip route і консоль провайдера. Не правте UFW, коли пакети взагалі не доходять.
Симптом: Існуючі SSH-сесії працювали, поки не відключилися; нові сеанси відмовляють.
Корінь: Становий файрвол дозволяв established з’єднання; нові вхідні блокує політика.
Виправлення: Додайте allow-правило для нових підключень. Не плутайте «я ще підключений» з «все гаразд».
Симптом: UFW каже, що правило є, але поведінка не змінюється.
Корінь: Інший менеджер файрволу перезаписав правила, або UFW застосувався не повністю, або ви дебагуєте не той хост/неймспейс.
Виправлення: Перегляньте ufw show raw, перевірте інші сервіси (контейнери, оркестрація) і впевніться, що ви на правильній машині (hostnamectl).
Симптом: SSH доходить до хоста, але автентифікація йде не так після змін UFW.
Корінь: Співпав якийсь випадковий змін у конфігах sshd, права ключів або PAM; UFW звинувачують, бо це остання зміна.
Виправлення: Перевірте journalctl -u ssh, підтвердіть /etc/ssh/sshd_config і тестуйте локально ssh localhost.
Симптом: Ви дозволили порт 22, але SSH на 2222 (або навпаки).
Корінь: Невідповідність між конфігом sshd і правилами файрволу; іноді спричинена гайдами по жорсткій безпеці.
Виправлення: Підтвердіть порт прослуховування через ss -ltnp; оновіть UFW відповідно: ufw allow 2222/tcp.
Симптом: Ви впевнені, що дозволили IP офісу, але все одно не можете підключитись.
Корінь: Ваш вихідний IP змінився (ISP, мобільний хот-спот, VPN egress).
Виправлення: Підтвердіть поточний egress IP через відомий сервіс або корпоративні інструменти; потім тимчасово дозволіть цей IP. Краще використовувати VPN/bastion для стабільного виходу.
Симптом: UFW enable попереджає про можливе порушення SSH, і воно трапляється.
Корінь: Ви увімкнули UFW до додавання allow-правила, або default incoming deny вступив у силу.
Виправлення: З консолі додавайте allow-правила спочатку; потім вмикайте. Для віддалених змін плануйте maintenance window або використовуйте механізм відкату за часом.

Запобіжні заходи, щоб не повторити блокування

Після відновлення доступу витратьте п’ять хвилин, щоб зменшити шанс повторення. Мета не в театральній максимальній безпеці; вона в контролі доступу, який не ламається під час рутинних робіт.

1) Зробіть доступ SSH явним і вузьким

Оберіть один із цих підходів:

Модель bastion: Лише bastion-хости приймають SSH з інтернету; всі інші сервери дозволяють SSH тільки з підмережі bastion.
Модель VPN: Сервери дозволяють SSH тільки з пулу адрес VPN.
Модель мережі керування: Виділена адмінмережа (on-prem або в хмарі) має доступ; усе інше — ні.

Не змішуйте ці моделі довільно. Змішані підходи породжують суперечливі allow/deny правила і нічні консолі.

2) Ставтеся до IPv6 серйозно

Якщо хост має глобальну IPv6-адресу, інтернет може дістатися до нього по IPv6, якщо тільки upstream-фільтри не обмежують. Розв’язуйте навмисно:

Якщо ви використовуєте IPv6, напишіть v6-allow правила для тих самих джерел, що і для IPv4.
Якщо ви не використовуєте IPv6, або вимкніть його цілеспрямовано (зі тестуванням), або тримайте дефолт-deny і переконайтесь, що клієнти не віддають йому пріоритету.

3) Тримайте правила UFW читабельними

Використовуйте коментарі. Майбутнє «я» — це чужий, якого не треба мучити.

cr0x@server:~$ sudo ufw status numbered
Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     ALLOW IN    198.51.100.0/24             # SSH from mgmt subnet
[ 2] 80/tcp                     ALLOW IN    Anywhere                    # HTTP
[ 3] 443/tcp                    ALLOW IN    Anywhere                    # HTTPS

Рішення: Якщо ваші правила не розповідають історію — перепишіть їх, доки не буде ясно, чому вони існують.

4) Додайте метод відкату для віддалених змін файрволу

У дорослих системах зміни файрволу застосовуються з автоматичним відкатом, якщо тести доступності не пройшли. Ви можете наблизитися до цього навіть без складного інструментарію, виконуючи зміни поетапно і перевіряючи з окремої сесії, або використовуючи планувальник задач для автоматичного відкату, якщо не скасувати його вручну. Якщо ви керуєте продакшном — інвестуйте в справжній механізм змін, а не покладайтеся на сміливість.

Часті питання

1) Мені просто виконати `ufw reset`?

Тільки якщо ви готові втратити всю політику файрволу та перебудувати її. Це грубий інструмент. Краще видалити або переопреді́лити конкретне правило, яке блокує SSH.

2) Чому моя існуюча SSH-сесія залишилась, коли UFW заблокував SSH?

Через stateful filtering. Встановлене з’єднання може залишатися дозволеним, тоді як нові вхідні відхиляються. Це корисно до того моменту, поки ви не від’єднаєтесь і не помітите, що не можете повернутися.

3) Я дозволив `22/tcp`, але все одно не можу підключитись. Яка звична причина?

Найчастіше це невідповідність IPv6, неправильний джерельний IP, upstream-хмарний файрвол або sshd не слухає на потрібному інтерфейсі. Перевіряйте в цьому порядку.

4) Як зрозуміти, чи пакети доходять до сервера взагалі?

Перевірте логи ядра на предмет UFW BLOCK. Якщо бачите блокування — пакети доходять і UFW їх відкидає. Якщо нічого немає — підозрюйте upstream-фільтр або маршрутизацію до того, як пакет дійде до UFW.

5) Чи безпечно тимчасово дозволити SSH з будь-де?

Іноді це єдиний практичний крок, але це не «безпечна» дія. Якщо робите так — компенсуйте: лише ключі, заборона root і негайне видалення широкого allow після відновлення.

6) Чи використовує Ubuntu 24.04 nftables чи iptables з UFW?

UFW — це інтерфейс; під ним може бути різний механізм. Не робіть припущень. Використовуйте ufw show raw та системні інструменти, щоб зрозуміти, що саме застосовується.

7) Чому UFW попереджає, що його увімкнення може порушити SSH?

Бо може. Якщо default incoming стане deny і ви не дозволили SSH належним чином, UFW із задоволенням заблокує нові підключення і, можливо, порушить існуючі потоки в залежності від змін правил.

8) Яка найнадійніша постійна конфігурація SSH для серверів, відкритих в інтернет?

Модель bastion або VPN з allow-листами джерел, лише ключі для автентифікації та суворий логінг. Якщо SSH мусить бути публічним — ставтеся до нього як до публічного API і моніторьте.

9) Я виправив IPv4, але IPv6 досі відмовляє. Чи це проблема?

Якщо ваші користувачі або автоматизація надають перевагу IPv6 — так. Багато клієнтів намагаються підключитись по IPv6 першими. Або дозволяйте IPv6 правильно, або вимикайте його цілеспрямовано з планом тестування.

Висновок: наступні кроки, які варто виконати

Ви відновили SSH правильним шляхом: з консолі, з вузькими дозволами і з доказами з логів, а не інтуїцією. Тепер доведіть справу до кінця.

Видаліть усі TEMP-правила, які ви додали під час відновлення, і замініть їх на задуману політику (VPN/bastion/мережа керування).
Прийміть рішення щодо IPv6 — або підтримайте його належним чином, або послідовно його заблокуйте.
Запишіть мінімальний runbook для вашої команди: порядок швидкої діагностики, точні команди UFW і де знаходиться доступ до консолі.
Впроваджуйте зміни файрволу поетапно: додати allow → перевірити з двох мереж → прибрати старі правила. Нудно — працює.

Схожі статті

Ubuntu 24.04: зміни Netplan не застосовуються — чому (і як зробити їх постійними)