Skip to content Провайдер прислал письмо, а в нём – IP-адрес, логин (скорее всего root) и либо пароль, либо строчка о том, что при заказе ты уже прикрутил SSH-ключ. Дальше письмо заканчивается, и ты остаёшься наедине с вопросом: а внутрь-то как попасть?
SSH – это и есть вход. Стандартный протокол удалённого доступа к Linux-серверу: весь обмен зашифрован, идёт через один порт, и на той стороне тебя ждёт не рабочий стол с картинкой, а текстовый терминал. Ты пишешь команду, сервер отвечает строкой. Скупо, зато именно так серверы и живут – от копеечного VPS под одним Telegram-ботом до стоек в дата-центре.
Нужно ровно две вещи: данные для подключения из письма и SSH-клиент, то есть программу, которая умеет говорить на этом протоколе. На Mac и Linux он встроен. На Windows тоже есть, если система свежая, а если нет – ставится за пару минут. На телефоне это отдельное приложение. Разберём по очереди, а заодно пройдёмся по тому, что реально ломается на первом подключении, потому что «набери ssh и всё заработает» – это про идеальный мир. Если это вообще первый твой сервер и хочется пройти всё с нуля, есть отдельный разбор настройки VPS для новичков.
Mac и Linux: терминал уже на месте
На маке открой «Терминал» (Spotlight, набрать «Терминал») или iTerm2, если он у тебя стоит. Команда одна:
ssh root@203.0.113.10После @ – твой IP из письма. Жмёшь Enter. В первый раз SSH задаст вопрос про «authenticity» (о нём чуть ниже), потом попросит пароль. И вот тут начинается классика.
Ты вводишь пароль, а на экране – ничего. Ни точек, ни звёздочек, курсор стоит на месте, будто терминал завис. Не завис. SSH намеренно не показывает даже длину пароля, так уж заведено в Unix. Печатай вслепую и жми Enter. Первый раз это сбивает с толку всех подряд, и половина новичков давит Enter раз десять, думая, что ввод не проходит, а сервер потом ругается на кучу пустых попыток. Если ты вставляешь пароль из письма – вставка работает, её просто тоже не видно.
Как только пустишь, приглашение в строке сменится на что-то вроде root@hostname:~#. Ты внутри. Дальше уже другой разговор – про команды Linux для управления сервером. Чтобы выйти обратно, набери exit или нажми Ctrl+D. На Linux всё то же самое слово в слово, и если на Windows у тебя стоит WSL – тоже.
Windows: встроенный клиент или PuTTY
Тут две дороги, и обе рабочие.
Первая – встроенный клиент. Начиная с Windows 10 (сборка 1809) и в Windows 11 в системе есть OpenSSH. Открываешь PowerShell или Windows Terminal и пишешь ту же команду:
ssh root@203.0.113.10На Windows 11 клиент чаще всего уже стоит, на Windows 10 иногда нужно доставить: Параметры → Приложения → Дополнительные компоненты → добавить «Клиент OpenSSH». Если система пишет, что ssh не распознан как команда, причина именно в этом. Пароль здесь так же невидим, как на маке, не пугайся.
Вторая дорога – PuTTY, для тех, кому спокойнее с окном, где есть поля, а не с голой командной строкой. Качаешь с официального сайта (ссылка в конце), установка не обязательна, putty.exe запускается сам по себе. В поле Host Name – IP, Port оставляешь 22, тип соединения SSH, жмёшь Open. При первом подключении выскочит предупреждение безопасности про ключ хоста – это тот же вопрос про «authenticity», просто в виде окошка, жмёшь Accept. Дальше login as: – пишешь root, потом пароль (тоже вслепую, но правый клик мышью вставляет из буфера).
Чтобы не вбивать всё заново, заполни поля, впиши имя в Saved Sessions и нажми Save – сессия сохранится. И один момент, на котором спотыкаются постоянно: PuTTY работает со своим форматом ключей .ppk, а не с обычным форматом OpenSSH. Если провайдер выдал тебе приватный ключ в формате OpenSSH, PuTTY его напрямую не съест – надо прогнать через PuTTYgen (Conversions → Import key → Save private key). Но это уже про вход по ключам, отдельная большая тема.
С телефона: для экстренных случаев, а не для работы
Сразу честно: печатать конфиги на стекле – мучение, и как основной инструмент телефон не годится. А вот как аварийный – выручает не раз. Ты не за столом, сайт лёг, надо перезапустить упавший сервис или перезагрузить машину – тут связь с сервера в кармане бесценна.
Приложений по сути два. Termius (iOS и Android) – вылизанный, хранит хосты и ключи, синхронизирует между устройствами. Удобно, но синхронизация означает, что ключи лежат в их облаке: для хобби-VPS нормально, для чего-то серьёзного стоит подумать дважды. Termux (только Android) – это полноценный Linux-терминал в телефоне: ставишь pkg install openssh и дальше ssh root@ip ровно как на десктопе. Больше контроля, больше возни.
Главная боль здесь – клавиатура. У экранной нет ни Ctrl, ни Tab, ни стрелок, а автозамена радостно «исправляет» команды в мусор. Termius дорисовывает отдельный ряд с недостающими клавишами, в Termux клавиша громкости вниз работает как Ctrl. Первым делом отключи автокоррекцию для приложения, иначе весь вечер будешь воевать с клавиатурой вместо сервера.
Что за вопрос про «authenticity» и почему на него нельзя жать вслепую
При первом подключении к новому серверу SSH выдаёт такое:
The authenticity of host '203.0.113.10' can't be established.
ED25519 key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxx
Are you sure you want to continue connecting (yes/no/[fingerprint])?Смысл простой: сервер SSH видит впервые, показывает его отпечаток (fingerprint) и просит тебя за него поручиться. Печатаешь yes целиком, не y. Отпечаток запишется в файл ~/.ssh/known_hosts, и больше вопрос не всплывёт.
Нюанс, который обычно проскакивают мимо. Этот вопрос – единственный момент, когда SSH проверяет, что ты разговариваешь с правильной машиной, а не с подставной, вклинившейся посередине. На новеньком VPS честный ответ звучит как «мне не с чем сверить этот отпечаток», и 99% людей просто жмут yes – для свежего сервера в доверенной сети это вполне разумно. Но механизм придуман не зря, и позже он умеет громко напомнить о себе (об этом дальше). Некоторые провайдеры показывают ожидаемый отпечаток в панели или в первом письме – сверить стоит, если на сервере что-то ценное или просто хочется спокойствия.
Когда не пускает: сначала читаем текст ошибки
Самое полезное умение на этом этапе – не гадать, а прочитать, что именно написал SSH. Формулировка почти всегда показывает, где сломалось, и лечение в каждом случае разное.
Connection timed out – пакеты вообще не доходят до сервера. Варианты: не тот IP, машина ещё не поднялась после заказа (дай ей пару минут), выключена, либо порт закрыт файрволом и соединение молча роняется. Сюда же попадает случай, когда ты сменил порт SSH, а стучишься по привычке на 22 – про то, как порты открываются и закрываются, есть разбор файрволов UFW и iptables.
Connection refused – до сервера ты достучался, но на этом порту никто не отвечает. Значит, либо демон SSH не запущен, либо слушает другой порт. На свежем VPS такое редкость, чаще вылезает после того, как сам поковырялся в настройках sshd.
kex_exchange_identification: Connection closed by remote host — соединение установилось и тут же оборвалось, ещё до всякого логина. Выглядит как поломка на стороне сервера, а причины почти всегда три. Первая и самая частая — тот же Fail2ban или аналогичный блокировщик: некоторые конфигурации не роняют пакеты молча, а рвут уже установленное соединение, и тогда вместо таймаута ты получаешь вот эту строку. Вторая — ограничение по адресам: сервер настроен пускать только с определённых IP, а ты пришёл с другого (домашний провайдер сменил адрес, ты подключился через мобильный интернет или VPN). Третья, самая обидная, — на сервере кончилась память или упёрлись лимиты, и sshd просто не может породить процесс под новую сессию. Последний вариант проверяется через консоль провайдера: если машина еле шевелится, дело не в SSH.
Отдельный случай — когда подключение просто висит. Ни ошибки, ни приглашения, курсор мигает, и через минуту-другую всё отваливается. Запусти с подробным выводом: ssh -vvv root@203.0.113.10. Если поток замирает на строке expecting SSH2_MSG_KEX_ECDH_REPLY, к SSH это отношения почти не имеет — обмен ключами требует передачи довольно крупных пакетов, и где-то по пути они не проходят из-за MTU. Виноват обычно домашний роутер с PPPoE, VPN-туннель или мобильный оператор. Лечится на своей стороне: снизить MTU на интерфейсе (на роутере это часто значение 1492 или 1400) либо подключиться из другой сети, чтобы проверить догадку. Гуглить тут нечего — ошибки-то нет, и человек честно думает, что сервер мёртв, хотя мёртв канал.
Permission denied (publickey,password) – соединение установилось, а аутентификация не прошла. Неверный пароль, не тот пользователь, забытый Caps Lock. В скобках, кстати, перечислено, какие способы входа сервер вообще принимает.
А вот Permission denied (publickey) – только publickey, без password – читается иначе. Сервер настроен пускать исключительно по ключам, парольный вход выключен наглухо. Никакой пароль тут не поможет в принципе, нужен ключ. Многие провайдеры так и отдают образы: root по паролю запрещён, вход только по тому ключу, что ты приложил при заказе. Если видишь такую ошибку, а ключа у тебя нет, – ты не пароль забыл, ты не туда ломишься.
В PuTTY та же самая ситуация выглядит иначе: No supported authentication methods available (server sent: publickey). Смысл ровно тот же — сервер принимает только ключи, а PuTTY предложить ему нечего. Формулировка сбивает с толку, потому что звучит как несовместимость версий или отсутствие какого-то модуля, хотя речь всё о том же: нужен ключ, и он должен быть подсунут PuTTY в его собственном формате .ppk. Как его получить и куда положить — в статье про SSH-ключи вместо пароля.
Про порт отдельно: по умолчанию SSH сидит на 22, но многие настройки и провайдеры двигают его, чтобы поменьше шумели логи от автоматических переборщиков. Смотри в письме и в панели. Подключиться на нестандартный порт: ssh -p 2222 root@203.0.113.10 (в PuTTY – поле Port).
Есть и обидная ловушка. Несколько раз подряд ошибся паролем, а потом подключения вдруг стали отваливаться по таймауту, хотя минуту назад доходили. Выглядит как проблема с сетью, а на деле тебя забанил Fail2ban: он видит серию неудачных входов и блокирует IP на время. Пару лет назад такие обращения шли валом – «сервер вдруг перестал пускать», а человек сам себя и закрыл. Лечится ожиданием (бан обычно временный) или заходом через консоль провайдера, чтобы снять блокировку вручную.
И ещё одна частая мелочь – пользователь. Часть облачных образов отключает root и выдаёт вместо него sudo-пользователя с именем вроде ubuntu, debian или admin. Если под root упорно не пускает, попробуй имя по умолчанию для твоего образа, оно есть в документации провайдера.
Полезная привычка на будущее: почти у каждого провайдера в панели есть веб-консоль (VNC или последовательный порт), которая работает даже когда SSH мёртв. Найди её заранее — в момент, когда сам себе перекроешь доступ неудачным конфигом, искать будет уже не до того. Для тяжёлых случаев, когда система не грузится, есть режим восстановления.
REMOTE HOST IDENTIFICATION HAS CHANGED: большая красная простыня
Рано или поздно ты увидишь вот это, и первое впечатление – что тебя взломали:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
...
Host key verification failed.Чаще всего это происходит после переустановки ОС или пересоздания VPS. Новая система – новый ключ хоста, а у тебя в known_hosts под этим IP лежит старый. SSH видит несовпадение и, поскольку это ровно тот сценарий, от которого он защищает (подмена сервера посередине), поднимает панику и отказывается подключаться вообще.
Если ты действительно переставлял систему – всё ожидаемо, чинится одной строкой:
ssh-keygen -R 203.0.113.10Она вычищает старую запись именно для этого адреса. При следующем входе снова спросит про отпечаток, скажешь yes. PuTTY хранит ключи в реестре и при подключении сам предложит обновить.
Самое неприятное здесь другое. Если ты не переустанавливал сервер и ничего с ним не делал, а простыня всё равно вылезла, – вот тут стоит притормозить, потому что теоретически это и есть тот случай, ради которого весь механизм придуман. На практике у VPS бывает и прозаичнее: провайдер сменил ноду, тебе перевыдали IP от чужого старого сервера, и на этом адресе теперь другая машина. Но раз уж SSH кричит, сначала пойми, почему ключ сменился, и только потом чисти known_hosts, а не наоборот.
Чтобы не набирать всё заново: файл ~/.ssh/config
Когда заходишь на сервер каждый день, набирать ssh -p 2222 root@203.0.113.10, да ещё с путём до ключа, быстро надоедает. Заведи файл ~/.ssh/config (на Windows это C:\Users\Имя\.ssh\config) и опиши сервер один раз:
Host myvps
HostName 203.0.113.10
User root
Port 2222
IdentityFile ~/.ssh/id_ed25519Теперь достаточно ssh myvps. Работает и в scp, и в sftp, и во всём, что ходит поверх SSH. Мелочь, а экономит время и убирает опечатки в IP, из-за которых потом ловишь «connection timed out» на ровном месте.
Сессия отвалилась посреди команды
Две беды, и обе решаемы. Первая – обрыв по простою: домашний роутер или NAT рвёт молчащее соединение через несколько минут, и ты ловишь broken pipe. Лечится строчкой в том же config:
ServerAliveInterval 60Клиент раз в минуту шлёт серверу пустой пакет, и соединение не считается простаивающим.
Вторая серьёзнее. Связь рвётся посреди долгой операции – апгрейд системы, перенос базы, распаковка большого архива – и команда умирает вместе с сессией, а в каком она осталась состоянии, непонятно. Поэтому всё, что дольше пары минут, стоит запускать внутри tmux или screen: даже если тебя выкинет, процесс продолжит работать на сервере, а ты переподключишься и вернёшься ровно туда, где был. Потеряв так один раз наполовину перенесённую базу, начинаешь запускать tmux рефлекторно.
Дальше: ключи и защита
Зашёл по паролю — это старт, но почти все следом делают два шага. Первый: переходят на вход по ключу — так и удобнее (не набирать пароль каждый раз), и на порядок устойчивее к перебору (SSH-ключи вместо пароля). Второй: закрывают SSH — меняют порт, запрещают вход под root, ограничивают доступ по IP (как защитить SSH).
Кстати про root: большинство провайдеров до сих пор по умолчанию отдают именно его. Удобно и слегка безрассудно, потому что под root любая опечатка в команде бьёт по всей системе сразу, без предохранителя. Часть managed-тарифов root специально не даёт, и это не жадность, а страховка. Но это уже тема отдельного разговора про пользователей и права доступа…
