SSH: Connection refused чи Connection timed out

Що означають помилки «Connection refused» і «Connection timed out» в SSH

Помилка Connection refused під час SSH-з’єднання та помилка Connection timed out означають протилежні проблеми, тому виправлення для однієї з них ніколи не усуває іншу. Connection refused означає, що пакет дійшов до сервера, а ядро сервера відповіло: «тут нічого не прослуховується». Connection timed out означає, що пакет не дійшов до вузла, який міг би відповісти, тому клієнт зачекав і завершив спробу. Connection refused — це проблема сервісу на сервері. Connection timed out — це проблема мережевого шляху перед сервером.

Прочитайте точний рядок, який вивів клієнт, оскільки формулювання містить повний діагноз.

ssh: connect to host 203.0.113.10 port 22: Connection refused
ssh: connect to host 203.0.113.10 port 22: Connection timed out

Час очікування — друга підказка. Connection refused повертається одразу, приблизно за час одного проходження пакета в обидва боки. У разі Connection timed out клієнт не завершує спробу багато секунд, оскільки повторно надсилає пакети, перш ніж припинити очікування. macOS виводить Operation timed out для тієї самої умови. Якщо сам протокол вам ще незнайомий, як працює SSH і що робить sshd — це базова інформація, на яку спирається цей посібник.

Чому «Connection refused» — це добра новина

Відмова — це TCP reset (скидання з’єднання). Клієнт надсилає SYN-пакет на порт 22. Він проходить через Інтернет, надходить до мережевого стека сервера, і ядро не знаходить сокет, який прослуховує цей порт, тому відповідає пакетом RST (reset). SSH-клієнт перетворює цей RST на повідомлення Connection refused.

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

• sshd не запущено, оскільки його запуск завершився помилкою або unit не було ввімкнено.
• sshd прослуховує інший порт, зазвичай після зміни параметрів hardening.
• sshd прив’язано до однієї адреси, наприклад ListenAddress 127.0.0.1, тому підключитися до нього може лише сам сервер.
• Firewall налаштовано на відхилення, а не на відкидання пакетів, тому він надсилає RST від імені хоста. Це роблять дія ufw reject і правило nftables, що закінчується на reject with tcp reset.

Є ще один випадок, який виглядає так само, але має іншу причину: ви ввели адресу іншого активного хоста. Цей хост відповідає на ваш SYN, не має SSH на порту 22 і ввічливо відхиляє підключення. Перевірте адресу, перш ніж витратити годину на неправильний сервер. Якщо ви знаєте що насправді означає порт, який прослуховується, у Linux, решту цього розділу буде легше читати.

Як виправити помилку Connection refused

Цю проблему не можна виправити через SSH, оскільки саме SSH не працює. Відкрийте web console або serial console свого провайдера, увійдіть до системи через неї та послідовно виконайте наведені команди.

systemctl status ssh
sudo ss -tlnp
sudo sshd -T | grep -Ei '^(port|listenaddress|addressfamily)'

systemctl status ssh використовує назву unit в Ubuntu та Debian. У RHEL і його збірках, зокрема AlmaLinux, unit має назву sshd. ss -tlnp показує всі TCP-сокети у стані listening разом із процесом, якому вони належать. Це фактичне джерело даних: якщо жоден рядок не містить sshd, нічого не прослуховує з’єднання, незалежно від того, що вказано у файлі конфігурації. sshd -T виводить ефективну конфігурацію після об’єднання всіх файлів Include. Саме тут видно порт, який випадково пропущено у /etc/ssh/sshd_config.d/.

Уважно перевірте стовпець адреси. 0.0.0.0:22 означає всі IPv4-адреси системи. [::]:22 означає всі IPv6-адреси. 127.0.0.1:22 означає лише loopback, тому всі віддалені підключення до цієї адреси відхиляються, а локальне ssh localhost працює без проблем.

Якщо нічого не прослуховує з’єднання, запустіть сервіс і перегляньте повідомлення про помилку, через яку він не запускається.

sudo sshd -t
sudo systemctl enable --now ssh
sudo journalctl -u ssh -n 50 --no-pager

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

Пастка socket activation в Ubuntu

В Ubuntu 24.04 постачається socket unit systemd для OpenSSH. Якщо цей unit увімкнено, systemd утримує порт у стані прослуховування та запускає sshd для кожного підключення, тому Port 2222 у sshd_config нічого не змінює, і сервер продовжує відповідати на старому порту. Перед редагуванням перевірте, який режим використовується.

systemctl is-enabled ssh.socket
systemctl status ssh.socket

Якщо socket увімкнено, задайте порт у socket unit, а не в sshd_config.

sudo systemctl edit ssh.socket

[Socket]
ListenStream=
ListenStream=2222

Порожній рядок ListenStream= обов’язковий, оскільки systemd додає параметри списків до вже налаштованих. Якщо не додати його, сервер прослуховуватиме обидва порти. Застосуйте зміну за допомогою sudo systemctl daemon-reload і sudo systemctl restart ssh.socket, а потім перевірте за допомогою sudo ss -tlnp, що новий порт утримується саме цим unit. Зміна порту є стандартним кроком для зміцнення захисту SSH на VPS, і саме через цей крок користувачі найчастіше втрачають доступ.

Чому «Connection timed out» нічого не повідомляє

Тайм-аут означає відсутність відповіді. Клієнт надіслав SYN-пакет, повторив спробу кілька разів протягом однієї-двох хвилин і не отримав у відповідь жодного пакета. Це нічого не доводить про сервер, оскільки від нього не надійшло жодної відповіді.

Саме таку тишу створює правило DROP, а відкидання пакетів є навмисним. Відмова повідомляє тому, хто сканує мережу, що хост існує. Тому ufw і мережевий firewall кожного cloud-провайдера відкидають небажані пакети та нічого не надсилають у відповідь. Зазвичай тайм-аут означає, що firewall виконує свою роботу на порту, який ви хотіли відкрити.

• Адреса неправильна: DNS-запис досі вказує на сервер, який ви перебудували, або через помилку в адресі запит надходить на адресу, якою ніхто не користується.
• Хост не працює: його вимкнено або він перебуває в процесі перезавантаження. Призупинення роботи провайдером через несплату має такий самий вигляд іззовні.
• Firewall хоста відкидає пакети на порт 22. Найчастіше це відбувається через те, що ufw enable було виконано до створення будь-якого правила allow.
• Firewall провайдера перед інстансом відкидає пакет, і операційна система взагалі його не бачить.
• Ваша мережа блокує вихідні підключення до порту 22. Це поширено в офісних мережах і мережах готелів.

Виконайте тест із потрібного боку з’єднання

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

getent hosts vps.example.com
ssh -G vps.example.com | grep -Ei '^(hostname|port|user)'
ssh -vvv -o ConnectTimeout=10 user@vps.example.com
nc -vz -w 5 203.0.113.10 22

getent hosts показує адресу, яку фактично використовуватиме ваш комп’ютер. Це дає змогу за лічені секунди виявити застарілий запис DNS. ssh -G виводить параметри, які застосовує ваш клієнт після читання ~/.ssh/config. Тому команда виявляє старий блок Host, який непомітно змінює ім’я хоста, порт або користувача. ssh -vvv показує, наскільки далеко просунулася спроба підключення: останній рядок із повідомленням про підключення до адреси, після якого настає тривала пауза, означає тайм-аут. Рядок із версією віддаленого OpenSSH означає, що TCP-підключення вже встановлено, а справжня проблема пов’язана з автентифікацією. У Windows Test-NetConnection 203.0.113.10 -Port 22 у PowerShell замінює nc.

Перевіряйте порт, а не хост. Помилка ping нічого не доводить, оскільки багато провайдерів фільтрують ICMP (internet control message protocol) на периферії мережі. Успішний ping також нічого не доводить, оскільки він не перевіряє порт 22.

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

Провайдерський firewall, якого не видно із сервера

Більшість панелей керування VPS пропонують мережевий firewall, який іноді називають security group або cloud firewall. Він працює перед вашим інстансом і має власний список правил. ufw status на сервері не може його побачити, тому фраза «але я вже дозволив порт 22» трапляється так часто. Відкрийте панель і перегляньте цей список, перш ніж змінювати хоча б одне правило на сервері.

Однією командою можна визначити причину, але для цього потрібен доступ до консолі. Запустіть її на сервері, а потім спробуйте підключитися з ноутбука, поки вона працює.

sudo tcpdump -ni any tcp port 22

Якщо під час спроби підключення клієнта нічого не з’являється, пакети відкидаються ще до того, як досягають операційної системи. Отже, проблема в provider firewall або в маршруті до хоста. Якщо SYN-пакети надходять, але відповідь не виходить, відкидання відбувається локально та пов’язане з ufw або nftables. Цей простий тест ділить гілку діагностики тайм-ауту навпіл, тому заради нього варто підключитися до консолі.

Порядок правил ufw, IPv6 і блокування власної адреси

Помилка в порядку налаштування ufw блокує доступ частіше за будь-яку іншу причину в цьому розділі. sudo ufw enable одразу встановлює політику за замовчуванням deny incoming, тому без правила для SSH поточна сесія зберігається завдяки вже встановленому з’єднанню, а кожне нове з’єднання завершується тайм-аутом. Спочатку дозвольте доступ, а потім увімкніть ufw.

sudo ufw allow OpenSSH
sudo ufw status verbose

Профіль застосунку OpenSSH охоплює лише порт 22. Якщо ви плануєте перенести SSH на порт 2222, потрібне правило sudo ufw allow 2222/tcp. Додайте його до зміни порту, а не після неї. Розширений набір правил описано в основах ufw firewall для VPS, а безпечний порядок дій наведено в інструкції для перших десяти хвилин на новому VPS.

IPv6 може спричинити тайм-аут, який здається незрозумілим. Якщо hostname має запис AAAA, клієнт спочатку використовує IPv6. Тому сервер без потрібних правил для IPv6 зависає, тоді як звичайна спроба через IPv4 працює. Перевірте ці два протоколи окремо.

ssh -4 user@vps.example.com
ssh -6 user@vps.example.com

Якщо -4 підключається, а -6 — ні, проблему потрібно виправляти в правилах IPv6 на сервері. Інструкція як відкрити той самий порт для IPv6 у ufw описує ці кроки.

Можливо, ви також заблокували власну адресу. fail2ban відстежує журнал автентифікації та додає правило firewall для адрес, з яких багато разів надходять невдалі спроби. Тому неправильний ключ або скрипт, що повторює спроби у фоновому режимі, може заблокувати адресу всього офісу. Блокування з відкиданням пакета виглядає як тайм-аут. Блокування з відхиленням повертає No route to host. Виконайте з консолі:

sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 198.51.100.24

Додавання власної адреси до ignoreip є частиною робочого налаштування fail2ban на Ubuntu 24.04.

Помилки, які не є відмовою в підключенні або перевищенням часу очікування

No route to host означає, що надійшло повідомлення ICMP про недосяжність. Або ваш власний комп’ютер не має маршруту до цієї мережі, або один із вузлів на шляху відповів адміністративною відмовою. Саме так відповідає правило iptables REJECT.

Network is unreachable надходить від вашого власного комп’ютера. Для цієї адресної родини взагалі немає маршруту. Це типова відповідь, коли ім’я хоста резолвиться лише в IPv6-адресу, а підключення працює тільки через IPv4.

kex_exchange_identification: Connection closed by remote host означає, що TCP-підключення встановилося, але сервер розірвав його до завершення обміну ключами. Порт відкритий, а sshd працює. Перевірте навантаження на сервер, MaxStartups або блокування, яке могло спрацювати під час підключення.

Permission denied (publickey) означає, що ви дійшли до автентифікації, але вона завершилася помилкою. Мережа та firewall працюють, тому цей посібник тут не допоможе. Перейдіть до матеріалу як виправити Permission denied (publickey) в SSH.

Як повернути доступ і як уникнути повторного блокування

Кожен надійний VPS-хостинг надає консоль, яка не залежить від мережі гостьової системи: serial console або браузерний екран VNC. Ця консоль є способом відновлення доступу в обох варіантах цього посібника, оскільки вона працює, навіть коли sshd зупинено або правило firewall відкидає весь трафік. Знайдіть її в панелі керування, увійдіть як root або як звичайний користувач і виконайте наведені вище перевірки. Якщо пароль root ніколи не налаштовувався, у більшості панелей його можна скинути.

Якщо консоль недоступна, скористайтеся rescue mode, який надає провайдер. Він завантажує невелику систему відновлення та монтує ваш диск, щоб ви могли офлайн відредагувати /etc/ssh/sshd_config або видалити правило firewall і перезавантажити сервер.

Дві звички допоможуть уникнути наступного блокування. Під час редагування sshd або firewall залишайте відкритою другу SSH-сесію, оскільки вона продовжує працювати завдяки вже встановленому з’єднанню, поки ви перевіряєте нове. Також налаштовуйте автоматичне скасування перед внесенням ризикованих змін до firewall.

sudo systemd-run --unit=ufw-rollback --on-active=10min /usr/sbin/ufw disable
sudo systemctl stop ufw-rollback.timer

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

Порядок дій

1. Прочитайте текст помилки та зверніть увагу, через який час вона з’явилася.
2. Refused: відкрийте консоль і перевірте в sudo ss -tlnp listening socket, його порт і адресу, на якій він прослуховується.
3. Timed out: на власному комп’ютері перевірте адресу, потім firewall провайдера в панелі керування, а далі firewall хоста на сервері.
4. Якщо немає жодного з цих рядків: TCP-з’єднання вже встановлено, тому розглядайте проблему як питання автентифікації або навантаження на сервер, а не мережі.

FAQ

Чому SSH повідомляє «Connection refused», якщо sshd запущено?

Відмова надходить від сокета, а не від служби. Запущений sshd все одно може відхиляти підключення. Відкрийте консоль провайдера та виконайте sudo ss -tlnp. Сокет на 127.0.0.1:22 відхиляє всіх віддалених клієнтів, оскільки прив’язаний лише до loopback. Сокет на іншому порту відхиляє всіх клієнтів, які й далі використовують 22. Якщо використовується активація сокета через systemd, порт береться з ssh.socket, а не з sshd_config, тому також перевірте systemctl is-enabled ssh.socket. Правило ufw reject також може спричиняти відмову від імені хоста, тому перед висновками прочитайте sudo ufw status verbose.

Чому SSH завершується через тайм-аут, якщо ufw уже дозволяє порт 22?

Тайм-аут означає, що відповідь не надійшла. ufw — не єдиний firewall на цьому шляху. Більшість панелей VPS запускають мережевий firewall перед інстансом, і операційна система не бачить пакети, які цей firewall відкидає. У консолі виконайте sudo tcpdump -ni any tcp port 22 і спробуйте підключитися з ноутбука, поки команда працює. Якщо пакети не надходять, їх відкидає upstream firewall у панелі. Якщо пакети надходять, але відповідь не виходить, їх відкидає локальний firewall — ufw або nftables.

Чи означає невдалий ping, що мій VPS недоступний?

Ні. Багато провайдерів фільтрують ICMP на межі мережі. Тому сервер, який нормально обслуговує traffic, може ігнорувати всі надіслані вами ping. Успішний ping так само мало що підтверджує, оскільки він не показує, чи відкритий порт 22. Перевірте сам порт за допомогою nc -vz -w 5 203.0.113.10 22 зі свого комп’ютера або Test-NetConnection 203.0.113.10 -Port 22 у PowerShell на Windows.

Я змінив порт SSH, і тепер нічого не підключається. Що сталося?

Це може бути наслідком двох помилок у порядку дій. Якщо до firewall не додали правило для нового порту, спроби підключення до нового порту завершуються тайм-аутом, а порт 22 відхиляє підключення. Тому sudo ufw allow 2222/tcp потрібно виконати до зміни порту, а не після неї. Якщо на сервері для SSH використовується активація сокета через systemd, параметр Port 2222 у sshd_config ігнорується, а systemd продовжує утримувати старий порт. Це можна підтвердити за допомогою systemctl is-enabled ssh.socket. Відновіть доступ через консоль провайдера, виправте відповідну проблему, а потім підключіться за допомогою ssh -p 2222 user@203.0.113.10, коли sudo ss -tlnp покаже новий сокет.