Як завантажити публічний SSH ключ на існуючий VPS

SSH публічний ключ — це криптографічний обліковий запис, що зберігається в ~/.ssh/authorized_keys на віддаленому сервері та надає доступ будь-якому клієнту, який має відповідний приватний ключ, — без передачі пароля через мережу. Завантаження публічного ключа на існуючий VPS замінює або доповнює автентифікацію на основі пароля асиметричною криптографією, усуваючи вектор атаки, який використовується під час брутфорс-атак і атак із підстановкою облікових даних.

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

Чому SSH-автентифікація за ключем перевершує паролі

Перш ніж виконувати будь-яку команду, варто зрозуміти криптографічну механіку. Коли ви автентифікуєтесь за допомогою пари ключів, сервер надсилає виклик, зашифрований вашим публічним ключем. Лише власник відповідного приватного ключа може розшифрувати та підписати відповідь. Жоден секрет ніколи не передається — на відміну від автентифікації за паролем, де сам обліковий запис передається через мережу (навіть якщо він загорнутий у TLS).

Практичний висновок: у будь-якому середовищі VPS Хостингу, відкритому для публічного інтернету, SSH-ключі — це не додаткове посилення безпеки, а базовий стандарт.

Передумови

• Існуючий VPS, доступний через SSH (автентифікація за паролем або існуючим ключем наразі працює)
• Локальна машина під управлінням Linux, macOS або Windows з OpenSSH або PuTTY
• Достатні привілеї на VPS для запису в домашній каталог цільового користувача
• Базові навички роботи з терміналом і текстовим редактором, наприклад nano або vim

Крок 1: Генерація пари SSH-ключів

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

Вибір правильного алгоритму

Ed25519 є сучасним стандартом. Використовуйте RSA 4096 лише при підключенні до застарілих серверів, які не підтримують Ed25519.

Генерація пари ключів Ed25519:

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

Генерація пари ключів RSA 4096 (для застарілих систем):

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Під час генерації ключів вам буде запропоновано вказати шлях збереження та необов’язкову парольну фразу. Прийняти шлях за замовчуванням (~/.ssh/id_ed25519) цілком прийнятно для більшості користувачів. Завжди встановлюйте парольну фразу — вона шифрує приватний ключ на диску за допомогою AES-256, тому викрадений ноутбук не означає автоматично скомпрометований сервер.

У результаті процесу створюються два файли:

~/.ssh/id_ed25519 — ваш приватний ключ. Ніколи не передавайте його, не копіюйте на сервер, не додавайте до системи контролю версій.
~/.ssh/id_ed25519.pub — ваш публічний ключ. Його можна вільно поширювати.

Відобразіть публічний ключ, щоб скопіювати його:
cat ~/.ssh/id_ed25519.pub
Результат виглядатиме приблизно так:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... your_email@example.com
Скопіюйте весь рядок цілком, включаючи префікс алгоритму та коментар у кінці.
Крок 2: Вхід на VPS
Підключіться до VPS за допомогою поточного методу автентифікації:
ssh root@your_vps_ip
Замініть your_vps_ip на фактичну IPv4 або IPv6 адресу вашого сервера. Якщо ви керуєте обліковим записом не-root користувача, замініть root на відповідне ім’я користувача. На Виділених серверах, де може бути кілька облікових записів користувачів, завжди надавайте перевагу розгортанню ключів для не-root користувача та використовуйте sudo для підвищення привілеїв.
Крок 3: Підготовка каталогу .ssh
Після входу перевірте або створіть каталог .ssh для цільового користувача:
mkdir -p ~/.ssh
chmod 700 ~/.ssh
Дозвіл 700 (rwx------) є обов’язковим. OpenSSH мовчки відмовиться використовувати authorized_keys, якщо каталог .ssh доступний для запису групою або всіма користувачами. Це одна з найпоширеніших причин, чому автентифікація за ключем не працює після правильно виконаного налаштування.
Крок 4: Додавання публічного ключа до authorized_keys
Метод A: Ручне вставлення (універсальний)
Відкрийте або створіть файл authorized_keys:
nano ~/.ssh/authorized_keys
Вставте ваш публічний ключ на новий рядок. Кожен рядок у цьому файлі представляє один авторизований ключ. Збережіть за допомогою Ctrl+X, потім Y, потім Enter.
Встановіть правильні дозволи:
chmod 600 ~/.ssh/authorized_keys
Дозвіл 600 (rw-------) гарантує, що лише власник файлу може читати або записувати його. OpenSSH суворо дотримується цієї вимоги.
Метод B: ssh-copy-id (рекомендований для швидкості)
Якщо на вашій локальній машині доступна утиліта ssh-copy-id (стандартна для Linux і macOS), ця єдина команда автоматично виконує створення каталогу, додавання ключа та встановлення дозволів:
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@your_vps_ip
Вам буде запропоновано ввести поточний SSH-пароль один раз. Після цього вхід за ключем стане активним. Прапорець -i явно вказує, який публічний ключ завантажити, запобігаючи випадковому завантаженню неправильного ключа.
Метод C: Однорядкова команда через cat та pipe (для скриптів)
Корисний в автоматизованих конвеєрах або коли ssh-copy-id недоступний:
cat ~/.ssh/id_ed25519.pub | ssh root@your_vps_ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"
Цей підхід є безпечним з точки зору ідемпотентності в тому сенсі, що він додає ключ, а не перезаписує файл, зберігаючи всі наявні авторизовані ключі.
Крок 5: Перевірка правильності власника файлу
Часто overlooked підводний камінь: якщо ви створили каталог .ssh або файл authorized_keys від імені root під час налаштування облікового запису іншого користувача, власник буде неправильним і SSH мовчки відхилить ключ.
Перевірте власника:
ls -la ~/.ssh/
У виводі має відображатися ім’я цільового користувача як власника та групи для каталогу та файлу:
drwx------ 2 alice alice 4096 Jan 15 10:00 .ssh
-rw------- 1 alice alice  571 Jan 15 10:00 .ssh/authorized_keys
Якщо власник неправильний, виправте це (виконайте від імені root):
chown -R alice:alice /home/alice/.ssh
Крок 6: Тестування входу за SSH-ключем
Завершіть поточний сеанс:
exit
Підключіться знову з явним зазначенням ключа для підтвердження налаштування:
ssh -i ~/.ssh/id_ed25519 root@your_vps_ip
Якщо вхід виконується без запиту пароля (або запитується лише парольна фраза локального ключа), конфігурація правильна. Якщо все ще запитується пароль сервера, перейдіть до розділу усунення несправностей нижче.
Крок 7: Посилення конфігурації SSH-демона
Після підтвердження роботи входу за ключем вимкніть автентифікацію за паролем, щоб повністю усунути вектор атаки брутфорсом паролів.
Відкрийте файл конфігурації SSH-демона:
nano /etc/ssh/sshd_config
Знайдіть і встановіть наступні директиви. Якщо рядок закоментований символом #, видаліть # та встановіть значення:
PasswordAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PermitRootLogin prohibit-password
ChallengeResponseAuthentication no
UsePAM yes
Примітка щодо PermitRootLogin prohibit-password: це налаштування дозволяє вхід root виключно за ключем, блокуючи доступ root за паролем, але дозволяючи сеанси root з автентифікацією за ключем. Для максимального посилення безпеки встановіть значення no та використовуйте не-root користувача з sudo.
На деяких дистрибутивах додатковий конфігураційний файл може перевизначати ваші налаштування. Перевірте наявність перевизначень:
grep -r "PasswordAuthentication" /etc/ssh/sshd_config.d/
Якщо будь-який файл у цьому каталозі встановлює PasswordAuthentication yes, відредагуйте або видаліть його.
Перевірте синтаксис конфігурації перед перезапуском:
sshd -t
Чистий вивід (без помилок) означає, що можна безпечно перезавантажити. Застосуйте зміни:
systemctl restart sshd
Критичне попередження: Не закривайте поточний SSH-сеанс, поки не відкриєте другий термінал і не переконаєтесь, що можете увійти за ключем. Перезапуск sshd з неправильно налаштованим файлом або до того, як ваш ключ запрацює, заблокує вам доступ. Більшість Панелей керування VPS надають аварійну консоль (доступ KVM/VNC) для відновлення, але набагато краще уникнути цієї ситуації заздалегідь.
Крок 8: Керування кількома ключами та серверами за допомогою ~/.ssh/config
При керуванні кількома серверами — що є звичайним у середовищах staging/production або при адмініструванні кількох Виділених серверів — файл конфігурації SSH-клієнта усуває необхідність запам’ятовувати IP-адреси, імена користувачів та шляхи до ключів.
Створіть або відредагуйте ~/.ssh/config на вашій локальній машині:
nano ~/.ssh/config
Приклад конфігурації для кількох хостів:
Host production-vps
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    Port 22

Host staging-vps
    HostName 203.0.113.20
    User deploy
    IdentityFile ~/.ssh/id_ed25519_staging
    Port 2222

Host legacy-server
    HostName 203.0.113.30
    User admin
    IdentityFile ~/.ssh/id_rsa_legacy
    PubkeyAcceptedKeyTypes +ssh-rsa
Встановіть правильні дозволи для файлу конфігурації:
chmod 600 ~/.ssh/config
Тепер ви можете підключатися за зручними псевдонімами:
ssh production-vps
ssh staging-vps
Директива PubkeyAcceptedKeyTypes +ssh-rsa у записі для застарілого сервера є важливою: новіші клієнти OpenSSH (8.8+) вимикають RSA-SHA1 за замовчуванням. Без цього перевизначення підключення до старіших серверів завершуватиметься помилкою «no matching host key type».
Усунення несправностей: чому автентифікація за SSH-ключем не працює
Навіть при правильному налаштуванні кілька факторів середовища можуть призвести до того, що автентифікація за ключем мовчки повертається до запиту пароля:
Неправильні дозволи для .ssh або authorized_keys:
Виконайте ls -la ~/.ssh/ на сервері. Каталог повинен мати дозвіл 700, а файл — 600. Будь-які більш ліберальні дозволи змушують OpenSSH ігнорувати файл.
Невідповідність контексту безпеки SELinux або AppArmor:
На системах RHEL/CentOS/AlmaLinux із увімкненим SELinux файл authorized_keys може мати неправильний контекст безпеки. Відновіть його за допомогою:
restorecon -Rv ~/.ssh
Неправильний домашній каталог користувача:
Якщо домашній каталог користувача доступний для запису не лише власнику, SSH відмовить у автентифікації за ключем. Перевірте за допомогою:
ls -ld ~
Сам домашній каталог не повинен бути доступним для запису групою або всіма користувачами.
Директива AuthorizedKeysFile вказує на інший шлях:
Деякі дистрибутиви налаштовують AuthorizedKeysFile на нестандартний шлях (наприклад, /etc/ssh/authorized_keys/%u). Перевірте активне налаштування:
sshd -T | grep authorizedkeysfile
Конфлікти кількох ключів та ssh-agent:
Якщо ssh-agent запущений із кількома завантаженими ключами, сервер може відхилити з’єднання після надто великої кількості невдалих спроб з ключами до того, як буде спробований правильний. Використовуйте -i для явного зазначення ключа або налаштуйте IdentitiesOnly yes у ~/.ssh/config.
Брандмауер або fail2ban блокує вашу IP-адресу:
Якщо ви раніше здійснювали кілька невдалих спроб входу, правила fail2ban або ufw/iptables могли тимчасово заблокувати вашу IP-адресу. Перевірте за допомогою:
fail2ban-client status sshd
Ротація та відкликання SSH-ключів
Ротація ключів — це практика безпекової гігієни, яку часто нехтують. Щоб відкликати конкретний ключ, відкрийте ~/.ssh/authorized_keys на сервері та видаліть відповідний рядок. Кожен рядок — це один ключ; його видалення негайно відкликає доступ для власника цього приватного ключа, не впливаючи на інші авторизовані ключі.
З метою аудиту використовуйте унікальні коментарі для кожного ключа (частина після матеріалу ключа, наприклад alice@workstation-2024), щоб ви могли визначити, якому користувачу або пристрою належить ключ. Коли співробітник звільняється або пристрій виводиться з експлуатації, знайдіть його ключ за коментарем і видаліть його.
Щоб виконати ротацію власного ключа, згенеруйте нову пару, додайте новий публічний ключ до authorized_keys, переконайтесь, що вхід за новим ключем працює, а потім видаліть запис старого ключа.
Практичний контрольний список

Генеруйте ключі Ed25519 за замовчуванням; використовуйте RSA 4096 лише для сумісності із застарілими серверами
Завжди захищайте приватний ключ надійною парольною фразою
Використовуйте ssh-copy-id для швидкого та безпомилкового розгортання ключів, коли це можливо
Переконайтесь, що дозволи каталогу .ssh встановлені на 700, а authorized_keys — на 600

Часті запитання

Чи можна додати кілька SSH публічних ключів до одного облікового запису користувача VPS?

Так. Кожен рядок у ~/.ssh/authorized_keys є незалежним авторизованим ключем. Додавайте по одному ключу на рядок. Це стандартний підхід для надання доступу кільком адміністраторам або з кількох пристроїв — кожна особа або пристрій має унікальний приватний ключ, а відкликання виконується на рівні рядка.

Що станеться, якщо я втрачу приватний ключ після вимкнення автентифікації за паролем?

Ви будете заблоковані у SSH. Для відновлення доступу потрібно використовувати позасмуговий консольний доступ вашого хостинг-провайдера (KVM/VNC), який доступний через більшість панелей керування VPS Хостингу. З консолі повторно увімкніть PasswordAuthentication yes у /etc/ssh/sshd_config, перезапустіть sshd та завантажте новий ключ. Саме тому тестування входу за ключем перед вимкненням паролів є обов’язковим.

Чи підтримується Ed25519 на всіх серверах?

Ed25519 вимагає OpenSSH 6.5 або новішої версії (випущеної у 2014 році). Будь-який сучасний дистрибутив Linux — Ubuntu 18.04+, Debian 9+, CentOS 7+, AlmaLinux 8+ — підтримує його нативно. Лише справді застарілі системи потребують резервного варіанту з RSA.

Чи варто використовувати одну пару SSH-ключів для кожного сервера, яким я керую?

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

Чи впливає завантаження SSH-ключа на мої SSL Сертифікати або конфігурацію веб-сервера?

Ні. SSH-ключі керують термінальним доступом до операційної системи та повністю відокремлені від TLS/SSL сертифікатів, які використовуються веб-серверами (Apache, Nginx) для HTTPS. Вони використовують різні порти (22 та 443), різні формати ключів і різні ланцюжки довіри. Зміна одного не має жодного впливу на інше.