Debian 13: зміна SSH-порту — виправити порядок firewall + sshd без блокування доступу (випадок №27)

Справа №27: що пішло не так (і чому це часто трапляється)

Сценарій виглядає так: хтось змінює SSH з порту 22 на інший — скажімо, 2222 — заради «безпеки».
Вони редагують /etc/ssh/sshd_config, перезавантажують сервіс, потім закривають порт 22 у фаєрволі.
Наступна спроба входу зазнає невдачі, і єдиний шлях повернення — позасітковий консольний доступ, iLO/DRAC, серійна консоль провайдера або тікет до когось, хто має доступ.

У Debian 13 поверхня ризику трохи більша, ніж на старіших системах, бо:
папки include (sshd_config.d) стали звичними, поведінка unit’ів systemd має більше значення, а фаєрволи дедалі частіше на базі nftables навіть коли адміністратор думає «iptables».
Людська помилка послідовна: ви робите дві зміни (sshd + фаєрвол) і не тестуєте їх у правильному порядку.

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

Факти та контекст: чому SSH‑порти й фаєрволи постійно підводять

• SSH не завжди домінував у віддаленому адмініструванні. До того, як він став стандартом, віддалені входи часто здійснювалися через Telnet або rlogin — незашифровані та трагічно довірливі.
• Порт 22 — це конвенція, не доля. Він призначений IANA для SSH, але sshd може прив’язатися до будь‑якого TCP‑порту, який ви вкажете.
• «Безпека зміною порту» — переважно шум. Це зменшує фонові сканування, а не цілеспрямовані атаки. Може бути корисним для чистоти логів, але не плутайте це з контролем доступу.
• OpenSSH популяризував розумні налаштування за замовчуванням. OpenSSH став стандартною реалізацією SSH на Linux/BSD, і більшість очікуваної «поведінки SSH» — це поведінка OpenSSH.
• Debian схилився до використання фрагментів include. Шаблон Include /etc/ssh/sshd_config.d/*.conf полегшує керування конфігом — але помилки переозначення стають тоншими.
• nftables замінив iptables у шляху ядра. Навіть якщо ви виконуєте iptables-команди, підлягаючий набір правил може бути nftables (або ви можете редагувати не те, що потрібно).
• systemd змінює режим невдач. Перезавантаження може пройти, але пізніший restart зазнає невдачі, якщо є прихована проблема; також має значення «який unit зараз активний?».
• Хмарні фаєрволи відокремлені від хостових фаєрволів. Ви можете правильно відкрити nftables, але все одно бути заблокованими групою безпеки провайдера або провайдерським фаєрволом.

Одна цитата, щоб тримати в кишені, бо вона нудна і правильна:
Надія — не стратегія.
— перефразована думка, часто приписувана інженерам з надійності

Ментальна модель: sshd, systemd і «хто володіє портом»

Зміна SSH‑порту — це не одиничний параметр. Це ланцюжок:
клієнт → мережевий шлях → cloud firewall → фаєрвол хоста → слухач sshd → автентифікація.
Якщо будь‑яке з посилань обірвало, користувач відчуває «SSH впав». Ваше завдання — швидко визначити, яке посилання зламалося, не погіршуючи ситуацію.

Шарування конфігурації sshd: порядок файлів має значення

Debian зазвичай використовує /etc/ssh/sshd_config плюс один чи більше фрагментів під /etc/ssh/sshd_config.d/.
Ефективна конфігурація — результат читання головного файлу та застосування include у лексикальному порядку.
Це означає, що 00-foo.conf може бути переозначений 99-bar.conf.
«Я змінив Port у sshd_config» нічого не означає, якщо пізніший include знову його встановлює.

Декілька портів: ваша карта втечі

OpenSSH підтримує кілька директив Port. Якщо ви вкажете два порти, sshd слухатиме обидва.
Це найнадійніший спосіб міграції: залиште 22 для існуючої автоматизації, додайте 2222 для нового доступу, потім пізніше приберіть 22.

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

У кожної системи фаєрволу є концепт порядку оцінки правил.
Але операційна істина простіша: якщо треба зберегти доступ — додайте дозволи для нового порту
до того, як видалите дозволи для старого. Кожного разу. Без винятків для «швидких змін».

Жарт №1: змінювати SSH‑порти без другої сесії — як оновлювати прошивку у п’ятницю: можна, але ви проходите кастинг на наслідки.

Швидка діагностика (перший/другий/третій)

Це потік «мені потрібні відповіді за п’ять хвилин». Не імпровізуйте. Дотримуйтесь ланцюга.

Перший: чи слухає sshd там, де ви думаєте?

• Перевірте слухаючі сокети (ss).
• Перевірте ефективну конфігурацію sshd (sshd -T).
• Перевірте статус сервісу та останні логи (systemctl, journalctl).

Другий: чи дозволяє це фаєрвол хоста?

• Визначте, яка система фаєрволу дійсно в дії: nftables, ufw або застарілий iptables.
• Підтвердіть, що існує правило allow для нового порту з ваших джерел мережі.
• Переконайтесь, що немає пізнішого правила deny, яке його затінює.

Третій: чи щось поза хостом блокує вас?

• Cloud security group / фаєрвол провайдера.
• Мережеві ACL, корпоративний периметр, політика VPN.
• Балансувальник навантаження або очікування бастіону (неспівпадіння порту).

Практичні завдання: 14 команд, виводів та рішень

Це не «запустити команди заради забави». Кожна відповідає на конкретне питання і призводить до рішення.
Запускайте їх із існуючої SSH‑сесії, якщо вона ще є, і тримайте цю сесію відкритою до кінця.

Завдання 1 — Підтвердіть версію Debian та припущення середовища

cr0x@server:~$ cat /etc/debian_version
13.0

Що це означає: Ви на Debian 13. За замовчуванням поведінка пакунків (включно з include для sshd) має відповідати очікуванням.
Рішення: Дійте, припускаючи OpenSSH + systemd за замовчуванням; все одно перевіряйте include.

Завдання 2 — Перевірте, чи запущений sshd і як systemd його бачить

cr0x@server:~$ systemctl status ssh
● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; enabled; preset: enabled)
     Active: active (running) since Mon 2025-12-30 08:41:12 UTC; 2h 11min ago
       Docs: man:sshd(8)
             man:sshd_config(5)
   Main PID: 914 (sshd)
      Tasks: 1 (limit: 19190)
     Memory: 7.2M
        CPU: 1.184s
     CGroup: /system.slice/ssh.service
             └─914 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups"

Що це означає: sshd запущений.
Рішення: Якщо він не активний, не чіпайте фаєрволи — спочатку виправте 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=914,fd=3))
LISTEN 0      128          0.0.0.0:2222      0.0.0.0:*    users:(("sshd",pid=914,fd=4))
LISTEN 0      128             [::]:22           [::]:*    users:(("sshd",pid=914,fd=5))
LISTEN 0      128             [::]:2222         [::]:*    users:(("sshd",pid=914,fd=6))

Що це означає: Ви в безпечному стані: sshd слухає і на старому, і на новому порту, IPv4 та IPv6.
Рішення: Тепер можна працювати з правилами фаєрволу для 2222 без ризику втратити доступ.

Завдання 4 — Виведіть ефективну конфігурацію sshd (не те, що ви думаєте, що встановили)

cr0x@server:~$ sudo sshd -T | grep -E '^(port|listenaddress|passwordauthentication|pubkeyauthentication)\b'
port 22
port 2222
listenaddress 0.0.0.0
listenaddress ::
passwordauthentication no
pubkeyauthentication yes

Що це означає: Ефективна конфігурація містить обидва порти; парольна автентифікація вимкнена (добре).
Рішення: Якщо потрібного порту тут немає — зупиніться і виправте порядок include/синтаксис перед тим, як чіпати фаєрвол.

Завдання 5 — Проінспектуйте порядок include і знайдіть перевизначення

cr0x@server:~$ grep -nE '^(Include|Port)\b' /etc/ssh/sshd_config
12:Include /etc/ssh/sshd_config.d/*.conf
18:Port 22

cr0x@server:~$ ls -la /etc/ssh/sshd_config.d/
total 16
drwxr-xr-x 2 root root 4096 Dec 30 08:40 .
drwxr-xr-x 4 root root 4096 Dec 30 08:10 ..
-rw-r--r-- 1 root root   26 Dec 30 08:40 10-ports.conf
-rw-r--r-- 1 root root  124 Dec 30 08:10 50-hardening.conf

cr0x@server:~$ cat /etc/ssh/sshd_config.d/10-ports.conf
Port 22
Port 2222

Що це означає: Зміна порту знаходиться у фрагменті. Це зручніше для підтримки і краще працює з інструментами керування конфігом.
Рішення: Віддавайте перевагу окремому файлу‑фрагменту для портів; уникайте редагування файлів, якими керує вендор, якщо ви їх не адмініструєте.

Завдання 6 — Перевірте синтаксис конфігурації sshd перед reload/restart

cr0x@server:~$ sudo sshd -t

Що це означає: Відсутній вивід означає, що синтаксис OK.
Рішення: Якщо є помилки — не перезапускайте. Виправте конфіг до тих пір, поки sshd -t не буде чистим.

Завдання 7 — Визначте, який інструмент фаєрволу керує правилами (не здогадуйтеся)

cr0x@server:~$ sudo systemctl is-active nftables
inactive

cr0x@server:~$ sudo systemctl is-active ufw
active

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

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    10.20.0.0/16

Що це означає: UFW застосовує політику вхідного трафіку; сервіс nftables окремо неактивний.
Рішення: Керуйте змінами SSH через UFW, а не через ad‑hoc nft‑команди, які можуть не зберігатися під контролем UFW.

Завдання 8 — Додайте правило allow для нового SSH‑порту, обмеживши за джерелом

cr0x@server:~$ sudo ufw allow from 10.20.0.0/16 to any port 2222 proto tcp
Rule added

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

     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     ALLOW IN    10.20.0.0/16
[ 2] 2222/tcp                   ALLOW IN    10.20.0.0/16

Що це означає: Новий порт дозволений з тієї самої мережі, що й старий.
Рішення: Не дозволяйте 2222 з «Anywhere», якщо немає вагомої причини. Якщо таки дозволяєте — логуйте і застосуйте обмеження по швидкості.

Завдання 9 — Підтвердіть, що ядро бачить дозвіл трафіку (nft під UFW)

cr0x@server:~$ sudo nft list ruleset | grep -nE 'tcp dport (22|2222)' | head
187: tcp dport 22 ct state new counter accept
190: tcp dport 2222 ct state new counter accept

Що це означає: Під капотом UFW додав правила nftables, які дозволяють обидва порти.
Рішення: Якщо ви не бачите 2222 тут — ваші зміни UFW не застосувалися або інший шар фаєрволу їх переозначив.

Завдання 10 — Протестуйте новий порт всередині хоста (саніті‑чек)

cr0x@server:~$ ssh -p 2222 -o BatchMode=yes -o ConnectTimeout=3 localhost 'echo ok'
ok

Що це означає: Слухач sshd на 2222 приймає з’єднання і ваш ключ‑автентифікація працює.
Рішення: Якщо localhost не проходить — зовнішній доступ теж не вдасться. Виправляйте sshd/auth перед зміною периметру.

Завдання 11 — Протестуйте новий порт з віддаленої машини до закриття 22

cr0x@server:~$ sudo journalctl -u ssh -n 5 --no-pager
Dec 30 10:51:07 server sshd[3842]: Accepted publickey for cr0x from 10.20.14.9 port 51788 ssh2: ED25519 SHA256:3kz...
Dec 30 10:51:07 server sshd[3842]: pam_unix(sshd:session): session opened for user cr0x(uid=1000) by (uid=0)
Dec 30 10:51:10 server sshd[3842]: pam_unix(sshd:session): session closed for user cr0x

Що це означає: Хтось (сподіваюсь, ви) недавно підключився успішно. Логи підтверджують прийняття, IP джерела і метод автентифікації.
Рішення: Не закривайте порт 22, поки не побачите успішний логін на 2222 з тієї мережі, якою ви фактично користуєтесь.

Завдання 12 — Перевірте припущення про cloud/провайдера (Linux тут не допоможе)

cr0x@server:~$ sudo ss -ltnp | grep ':2222 '
LISTEN 0      128          0.0.0.0:2222      0.0.0.0:*    users:(("sshd",pid=914,fd=4))

Що це означає: Хост слухає. Якщо віддалені підключення все ще таймаутяться — підозрюйте upstream контролі.
Рішення: Перевірте firewall провайдера/group безпеки/NACL і відкрийте TCP/2222 з ваших діапазонів. Не вважайте, що фаєрвол хоста — єдиний шлюз.

Завдання 13 — Безпечно перезавантажте sshd; уникайте restart, якщо не потрібно

cr0x@server:~$ sudo systemctl reload ssh

cr0x@server:~$ systemctl show -p ActiveState,SubState,ExecMainStatus ssh
ActiveState=active
SubState=running
ExecMainStatus=0

Що це означає: Reload не вбив ваш слухач.
Рішення: Віддавайте перевагу reload для змін конфігурації. Restart голосніший і більш схильний до помилок, якщо щось пішло не так.

Завдання 14 — Виведіть порт 22 тільки після підтвердженого успіху, потім підтвердіть сокети

cr0x@server:~$ sudo sed -i 's/^Port 22$/# Port 22/' /etc/ssh/sshd_config.d/10-ports.conf

cr0x@server:~$ sudo sshd -t

cr0x@server:~$ sudo systemctl reload ssh

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

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

Що це означає: sshd більше не прив’язується до 22, і фаєрвол більше його не дозволяє.
Рішення: Робіть це тільки після того, як довели, що 2222 працює ззовні. Все одно тримайте поточну сесію відкритою — бо ви любите спокійний сон.

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

Перевірки перед польотом (перш ніж щось чіпати)

• Майте два шляхи доступу: дві SSH‑сесії або SSH + консольний доступ (серійна консоль хмари, IPMI тощо). Якщо у вас тільки один шлях — зупиніться.
• Знайте шари фаєрволу: фаєрвол провайдера + фаєрвол хоста + корпоративні ACL. Запишіть, де треба відкрити порт.
• Підтвердіть режим автентифікації: якщо ви вимикаєте парольну автентифікацію — перевірте, що ключі працюють ЗАРАЗ. Не комбінуйте «зміну порту» з «жорсткістю автентифікації» в одній операції.
• Визначте область доступу: «дозволити з VPN‑підмережі» краще, ніж «дозволити звідусіль», якщо ви не створюєте публічний бастіон.
• Виберіть порт з наміром: не обирайте 2222 тільки тому, що його всі використовують, якщо не хочете галасливих логів. Оберіть порт, що підходить вашій моделі експлуатації.

План виконання (порядок, що запобігає блокуванню)

1. Додайте новий порт в sshd як додатковий слухач. Не видаляйте 22 поки що.
2. Валідуйте конфіг: sshd -t та sshd -T | grep ^port.
3. Reload sshd (а не restart) і переконайтесь, що ss показує обидва порти.
4. Відкрийте новий порт у фаєрволі хоста. Перевірте правила на рівні ядра (nft/iptables view), щоб уникнути ситуації «UFW каже так, а в ядрі — ні».
5. Відкрийте новий порт у верхніх шарах (cloud SG, фаєрвол провайдера, корпоративні ACL) перед тим, як тестувати ззовні.
6. Тестуйте з мережі, якою ви реально користуєтесь. Підтвердіть, що логи показують прийняте з’єднання на новому порту.
7. Оновіть автоматизацію й інструменти: Ansible inventory, конфігурації бастіонів, моніторинг, jump hosts і людські рукописи.
8. Тільки потім видаліть порт 22 з sshd і фаєрволу, у такому порядку: sshd перестає слухати, потім фаєрвол перестає дозволяти.
9. Післязмінна перевірка: віддалений логін на новому порту, підтвердження, що 22 закритий (connection refused або filtered), і спостереження за логами на предмет помилок.

План відкату (він вам знадобиться колись)

• Якщо новий порт не працює, але у вас ще є існуюча сесія: додайте знову Port 22, reload sshd, знову додайте allow для 22 у фаєрволі і протестуйте.
• Якщо ви заблоковані: використайте консольний доступ, відкотіть фрагмент sshd, reload, потім виправте фаєрвол. Якщо у вас немає консолі — вітаємо: ви дізналися, чому консольний доступ є обов’язковим.

Жарт №2: фаєрволи — як офісна політика: всі про них забувають, поки вони не заважають працювати.

Три корпоративні історії (як команди насправді отримують опіки)

Інцидент: хибне припущення («ми відкрили порт»)

Платформна команда перевела SSH з 22 на 22022 по всьому кластеру. У них була стандартна процедура: змінити sshd, потім оновити UFW.
Зміни виглядали чистими в їхньому інструменті конфігурацій. Вікно для релізу було тихим. Потім почали надходити повідомлення, що підмножина хостів недоступна.

Інженер on‑call перевірив один із «мертвих» хостів через позасіткову консоль і знайшов sshd, який слухає 22022, саме як задумано.
UFW теж показував правило allow для 22022. У той момент впевненість у всіх підросла — і того не мав би сталося.

Відсутнім ланцюжком був upstream: ті хости жили в іншому проекті хмари з суворішою базовою політикою фаєрволу провайдера.
Порт 22 мав явне дозволення з корпоративного VPN, а інші вхідні порти вимагали окремого процесу винятків.
Інструмент конфігурації не мав видимості цього шару, тож «ми відкрили порт» було правдою лише всередині VM.

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

Оптимізація, що обернулась проти: «restart чистіший за reload»

Інша команда не любила дрейф конфігурацій. Їхній внутрішній стиль вимагав рестарту сервісів після будь‑якої зміни конфігу.
Для sshd вони використовували systemctl restart ssh як жорстке правило. Звучало дисципліновано.

Під час міграції порту у фрагменті прослизнула безпечна на вигляд орфографічна помилка — невірна опція в неправильному Match‑блоці.
Помилка синтаксису не проявлялася до restart. Reload теж би зафіксував помилку, але restart спричинив ширшу проблему: sshd зупинився,
і оскільки systemd вважав старт невдалим, був невеликий затримка на повторні спроби. Існуючі сесії залишалися, але нові підключення блокувалися.

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

Після цього вони не відмовилися від рестартів зовсім. Вони стали розумнішими: валідувати конфіги sshd -t, віддавати перевагу reload коли можливо,
і планувати рестарти лише коли ризик прийнятний. «Чистіше» — не означає відповідність SLO.

Нудно, але правильно: паралельні порти + поетапний фаєрвол врятували день

Компанія, близька до фінансів, мала вимогу відповідності: «перенести SSH з 22 скрізь». Команда безпеки хотіла швидкого виконання.
Операційний лід відмовився. Не тому, що він любив порт 22, а тому, що любив аптайм більше.

Вони реалізували двофазний план. Фаза 1: додати другий порт у sshd по всіх хостах, відкривши його тільки з CIDR‑ів VPN,
і оновити бастіони та автоматизацію, щоб віддавати перевагу новому порту. Нічого не видаляли. Кожен сервер завершував фазу 1 з двома дверима.

Вони чекали повний цикл змін. За цей час дивилися логи на предмет клієнтів, що досі використовують 22 — старі скрипти, забуті jump‑хости,
пристрої вендорів і чиїсь «тимчасові» cron‑задачі, що пережили три квартали.

Фаза 2 була антикліматичною: видалити порт 22 з sshd, потім видалити allow у фаєрволі. Ніяких блокувань, ніякої драми.
Було майже сумно, і це правильна емоційна реакція на зміну інфраструктури.

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

1) Симптом: «Connection refused» на новому порту

Корінна причина: sshd не слухає на тому порту (конфіг не застосовано, перевизначення include або reload/restart зазнав невдачі).

Виправлення: Перевірте ss -ltnp і sshd -T | grep ^port. Виправте порядок конфігів у sshd_config.d. Запустіть sshd -t, потім systemctl reload ssh.

2) Симптом: «Connection timed out» на новому порту

Корінна причина: фаєрвол блокує upstream (cloud security group, фаєрвол хоста або ACL) або проблема маршрутизації.

Виправлення: Підтвердіть, що хост слухає; потім підтвердіть, що існує правило хоста; потім перевірте, чи провайдер дозволяє цей порт. Таймаути зазвичай означають «drop», а не «reject».

3) Симптом: UFW показує allow, але трафік все ще заблокований

Корінна причина: ви насправді не користуєтесь правилами UFW (інший менеджер фаєрволу активний), або пізніше правило їх затінює.

Виправлення: Перевірте за допомогою nft list ruleset і стани сервісів. Якщо nftables використовує окремі правила, визначте одного власника і відключіть інший.

4) Симптом: sshd слухає на IPv4, але не на IPv6 (або навпаки)

Корінна причина: параметри AddressFamily або ListenAddress, або IPv6 вимкнено в системі/мережі.

Виправлення: Перевірте ss -ltnp на наявність [::]:PORT. Підтвердіть sshd -T | grep listenaddress. Навмисно відкоригуйте конфіг; не покладайтеся на значення за замовчуванням, якщо це важливо.

5) Симптом: можете SSH із самого хоста, але не ззовні

Корінна причина: upstream фаєрвол або маршрут блокує; тест на localhost обходить ці шари.

Виправлення: Тестуйте з піар‑машини в тій же підмережі/VPN. Перевірте правила провайдера. Не святкуйте, бо localhost працює.

6) Симптом: існуючі сесії залишаються, але нові не відкриваються після зміни

Корінна причина: restart sshd зазнав невдачі або порти слухача змінилися несподівано; встановлені TCP‑сесії живі до закриття.

Виправлення: Перевірте systemctl status ssh і journalctl -u ssh. Відновіть порти‑слухачі і зробіть reload. Тримайте одну сесію відкритою поки не валідуєте нові логіни.

7) Симптом: автоматизація ламається (Ansible, скрипти, моніторинг)

Корінна причина: клієнти хардкодять порт 22 або покладаються на ~/.ssh/config, який не розгорнуто повсюдно.

Виправлення: Оновіть інвентарі й SSH‑конфіги, або використайте DNS‑бастіони з централізованою конфігурацією. Проведіть аудит логів перед видаленням 22.

8) Симптом: порт видається відкритим, але автентифікація на новому порту провалюється

Корінна причина: Match‑блоки застосовуються відмінно (за LocalPort, Address або User), або невідповідність PAM/AllowUsers.

Виправлення: Перегляньте sshd -T і логіку Match. Перевірте логи на причини відмови автентифікації; виправте Match‑блоки, щоб обидва порти мали потрібну політику.

Часті питання (FAQ)

1) Чи покращує безпеку фактично зміна SSH‑порту?

Це зменшує опортуністичний шум (масові сканування на 22), що може підвищити співвідношення сигнал/шум у логах.
Це не замінює реальні заходи: автентифікація ключами, відключення паролів, MFA на бастіонах і суворі allowlists за джерелом.

2) Чи варто тримати SSH на двох портах назавжди?

Тимчасово — так, під час міграції це найнадійніший підхід. Назавжди — зазвичай ні: ви збільшуєте експоновану поверхню без операційної вигоди.
Тримайте два порти тільки якщо маєте чітке обґрунтування (окремий шлях бастіона vs внутрішній доступ) і задокументуйте це.

3) Де розміщувати директиву Port на Debian 13?

Помістіть її в окремому фрагменті, наприклад /etc/ssh/sshd_config.d/10-ports.conf.
Це легше керувати, простіше аудитувати і менш імовірно, що її перезапише пакет або інше ПЗ.

4) В чому різниця між «connection refused» і «timed out»?

Refused зазвичай означає активне відхилення з’єднання — ніхто не слухає або фаєрвол відкидає.
Timed out зазвичай означає, що пакети губляться — часто це upstream фаєрвол або проблеми маршрутизації.
Діагностуйте їх по‑різному.

5) Reload чи restart sshd?

Віддавайте перевагу reload для змін конфігурації. Це менш руйнівно. Все одно валідуйте за допомогою sshd -t перед дією.
Restart — коли справді потрібно, а не за інерцією.

6) Як підтвердити, яким портом фактично користується sshd?

Використовуйте ss -ltnp щоб побачити живі слухачі та sshd -T щоб побачити ефективну конфігурацію.
Не довіряйте «я відредагував файл». Довіряйте тому, що робить процес.

7) Я відкрив порт у VM‑фаєрволі. Чому не можу підключитися?

Бо ваша VM — не єдиний фаєрвол. Cloud security groups/фаєрвол провайдера і корпоративні ACL можуть блокувати.
Якщо хост слухає і фаєрвол хоста дозволяє — підозрюйте upstream шари.

8) Який номер порту обрати?

Оберіть щось, що не конфліктує з локальними сервісами і легко стандартизувати в команді.
Уникайте «популярних альтернатив», якщо ви хочете зменшити шум. Але не вибирайте настільки дивний порт, що ніхто його не запам’ятає.
Стандартизація важливіша за креатив.

9) Чи можна змінити SSH‑порт без простою?

Зазвичай так: додайте додатковий порт, reload, відкрийте фаєрвол, протестуйте, потім видаліть старий порт.
Існуючі сесії залишаться; нові можна поступово переносити.

Наступні кроки, що зберігають вашу роботу

Ставтеся до зміни SSH‑порту як до будь‑якої іншої продакшн‑зміни: етапуйте, валідуйте, забезпечуйте відкат.
Правильний порядок не опційний: sshd слухає обидва → фаєрвол дозволяє обидва → тест нового порту → оновіть клієнти → приберіть старий порт.
Усе інше — гра в азартні ігри з доступом.

Практичні наступні кроки:

• Прийміть стандартний файл‑фрагмент для портів SSH під /etc/ssh/sshd_config.d/.
• Закріпіть правило «дві сесії» для змін віддаленого доступу.
• Зробіть власність фаєрволу явною (UFW vs nftables vs config management) і приберіть проблему «двоє капітанів».
• Аудитуйте логи на предмет залишкового використання порту 22 перед його закриттям, особливо автоматизацію та вендорські інструменти.
• Задокументуйте шлях відкату і переконайтесь, що консольний доступ існує перед початком.