Після замовлення VDS провайдер надсилає IP-адресу, логін (зазвичай root) і пароль або SSH-ключ. Усе подальше адміністрування сервера йде через SSH — графічної панелі на самому сервері немає, лише консоль і термінал.
Підключення до VDS через SSH
SSH (Secure Shell) шифрує канал між вашим комп'ютером і сервером і за замовчуванням слухає порт 22. Перше підключення — це перевірка того, що дані доступу правильні і сервер відповідає.
Підключення з Linux/macOS
ssh root@your-server-ip
# Якщо провайдер видав нестандартний порт SSH
ssh -p 2222 root@your-server-ip
# Підключення за ключем, якщо пароль вимкнено
ssh -i ~/.ssh/id_ed25519 root@your-server-ipПідключення з Windows
Починаючи з Windows 10 є вбудований SSH-клієнт прямо в PowerShell чи «Командному рядку» — окремо ставити нічого не потрібно:
ssh root@your-server-ipАльтернатива для тих, хто звик до графічного інтерфейсу, — PuTTY: у полі Host Name вводиться IP-адреса, порт за замовчуванням 22, тип з'єднання SSH, після чого вікно термінала відкриється окремо.
Перші кроки після входу
- Оновіть систему:
apt update && apt upgrade -y— свіжі патчі безпеки важливіші за будь-яке інше налаштування. - Створіть нового користувача замість постійної роботи під root:
adduser myuser && usermod -aG sudo myuser. - Згенеруйте SSH-ключ на своїй машині і скопіюйте публічну частину на сервер:
ssh-keygen -t ed25519, потімssh-copy-id myuser@your-server-ip. - Вимкніть вхід за паролем і напряму під root у
/etc/ssh/sshd_config, тільки переконавшись, що вхід за ключем уже працює. - Налаштуйте файрвол UFW:
ufw allow 22 && ufw enable— детальний розбір портів і правил у статті про налаштування UFW на VDS.
Розбір типових помилок підключення
Помилка Connection refused означає, що пакет дійшов до сервера, але порт 22 ніхто не слухає або файрвол одразу його відкидає активною відмовою. Причини: SSH-демон не запущено (systemctl status sshd), або підключаєтеся не на той порт, якщо його було змінено.
ssh: connect to host 203.0.113.10 port 22: Connection timed outНа відміну від refused, помилка timed out зазвичай означає, що пакети взагалі не доходять: сервер вимкнено, IP вказано неправильно, або файрвол на боці провайдера (Security Group) чи на самій VDS мовчки відкидає пакети, не відповідаючи відмовою.
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
...
Host key verification failed.Це попередження з'являється, коли ключ хоста у файлі ~/.ssh/known_hosts не збігається з тим, що надіслав сервер, — зазвичай після перевстановлення VDS з тією ж IP-адресою в іншого провайдера або після заміни самого сервера. Якщо ви точно знаєте, що сервер перестворено навмисно, старий запис видаляють командою ssh-keygen -R your-server-ip, а не ігнорують попередження наосліп.
Помилка Permission denied (publickey) означає, що вхід за паролем уже вимкнено на сервері, а придатного приватного ключа в клієнта немає або він не той. Перевірте, що вказуєте правильний файл ключа через -i і що на сервері в ~/.ssh/authorized_keys лежить саме парна публічна частина.
Порівняння способів входу на VDS
| Спосіб | Безпека | Зручність | Коли використовувати |
|---|---|---|---|
| Пароль root по SSH | Низька, вразливий до перебору | Високе, нічого не готувати заздалегідь | Лише для першого входу одразу після замовлення VDS |
| SSH-ключ для окремого користувача | Висока | Середнє, потрібне разове налаштування | Постійна робота із сервером |
| Консоль у панелі провайдера | Висока, минає мережу | Низьке, інтерфейс повільніший за термінал | Відновлення доступу при зламаному SSH чи файрволі |
| SSH через VPN/бастіон-хост | Максимальна, порт 22 не стирчить назовні | Низьке, додатковий вузол у ланцюжку | Корпоративні вимоги до доступу |
Коли звичайного пароля через SSH недостатньо
- Сервер тримає платіжні дані або доступ до продакшн-бази — тут одного пароля мало, потрібні ключі і, бажано, другий фактор для sudo-дій.
- До сервера підключається декілька людей — спільний пароль root не дає розмежувати, хто і що зробив; для цього заводяться окремі користувачі з власними ключами.
- Порт 22 видно з інтернету і його регулярно сканують боти — у логах це буде помітно за потоком невдалих спроб входу; тут допомагає зміна порту і fail2ban поверх SSH-ключів, а не замість них.
Перевірка результату
- Відкрийте нову SSH-сесію в окремому вікні, не закриваючи поточну, — якщо нова сесія підключається новим користувачем і за ключем, стару можна закривати безпечно.
- Перевірте, що вхід під root за паролем справді вимкнено: спроба
ssh root@your-server-ipіз зазначенням пароля має завершитися відмовою. - Перевірте статус SSH-демона і порт, що слухається:
systemctl status sshdіss -tulpn | grep ssh. - Переконайтеся, що резервний доступ через консоль провайдера все ще працює — на випадок, якщо конфігурацію SSH колись буде зіпсовано помилковою правкою.