Подключение к серверу по SSH: частые ошибки новичков

Новая SSH-сессия открывается, ключ работает, а парольный вход отключён только после проверки — так выглядит безопасное первое подключение. Ниже — инструкция для OpenSSH-клиента версии 9.x на Linux или macOS и Linux-сервера с OpenSSH. На подключение и проверку обычно достаточно 10–20 минут; если вы меняете серверные настройки или правила межсетевого экрана, время зависит от провайдера и доступа к консоли управления.

Что нужно до начала

Подготовьте адрес сервера, имя пользователя и один способ попасть на него: пароль либо консоль провайдера. У облачного сервера есть как минимум два места, где могут закрыть доступ: межсетевой экран в панели провайдера и firewall внутри Linux. Убедитесь, что разрешён входящий TCP-трафик на порт SSH — часто это 22, но администратор мог выбрать другой.

• Уточните у администратора или в панели адрес, имя пользователя и SSH-порт.
• Если сервер уже доступен через терминал или консоль провайдера, не закрывайте это окно до завершения проверки ключа.
• Не меняйте порт и правила firewall в ходе первого входа. Если потеряете соединение, заранее выясните, как открыть консоль восстановления у хостера.

В командах ниже замените YOUR_USER и YOUR_SERVER на свои данные. Если используется нестандартный порт, вместо примера без порта укажите его через параметр -p.

Подключитесь и проверьте ключ сервера

1. Откройте терминал и выполните команду, подставив имя пользователя и адрес:

   ssh YOUR_USER@YOUR_SERVER

   При нестандартном порте добавьте, например, -p 2222. При первом входе клиент спросит, доверяете ли вы ключу сервера. Сверьте его отпечаток с данными в панели хостинга или получите у администратора по независимому каналу; не подтверждайте ключ автоматически. Проверка: после успешной аутентификации появится приглашение командной строки сервера.

2. Если вы видите запрос подтверждения пароля, введите пароль учётной записи. Символы при вводе обычно не отображаются — это ожидаемо. Проверка: команда whoami показывает имя вошедшего пользователя, а hostname — имя сервера.

3. При сообщении об изменившемся ключе остановитесь: сервер мог переустановить администратор, но возможна и подмена соединения. Сверьте новый отпечаток через панель провайдера или с ответственным за сервер. Не удаляйте запись о старом ключе, пока не выяснили причину изменения. Проверка: подключение продолжайте только после независимого подтверждения нового отпечатка.

Не закрывайте единственную рабочую SSH-сессию, пока не проверили вход по ключу в отдельном окне. Восстанавливать доступ через консоль провайдера дольше, чем открыть второй терминал.

Создайте ключ и установите его на сервер

SSH-ключ состоит из открытой части, которую можно добавить на сервер, и закрытой, которая остаётся на вашем устройстве. Не отправляйте закрытый ключ другим людям и не копируйте его на сервер.

1. На своём компьютере создайте ключ Ed25519:

   ssh-keygen -t ed25519 -C "your_email@example.com"

   Оставьте предложенный путь по умолчанию либо запишите выбранный. При запросе задайте парольную фразу: она защищает закрытый ключ, если файл попадёт к постороннему. Проверка: команда сообщает, что создала файлы ключа; открытая часть обычно имеет суффикс .pub.

2. Откройте второе окно терминала, подключитесь прежним способом и добавьте открытую часть ключа в файл авторизации. На своём компьютере сначала выведите её:

   cat ~/.ssh/id_ed25519.pub

   Скопируйте всю одну строку, начинающуюся с ssh-ed25519. В серверной сессии выполните:

   mkdir -p ~/.ssh
   chmod 700 ~/.ssh
   cat >> ~/.ssh/authorized_keys

   Вставьте скопированную строку и завершите ввод сочетанием Ctrl-D. Затем задайте права:

   chmod 600 ~/.ssh/authorized_keys

   Проверка: команда tail -n 1 ~/.ssh/authorized_keys показывает добавленную открытую часть. Не публикуйте содержимое файла: его можно использовать для входа с соответствующим закрытым ключом.

3. Не закрывая старую сессию, откройте третье окно на своём компьютере и проверьте вход явно по новому ключу:

   ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 YOUR_USER@YOUR_SERVER

   Если порт нестандартный, добавьте -p 2222 с фактическим номером. Введите парольную фразу ключа, если клиент её запросит. Проверка: открывается новая сессия без запроса пароля учётной записи сервера. Выполните в ней whoami, чтобы убедиться, что вошли под нужным пользователем.

Частые ошибки: что проверить

• Permission denied (publickey). Сервер не принял предложенный ключ. Проверьте, что открытая часть добавлена именно в ~/.ssh/authorized_keys нужного пользователя, а права на каталог и файл выставлены в 700 и 600. Убедитесь, что подключаетесь с правильным именем пользователя и ключом.
• Connection timed out. Клиент не дождался ответа. Проверьте адрес, порт и правила firewall как в панели хостинга, так и на сервере. Если у вас нет консоли восстановления, не меняйте удалённо правила, которые могут закрыть текущий доступ.
• Connection refused. Сервер доступен, но соединение на этом порту не принимает служба SSH либо порт указан неверно. Сверьте настройки с администратором или панелью провайдера; не перебирайте случайные порты.
• WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!. Клиент обнаружил другой ключ сервера по сохранённому адресу. Сначала подтвердите переустановку или замену ключа у провайдера. Удалять старую запись и подключаться заново можно только после проверки причины.
• UNPROTECTED PRIVATE KEY FILE. Права на закрытый ключ слишком широкие. На Linux или macOS ограничьте их командой chmod 600 ~/.ssh/id_ed25519, затем повторите подключение.

Не отключайте запасной вход преждевременно

Когда вход по ключу сработал во втором окне, не обязательно сразу отключать парольную аутентификацию. Сначала проверьте, что у вас есть разрешённый способ восстановления: консоль провайдера или контакт администратора. Сервер может читать настройки из нескольких конфигурационных файлов, а правила конкретного хостинга и дистрибутива различаются. Поэтому не заменяйте настройки SSH вслепую и не перезапускайте службу, пока не проверили конфигурацию по документации вашей системы.

Если вы всё же меняете конфигурацию, оставьте активную сессию, проверьте синтаксис командой sudo sshd -t и только затем применяйте изменения способом, который рекомендует документация дистрибутива. Не отключайте парольный вход, пока новая сессия по ключу не открывается и резервный доступ не проверен.

Термин: отпечаток ключа — короткое контрольное представление публичного ключа сервера. По нему проверяют, что подключаются к ожидаемому серверу, а не к узлу с подменённым ключом.

Что делать дальше

Сохраните адрес, имя пользователя, порт и путь к ключу в менеджере паролей или защищённой заметке — не сам закрытый ключ в открытом виде. Затем проверьте в документации провайдера способ восстановления доступа и правила хранения резервных ключей. Если сервер рабочий, согласуйте отключение входа по паролю с администратором: безопасная настройка не должна превращаться в блокировку всей команды.