Як додати SSH ключі до нового або існуючого VPS

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

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

Чому SSH ключі архітектурно перевершують паролі

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

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

• Автоматизація без участі людини — конвеєри CI/CD, плейбуки Ansible та завдання rsync на основі cron вимагають неінтерактивної автентифікації. Паролі повністю унеможливлюють це.
• Гранульований контроль доступу — кожен запис authorized_keys може містити обмеження command=, from= та no-pty, точно визначаючи, що дозволено робити конкретному ключу.
• Можливість аудиту — окремі ключі можна відкликати без зміни спільного пароля та порушення роботи всіх інших користувачів або скриптів.
• Стійкість до фішингу — немає пароля, який можна вкрасти через підроблену сторінку входу.

Передумови

Перш ніж продовжити, підтвердьте наступне:

• У вас є працюючий VPS або ви в процесі його налаштування.
• Ваш локальний комп’ютер працює під управлінням Linux, macOS або Windows з встановленим OpenSSH (Windows 10/11 постачається з OpenSSH за замовчуванням; перевірте за допомогою ssh -V).
• У вас є root або sudo доступ до цільового сервера.
• Ви розумієте, що втрата приватного ключа без альтернативного методу входу (консольний доступ, ключ відновлення) може назавжди заблокувати вас.

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

Оригінальна команда ssh-keygen -t rsa -b 4096 є надійною, але не єдиним варіантом. Розуміння компромісів допомагає зробити правильний вибір для вашого середовища.

Ed25519 є рекомендованим алгоритмом для будь-якого сервера під управлінням OpenSSH 6.5 або новішої версії (випущеної у 2014 році). Використовуйте RSA 4096 лише при підключенні до застарілих систем, які не підтримують ключі на основі еліптичних кривих.

Частина 1: Додавання SSH ключів до нового VPS

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

Крок 1: Згенеруйте пару SSH ключів

Відкрийте термінал на вашому локальному комп’ютері. Згенеруйте пару ключів Ed25519:

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

Якщо вам потрібен RSA з міркувань сумісності:

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

Коли буде запропоновано вказати розташування файлу, натисніть Enter, щоб прийняти значення за замовчуванням (~/.ssh/id_ed25519 або ~/.ssh/id_rsa). Коли буде запропоновано ввести парольну фразу, встановіть її — вона шифрує приватний ключ на диску, тому навіть якщо ваш ноутбук буде вкрадено, ключ буде марним без парольної фрази. Ваш SSH агент (ssh-agent) кешуватиме розшифрований ключ у пам’яті, тому вам потрібно вводити парольну фразу лише один раз за сесію.

Перевірте згенеровані файли:

ls -la ~/.ssh/

Ви побачите:

• id_ed25519 — ваш приватний ключ (права доступу мають бути 600; ніколи не діліться цим файлом)
• id_ed25519.pub — ваш публічний ключ (безпечно копіювати куди завгодно)

Відобразіть публічний ключ для копіювання:

cat ~/.ssh/id_ed25519.pub

Вивід виглядає так:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... your_email@example.com

Скопіюйте весь цей рядок — ви вставите його у свою панель хостингу.

Крок 2: Додайте публічний ключ під час налаштування VPS

Увійдіть до панелі керування хостингом. Під час процесу створення VPS:

1. Виберіть операційну систему (Ubuntu 22.04 LTS, Debian 12, Rocky Linux 9 тощо).
2. Знайдіть розділ SSH ключ або Автентифікація.
3. Вставте повний вміст id_ed25519.pub у відповідне поле.
4. Завершіть решту налаштувань (план, регіон, ім’я хоста).

Після завантаження VPS система налаштування автоматично записує ваш публічний ключ до /root/.ssh/authorized_keys. Вхід за паролем не потрібен.

Крок 3: Підключіться до щойно налаштованого VPS

ssh root@your_vps_ip

Якщо ви використовували нестандартне ім’я файлу ключа, вкажіть його явно:

ssh -i ~/.ssh/id_ed25519 root@your_vps_ip

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

Частина 2: Додавання SSH ключів до існуючого VPS

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

Крок 1: Згенеруйте пару ключів (якщо у вас її немає)

Дотримуйтесь того самого процесу, що й у Кроці 1 Частини 1 вище. Якщо у вас вже є пара ключів, отримайте свій публічний ключ:

cat ~/.ssh/id_ed25519.pub

Крок 2: Скопіюйте публічний ключ на сервер

Метод A — ssh-copy-id (Рекомендований)

Утиліта ssh-copy-id автоматично обробляє створення директорій, додавання до файлу та встановлення прав доступу:

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@your_vps_ip

Введіть пароль за запитом. Інструмент додає ключ до ~/.ssh/authorized_keys на віддаленому сервері та встановлює правильні права доступу. Це найбезпечніший метод, оскільки він запобігає випадковому перезапису існуючих ключів.

Метод B — Ручне розгортання

Використовуйте це, коли ssh-copy-id недоступний (наприклад, у деяких середовищах Windows або обмежених мережах):

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"

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

Метод C — Вручну через текстовий редактор (Запасний варіант)

Увійдіть на сервер за допомогою пароля:

ssh root@your_vps_ip

Створіть директорію .ssh, якщо вона не існує:

mkdir -p ~/.ssh
chmod 700 ~/.ssh

Відкрийте authorized_keys у текстовому редакторі:

nano ~/.ssh/authorized_keys

Вставте свій публічний ключ на новий рядок. Збережіть за допомогою Ctrl+X, потім Y, потім Enter. Встановіть права доступу:

chmod 600 ~/.ssh/authorized_keys

Завершіть сесію:

exit

Крок 3: Перевірте вхід за ключем

Перевірте підключення перед внесенням будь-яких подальших змін до SSH демона. Відкрийте нове вікно термінала (не закривайте існуючу сесію):

ssh -i ~/.ssh/id_ed25519 root@your_vps_ip

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

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

Крок 4: Посиліть конфігурацію SSH демона

Після підтвердження доступу за ключем відкрийте файл конфігурації SSH демона:

nano /etc/ssh/sshd_config

Застосуйте наступні налаштування:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password
AuthorizedKeysFile .ssh/authorized_keys
ChallengeResponseAuthentication no
UsePAM yes

Ключові примітки щодо цих директив:

• PermitRootLogin prohibit-password дозволяє вхід root за ключем, але блокує вхід root за паролем — кращий компроміс, ніж PermitRootLogin no, коли ви ще налаштовуєте непривілейованого sudo користувача.
• ChallengeResponseAuthentication no вимикає клавіатурно-інтерактивну автентифікацію, яка може обійти PasswordAuthentication no у деяких конфігураціях PAM.
• На Ubuntu 22.04+, файл /etc/ssh/sshd_config.d/50-cloud-init.conf може перевизначати ваші налаштування. Перевірте та відредагуйте його за необхідності.

Перевірте синтаксис конфігурації перед перезапуском:

sshd -t

Якщо помилок не виявлено, перезапустіть SSH сервіс:

systemctl restart sshd

На системах, що використовують ssh.service замість sshd.service:

systemctl restart ssh

Управління кількома SSH ключами та користувачами

Реальні середовища рідко передбачають один ключ і одного користувача. Ось як обробляти складніші сценарії.

Додавання ключів для кількох користувачів

Кожен обліковий запис користувача має власний файл ~/.ssh/authorized_keys. Щоб додати ключ для непривілейованого користувача з іменем deploy:

mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
echo "ssh-ed25519 AAAAC3... deploy@ci-server" >> /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh

Крок chown часто пропускається і призводить до збоїв автентифікації — SELinux та OpenSSH обидва перевіряють, що файл authorized_keys належить користувачу, що автентифікується.

Обмеження можливостей ключа

Ви можете додати параметри на початку будь-якого рядка в authorized_keys, щоб обмежити його можливості. Це особливо корисно для ключів розгортання або автоматизації резервного копіювання:

command="/usr/bin/rsync --server --daemon .",no-pty,no-agent-forwarding,no-X11-forwarding ssh-ed25519 AAAAC3... backup@monitoring

Цей ключ може виконувати лише rsync у режимі демона — нічого більше.

Використання ~/.ssh/config для зручніших підключень

Замість введення довгих команд ssh, визначте псевдоніми хостів на вашому локальному комп’ютері:

Host myserver
    HostName 203.0.113.45
    User root
    IdentityFile ~/.ssh/id_ed25519
    Port 22

Після збереження цього у ~/.ssh/config, підключайтесь просто за допомогою:

ssh myserver

Використання ssh-agent для кешування парольних фраз

Якщо ваш приватний ключ має парольну фразу (так і має бути), додайте його до агента, щоб вас не запитували повторно:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

На macOS додайте --apple-use-keychain для збереження між перезавантаженнями:

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

Поширені проблеми та усунення несправностей

Проблема: Після додавання ключа все одно запитується пароль

Запустіть підключення з детальним виводом для діагностики:

ssh -vvv root@your_vps_ip

Шукайте рядки на кшталт Offering public key та Server accepts key. Якщо ключ пропонується, але відхиляється, проблема майже завжди пов’язана з правами доступу до файлів на сервері.

Перевірте права доступу на сервері:

ls -la ~/.ssh/
stat ~/.ssh/authorized_keys

Необхідні права доступу:

• ~/.ssh/ — 700 (drwx——)
• ~/.ssh/authorized_keys — 600 (-rw——-)
• Домашня директорія ~/ — не повинна бути доступна для запису всім (755 або 750)

Проблема: SELinux блокує автентифікацію на RHEL/Rocky/AlmaLinux

restorecon -Rv ~/.ssh

Проблема: Файл authorized_keys має закінчення рядків Windows (CRLF)

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

sed -i 's/r//' ~/.ssh/authorized_keys

Проблема: Пропонується неправильний ключ

Якщо у вас є кілька ключів, вкажіть правильний явно:

ssh -i ~/.ssh/id_ed25519 root@your_vps_ip

Або налаштуйте це в ~/.ssh/config, як показано вище.

SSH ключі в контексті вашої хостингової інфраструктури

Автентифікація за SSH ключами — це не лише питання одного сервера, вона масштабується на всю вашу інфраструктуру. Якщо ви керуєте парком виділених серверів, централізований підхід з використанням таких інструментів, як Ansible, Puppet або менеджер секретів (HashiCorp Vault, AWS Secrets Manager) для розповсюдження та ротації авторизованих ключів є необхідним.

Для команд, що запускають веб-додатки на VPS з cPanel, інтерфейс SSH Access у cPanel в розділі Security надає графічний інтерфейс для генерації та управління парами ключів — корисний для розробників, які не впевнено почуваються в командному рядку, але потребують безпечного доступу.

Якщо ви запускаєте GPU-інтенсивні навантаження на інфраструктурі GPU хостингу, автентифікація за SSH ключами є особливо критичною, оскільки ці екземпляри часто виконують тривалі завдання без участі людини. Скомпрометовані облікові дані на GPU сервері можуть призвести до значних несанкціонованих витрат на обчислення на додаток до витоку даних.

Поєднання посилення SSH з дійсним SSL сертифікатом для будь-яких веб-сервісів, що працюють на тому самому сервері, одночасно закриває два найпоширеніші вектори атак — неавтентифікований доступ до оболонки та незашифрований HTTP трафік.

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

Ротація ключів та довгострокове управління ключами

SSH ключі не закінчуються автоматично. Без політики ротації ключ, скомпрометований роки тому, може досі надавати доступ. Встановіть такі практики:

• Ротуйте ключі щорічно або негайно при підозрі на компрометацію.
• Регулярно перевіряйте файли authorized_keys на всіх серверах. Видаляйте ключі, що належать колишнім співробітникам або виведеним з експлуатації сервісам.
• Використовуйте окремі ключі для кожного пристрою — не копіюйте один і той самий приватний ключ на кілька ноутбуків або серверів. Якщо один пристрій загублено, ви відкликаєте лише цей ключ.
• Використовуйте окремі ключі для кожної ролі — ваш ключ особистого доступу, ключ розгортання CI/CD та ключ автоматизації резервного копіювання мають бути різними.
• Документуйте власників ключів — ведіть реєстр, що відображає відбиток кожного публічного ключа на його власника, призначення та дату закінчення терміну дії.

Щоб відобразити відбиток ключа для аудиту:

ssh-keygen -lf ~/.ssh/id_ed25519.pub

Контрольний список технічних рішень

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

• Алгоритм: Використовуйте Ed25519, якщо не підключаєтесь до систем старіших за OpenSSH 6.5; використовуйте RSA 4096 як запасний варіант.
• Парольна фраза: Завжди встановлюйте її для приватних ключів, що використовуються людьми; сервісні ключі для автоматизації можуть не мати її, якщо зберігаються в менеджері секретів.
• Метод розгортання: Використовуйте ssh-copy-id для інтерактивного налаштування; використовуйте управління конфігурацією (Ansible, Puppet) для розгортання на парку серверів.
• Перевірка прав доступу: Підтвердьте 700 для ~/.ssh/, 600 для authorized_keys та правильне власництво перед вимкненням автентифікації за паролем.
• Перевіряйте перед блокуванням: Завжди перевіряйте вхід за ключем в окремій сесії термінала перед встановленням PasswordAuthentication no.
• Перевірка конфігурації демона: Запускайте sshd -t перед перезапуском SSH сервісу для виявлення синтаксичних помилок.
• Вимкнення автентифікації за паролем: Встановіть PasswordAuthentication no та ChallengeResponseAuthentication no разом — одного недостатньо на системах з увімкненим PAM.
• Політика входу root: Надавайте перевагу PermitRootLogin prohibit-password над PermitRootLogin yes; перейдіть на непривілейованого sudo користувача та встановіть PermitRootLogin no як остаточний посилений стан.
• Ротація ключів: Плануйте щорічну ротацію; відкликайте негайно при втраті пристрою або зміні персоналу.
• Аудит: Періодично запускайте grep -r "" /home/*/.ssh/authorized_keys /root/.ssh/authorized_keys для перегляду всіх авторизованих ключів у системі.

Поширені запитання

Чи можна додати кілька SSH ключів до одного сервера?

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

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

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

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

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

Чи вимикає додавання SSH ключа автоматично вхід за паролем?

Ні. Додавання ключа до authorized_keys вмикає вхід за ключем, але не вимикає автентифікацію за паролем. Ви повинні явно встановити PasswordAuthentication no у /etc/ssh/sshd_config та перезапустити SSH демон, щоб забезпечити доступ лише за ключем.

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

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