После заказа 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 когда-нибудь будет испорчена ошибочной правкой.