SSH-ключі замість паролів на Linux-сервері: інструкція

Покроково переходимо з паролів на SSH-ключі на Linux-сервері: створюємо ключ, додаємо на сервер, вимикаємо парольний вхід і перевіряємо результат так, щоб не втратити доступ.

Вікно термінала з рядками команд SSH на темному тлі: підключення до Linux-сервера за ключем
Ілюстрація

Для чого і кому

SSH-ключі замість паролів на Linux-сервері закривають слабке місце: пароль легко передати, повторно використати або забути змінити. За документацією OpenSSH, протокол SSH2 підтримує і традиційний парольний вхід, і автентифікацію за відкритим ключем. Покажемо, як перейти на другий варіант, вимкнути перший і не втратити доступ.

Кого це стосується

Інструкція для серверів з Linux, де віддалений доступ організовано через OpenSSH: вебсервери, сервери застосунків, файлові сховища, тестові середовища. Вона підійде і для фізичного сервера в офісі, і для віртуальної машини в хмарі чи дата-центрі.

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

Що це змінює для бізнесу

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

Пріоритет

Сьогодні: з'ясувати, на яких серверах SSH доступний з інтернету і хто має там паролі. Цього тижня: перевести на ключі адміністраторів і підрядників з доступом до продуктивних серверів. При плановому оновленні: решту серверів, тестові середовища та службові облікові записи. Термінової аварійної ситуації тут немає, тому спокійно проходьте кроки по одному.

Що знадобиться

Потрібен обліковий запис на сервері, з яким ви вже заходите за паролем, і права адміністратора для зміни конфігурації. На вашому комп'ютері має бути клієнт OpenSSH (команда ssh з переліку man-сторінок OpenSSH).

Заздалегідь підготуйте запасний вхід: консоль у панелі віртуальної машини, доступ через гіпервізор або фізичний доступ до сервера. Це страховка на випадок помилки в налаштуванні.

Тримайте відкритими man-сторінки ssh-keygen(1), ssh-agent(1), ssh-add(1) і sshd_config(5) на тій самій сторінці документації. Конкретні команди й назви параметрів завжди звіряйте з документацією версії OpenSSH, яка встановлена у вас.

Кроки

  1. Створіть пару ключів на своєму комп'ютері інструментом ssh-keygen. Тип ключа й параметри захисту оберіть за man-сторінкою ssh-keygen(1) та політикою вашої компанії. Перевірка: у вас є дві частини ключа, закрита й відкрита, і ви розрізняєте їх. Закрита лишається лише на вашому комп'ютері й нікому не передається.
  2. Додайте відкритий ключ на сервер у спосіб, який описано в документації вашої версії OpenSSH і дистрибутива. Передається лише відкрита частина. Перевірка: у списку дозволених ключів вашого облікового запису на сервері є запис саме відкритого ключа, по одному на кожну людину.
  3. Перевірте вхід за ключем, не закриваючи наявний сеанс. Відкрийте нове вікно термінала й підключіться командою ssh. Перевірка: вхід відбувся без пароля облікового запису. Якщо клієнт досі просить пароль, ключ не підхоплено: поверніться до кроку 2 і не переходьте далі.
  4. За потреби налаштуйте ssh-agent: це агент автентифікації, який може зберігати закриті ключі, а ssh-add додає ключі до нього. Перевірка: повторний вхід у тому ж сеансі роботи проходить без повторного введення захисту ключа. На спільних комп'ютерах після роботи не залишайте агент із завантаженими ключами.
  5. Вимкніть парольний вхід у конфігурації демона sshd. Спершу збережіть копію файлу конфігурації, потім у man-сторінці sshd_config(5) знайдіть параметр, що відповідає за парольну автентифікацію, і змініть його. Застосуйте зміну так, як це передбачено у вашому дистрибутиві. Перевірка: у новому вікні вхід за ключем працює, а спроба увійти лише з паролем сервер відхиляє. Перше вікно тим часом лишається відкритим.
  6. Запишіть, чий це ключ, і визначте порядок відкликання. Заведіть простий список: ім'я працівника, дата додавання, сервери. Перевірка: кожен запис у списку ключів на сервері відповідає людині зі списку, а в процедурі звільнення чи завершення співпраці є пункт «видалити ключі».

Як перевірити результат

Підсумкова перевірка складається з трьох дій. Увійдіть на сервер новим сеансом за ключем. Спробуйте зайти лише з паролем і переконайтеся, що сервер відмовляє. Порівняйте фактичну поведінку з тим, що описано для вашого параметра в sshd_config(5): перевіряти треба реальним входом, а не тільки текстом файлу.

Окремо перегляньте журнал автентифікації сервера: успішні входи мають йти за ключем, а спроби за паролем не повинні закінчуватися входом. Якщо в компанії є автоматизація (скрипти, резервне копіювання, система розгортання), запустіть її вручну й переконайтеся, що вона не залежала від пароля. Деталі налаштувань шукайте в документації OpenSSH для вашої версії.

Типові помилки

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

Друга помилка: ключ додано, а сервер його не використовує, і людина вважає, що «ключі не працюють». Тому після кожної зміни перевіряйте вхід окремим сеансом і шукайте причину в журналі автентифікації та документації. Третя: один спільний ключ на всю команду. Тоді втрачається головна перевага: не видно, хто саме заходив, і неможливо відкликати доступ однієї людини.

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

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

Висновок

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

Джерела

  1. OpenSSH manual pages · 2 листопада 2026 р.

Почнімо з розмови

Зв’язатися з TakeIT

Працюємо з компаніями в Києві та по всій Україні. Більшість робіт — дистанційно, виїзд в офіс у Києві передбачений у пакетах.

Запитайте AI про TakeIT