Ваша перша сесія SSH, зі шляхом назад.

Зберіть дані доступу та шлях відновлення

Вам потрібні фактична адреса сервера, порт SSH, ім’я користувача для входу, початковий метод автентифікації та надійне джерело відбитка хост-ключа сервера. Вибране ім’я хоста в конфігураторі не встановлює DNS і не створює обліковий запис. Отримайте ці дані з фактичного налаштування служби, а не з припущень щодо образу Linux.

Підтвердьте, як отримати доступ до консолі або середовища відновлення та хто може відновити доступ. Перевірте, чи можете ви відкрити цей шлях відновлення зараз; не виявляйте під час блокування, що у вас немає дозволу чи облікових даних для відновлення. Якщо незалежний шлях відновлення недоступний, залишайте налаштування доступу без змін, доки його не буде організовано.

У прикладах використовується клієнтський термінал Bash на вашому комп’ютері та сервер Ubuntu/Debian. Замініть на ваші реальні дані для builder, порт 22 та 192.0.2.10, що є зарезервованою прикладною адресою. Команди — це інструкції для перегляду відповідно до вашого середовища; цей посібник не підключався до сервера OffVPS і не налаштовував його.

Створіть клієнтський ключ, не замінюючи наявний

Ваш приватний ключ залишається на клієнтському комп’ютері. Відповідний публічний ключ можна встановити в авторизовані ключі облікового запису сервера. Жоден із них не є хост-ключем сервера: цей окремий ключ допомагає ідентифікувати машину, до якої ви підключаєтеся. Тримайте приватний ключ і його парольну фразу поза повідомленнями підтримки, репозиторіями та завантаженнями на сервер.

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 документує типи ключів, вихідні файли та відбитки. Якщо керований пристрій вимагає іншої політики ключів, дотримуйтеся цієї політики та перевірте підтримку сервером. Зберігайте належним чином захищену резервну копію приватного ключа, якщо ваш план відновлення залежить від неї.

Перевірте сервер перед автентифікацією

Через довірену консоль або інший автентифікований канал налаштування отримайте відбиток хост-ключа Ed25519 сервера. На сервері, що використовує стандартний шлях OpenSSH, адміністратор може переглянути публічний файл за допомогою:

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

Порівняйте повний відбиток SHA256 і алгоритм із першим запитом на підключення SSH. Відбиток, отриманий лише через те саме неперевірене мережеве з’єднання, не є незалежною перевіркою. Якщо сервер пропонує інший алгоритм хост-ключа, отримайте відбиток цього ключа, а не порівнюйте різнорідні значення. Настанови OpenSSH щодо перевірки хост-ключа пояснюють це порівняння.

Якщо ключ несподівано зміниться під час наступного відвідування, зупиніться. Перебудова може законно замінити хост-ключі, але перевірте цю подію та новий відбиток через канал відновлення. Не приглушуйте попередження та не видаляйте старий запис відомого хоста лише для того, щоб з’єднання вдалося.

Встановіть лише публічний ключ і відкрийте першу сесію

Якщо ваш публічний ключ уже встановлено через авторизований процес налаштування, підключайтеся безпосередньо. Інакше скористайтеся наявним перевіреним методом доступу, щоб додати публічний ключ до потрібного облікового запису. На клієнті з 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. Підтвердьте, що обліковий запис відповідає даним налаштування; саме лише ім’я хоста не є перевіркою хост-ключа. Якщо ваші завдання потребують адміністрування, виконайте 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 перевіряє синтаксис конфігурації та коректність хост-ключа; -T також показує дієві налаштування. Правила, специфічні для з’єднання, Match можуть вимагати -C параметрів для облікового запису та адреси, що тестуються. Ці перевірки не тестують доступність брандмауера і не доводять, що новий вхід працює. Див. режими тестування sshd. Усуньте помилки перед застосуванням або перезавантаженням конфігурації служби, потім повторіть незалежну перевірку входу.

Використайте збій, щоб вибрати наступну перевірку

• Час очікування: підтвердьте адресу, порт, правила провайдера та хостовий брандмауер через шлях відновлення.
• З’єднання відхилено: перевірте, чи SSH слухає на очікуваній адресі та порту.
• Доступ заборонено: перевірте ім’я користувача, вибраний публічний ключ і дозволи файлів ключів облікового запису з усе ще відкритої сесії.
• Ідентифікацію хоста змінено: перевірте машину та новий відбиток незалежно, перш ніж продовжити.

Запишіть перевірений відбиток хост-ключа, обліковий запис, порт і процедуру відновлення у своїх робочих нотатках. Тримайте матеріал ключів у таємниці. Коли доступ стане повторюваним, перейдіть до вашого першого випуску API або бюджет ресурсів для застосунку.