Ваша первая сессия SSH, с путём назад.

Соберите данные доступа и путь восстановления

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

Подтвердите, как получить доступ к консоли или среде восстановления и кто может восстановить доступ. Проверьте, что вы можете открыть этот путь восстановления сейчас; не обнаруживайте во время блокировки, что у вас нет разрешения или учётных данных для восстановления. Если независимый путь восстановления недоступен, не меняйте настройки доступа, пока он не будет организован.

В примерах используется клиентский терминал Bash на вашем компьютере и сервер Ubuntu/Debian. Замените реальными данными builder, порт 22 и 192.0.2.10, который является зарезервированным примером адреса. Команды — это инструкции, которые нужно проверить для вашей среды; это руководство не подключалось к серверу OffVPS и не настраивало его.

Создайте клиентский ключ, не заменяя существующий

Ваш закрытый ключ остаётся на клиентском компьютере. Соответствующий открытый ключ можно установить в authorized keys учётной записи сервера. Ни один из них не является host_key сервера: этот отдельный ключ помогает идентифицировать машину, к которой вы подключаетесь. Держите закрытый ключ и его парольную фразу вне сообщений в поддержку, репозиториев и загрузок на сервер.

ssh -V
ls -ld "$HOME/.ssh"
ls "$HOME/.ssh/offvps_first_vps" "$HOME/.ssh/offvps_first_vps.pub"

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

ssh-keygen -t ed25519 -f "$HOME/.ssh/offvps_first_vps" -C "first-vps"
ssh-keygen -lf "$HOME/.ssh/offvps_first_vps.pub" -E sha256

Вторая команда отображает отпечаток открытого ключа, а не материал закрытого ключа. руководство ssh-keygen документирует типы ключей, выходные файлы и отпечатки. Если управляемое устройство требует иной политики ключей, следуйте этой политике и проверьте поддержку сервером. Храните надлежащим образом защищённую резервную копию закрытого ключа, если ваш план восстановления зависит от неё.

Проверьте сервер перед аутентификацией

Через доверенную консоль или другой аутентифицированный канал настройки получите отпечаток host_key сервера Ed25519. На сервере, использующем стандартный путь OpenSSH, администратор может проверить открытый файл с помощью:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256

Сравните полный отпечаток SHA256 и алгоритм с первым приглашением подключения SSH. Отпечаток, полученный только через то же непроверенное сетевое соединение, не является независимой проверкой. Если сервер предлагает другой алгоритм host_key, получите отпечаток этого ключа, а не сравнивайте разнородные значения. Руководство по проверке host_key в OpenSSH объясняет это сравнение.

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

Установите только открытый ключ и откройте первую сессию

Если ваш открытый ключ уже был установлен в ходе авторизованного процесса настройки, подключайтесь напрямую. В противном случае используйте существующий проверенный способ доступа, чтобы добавить открытый ключ в нужную учётную запись. На клиенте с ssh-copy-id, и только когда этот начальный способ входа работает, эта команда добавляет выбранный открытый ключ:

ssh-copy-id -i "$HOME/.ssh/offvps_first_vps.pub" -p 22 [email protected]

Ubuntu руководство OpenSSH описывает установку открытого ключа и требования к правам доступа. Не заменяйте целиком authorized_keys файл и не изменяйте записи другого администратора. Затем откройте сессию на основе ключа:

ssh -o IdentitiesOnly=yes -i "$HOME/.ssh/offvps_first_vps" \
  -p 22 [email protected]

После входа проверьте id и hostname. Убедитесь, что учётная запись соответствует данным настройки; одно имя хоста не является проверкой host_key. Если ваши задачи требуют администрирования, выполните sudo -v и убедитесь, что эта учётная запись имеет предполагаемый путь привилегий. Оставьте эту первую сессию открытой.

Подтвердите действительно отдельный второй вход

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

ssh -o ControlMaster=no -o ControlPath=none \
  -o IdentitiesOnly=yes -o PreferredAuthentications=publickey \
  -i "$HOME/.ssh/offvps_first_vps" -p 22 [email protected]

Проверить id, hostname и, при необходимости, sudo -v в этой второй сессии тоже. Одного нового терминала недостаточно, если клиент повторно использует существующее подключение. ControlPath=none отключает это совместное использование; см. конфигурация клиента OpenSSH. Закрывайте исходную сессию только после успешного независимого подключения и при доступном пути восстановления.

Перед любым последующим изменением доступа

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

sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T

В системах с этим путём к исполняемому файлу OpenSSH -t проверяет синтаксис конфигурации и корректность host_key; -T также сообщает действующие настройки. Правила Match для конкретного подключения могут требовать -C параметры для проверяемой учётной записи и адреса. Эти проверки не тестируют доступность брандмауэра и не доказывают, что новый вход работает. См. режимы тестирования sshd. Устраните ошибки перед применением или перезагрузкой конфигурации службы, затем повторите независимую проверку входа.

Используйте ошибку, чтобы выбрать следующую проверку

• Тайм-аут: проверьте адрес, порт, правила провайдера и хост-брандмауэр через путь восстановления.
• Соединение отклонено: проверьте, слушает ли SSH ожидаемый адрес и порт.
• Доступ запрещён: проверьте имя пользователя, выбранный открытый ключ и права доступа к файлу ключей учётной записи из всё ещё открытой сессии.
• Идентификация хоста изменилась: проверьте машину и новый отпечаток независимо, прежде чем продолжать.

Запишите проверенный отпечаток host_key, учётную запись, порт и процедуру восстановления в свои рабочие заметки. Держите ключевой материал в секрете. Как только доступ становится воспроизводимым, переходите к первому выпуску API или бюджет ресурсов для приложения.