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

SSH-ключ складається з двох файлів: приватний лишається тільки на вашому комп’ютері, а публічний дописують у ~/.ssh/authorized_keys на сервері або додають через панель хостингу. Створіть ключ командою ssh-keygen -t ed25519, перенесіть публічну частину командою ssh-copy-id, перевірте вхід у новому вікні і лише потім вимикайте вхід за паролем. Після цього обов’язково подивіться ефективні налаштування командою sshd -T: на нашому стенді файл 50-cloud-init.conf тихо залишав паролі увімкненими, хоча перевірка синтаксису проходила без зауважень.

Коротко: п’ять команд від нуля до входу за ключем

На своєму комп’ютері (Linux, macOS або PowerShell у Windows 10 і 11, де клієнт OpenSSH уже вбудований):

ssh-keygen -t ed25519 -C "laptop-2026"
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server
ssh -i ~/.ssh/id_ed25519 user@server

Друга команда один раз попросить пароль від сервера і відповість рядком Number of key(s) added: 1. На стенді вона сама створила каталог ~/.ssh з правами 700 і файл authorized_keys з правами 600. Якщо ви ще не підключалися до сервера по SSH, почніть з інструкції як підключитися по SSH з Windows, macOS і Linux.

Ed25519, RSA чи ECDSA: що показав замір

Ми згенерували ключі всіх поширених типів і для кожного 15 разів виконали повний вхід на сервер. Результати:

Висновок несподівано простий: на швидкість входу тип ключа не впливає, різниця в межах похибки. Час з’єднання визначає обмін ключами і запуск сесії, а не одна операція підпису. Відрізняються розмір і зручність: публічний ключ Ed25519 займає один короткий рядок, який легко вставити в панель або повідомлення, а RSA 4096 тягнеться на 700 символів і частіше ламається під час копіювання. Генерація RSA випадкова за тривалістю: десять запусків RSA 4096 тривали від 0,7 до 3,2 секунди.

Практичне правило:

• Ed25519 для всіх нових ключів. Від OpenSSH 9.5 саме його створює ssh-keygen без параметра -t, ми перевірили це на версії 9.6.
• RSA 3072 або 4096 лише тоді, коли сервер чи обладнання не розуміє Ed25519: дуже старий OpenSSH, деякі мережеві пристрої, застарілі бібліотеки.
• ECDSA працює, але переваг перед Ed25519 для звичайного входу не дає.
• Ключі FIDO2 (ed25519-sk) зберігають секрет в апаратному токені і вимагають дотику до нього. Без пристрою команда ssh-keygen -t ed25519-sk на стенді завершилась повідомленням Key enrollment failed: device not found.

Пароль до ключа і ssh-agent

Passphrase шифрує приватний ключ на диску: якщо файл украдуть разом із ноутбуком, без фрази він марний. Параметр -a задає кількість раундів KDF, тобто наскільки дорого перебирати фразу. Ми заміряли розшифрування ключа:

• -a 16 (типово): 148 мс;
• -a 100: 1,0 с;
• -a 200: 2,0 с.

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

ssh-keygen -t ed25519 -a 100 -C "work-laptop"
eval "$(ssh-agent -s)"
ssh-add -t 8h ~/.ssh/id_ed25519
ssh-add -l

Після ssh-add три входи поспіль пройшли без жодного запиту. Без агента ключ з паролем не працює в неінтерактивному режимі: скрипт отримав Permission denied (publickey,password). У Windows агент є службою, яку вмикають один раз у PowerShell від імені адміністратора: Get-Service ssh-agent | Set-Service -StartupType Automatic, потім Start-Service ssh-agent і ssh-add.

Як додати ключ на сервер, у панель хостингу і в PuTTY

Якщо ssh-copy-id недоступна (у Windows її немає), допишіть ключ вручну, увійшовши за паролем:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "ssh-ed25519 AAAA... laptop-2026" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Один ключ займає рівно один рядок. Коли ми розбили рядок навпіл, як буває під час копіювання з вузького вікна, сервер мовчки відмовив, а в лозі з’явилось лише Failed publickey. Перевірити файл можна командою ssh-keygen -lf ~/.ssh/authorized_keys: для кожного правильного рядка вона покаже відбиток. Закінчення рядків у стилі Windows (CRLF) sshd 9.6 приймав без проблем.

Панель хостингу. У панелі керування ключ зазвичай додають у налаштуваннях користувача або в розділі SSH: туди вставляють рядок із файлу .pub, і панель дописує його в authorized_keys вашого користувача. Вхід по SSH працює лише тоді, коли для користувача дозволено оболонку, а не nologin. На віртуальному хостингу це вирішує провайдер: у RichHost SSH-доступ є на всіх тарифах.

PuTTY і FileZilla. PuTTY працює з власним форматом .ppk. Перетворення ми перевірили в puttygen 0.81:

puttygen ~/.ssh/id_ed25519 -o key.ppk
puttygen key.ppk -O public-openssh
puttygen key.ppk -O private-openssh -o id_from_ppk

Файл отримав заголовок PuTTY-User-Key-File-3, plink з ним увійшов на сервер, а відбиток збігся з оригінальним ключем. Навпаки не вийде: OpenSSH, отримавши .ppk, відповів Load key "key.ppk": error in libcrypto. Той самий ключ можна використати для SFTP; як підключити його в клієнті, описано в інструкції як підключитися через FileZilla.

Файл ~/.ssh/config і помилка Too many authentication failures

Щоб не писати щоразу порт, ім’я і шлях до ключа, створіть запис у ~/.ssh/config:

Host myserver
    HostName 203.0.113.10
    Port 22
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Тепер достатньо ssh myserver, а ssh -G myserver покаже, які значення реально застосовано. Рядок IdentitiesOnly yes важливий: ми поклали в агент шість сторонніх ключів і підключилися з правильним ключем через -i. Клієнт спершу перебрав ключі агента, сервер з типовим MaxAuthTries 6 розірвав з’єднання з повідомленням Too many authentication failures. З IdentitiesOnly yes вхід пройшов одразу. Сам файл config теж має бути закритим: з правами 666 клієнт відмовився працювати (Bad owner or permissions).

Права на файли: що sshd вважає «bad ownership or modes»

Параметр StrictModes yes (типове значення) змушує sshd ігнорувати ключ, якщо файли можуть змінити інші користувачі. Клієнт при цьому бачить лише Permission denied (publickey), а причина є тільки в лозі сервера. Що ми отримали:

Цікава деталь Ubuntu і Debian: права 664 на authorized_keys і 775 на домашній каталог sshd пропустив, бо групою був особистий груповий запис самого користувача. Щойно файл переписали на чужу групу з тими ж правами 664, вхід заблокувався. Найпростіше правило: каталог ~/.ssh 700, файли в ньому 600, власник ви. На клієнті ще суворіше: приватний ключ з правами 644 клієнт ігнорує з попередженням UNPROTECTED PRIVATE KEY FILE. Як працюють ці цифри, пояснює стаття про права доступу до файлів на хостингу.

Вимикаємо вхід за паролем і перевіряємо sshd -T

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

# /etc/ssh/sshd_config.d/01-hardening.conf
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

sudo sshd -t
sudo sshd -T | grep -E '^(passwordauthentication|kbdinteractiveauthentication|permitrootlogin) '
sudo systemctl reload ssh

Сервіс в Ubuntu і Debian називається ssh, у RHEL-подібних системах sshd. Чому саме окремий файл з префіксом 01: sshd бере перше знайдене значення параметра, а рядок Include стоїть на початку основного конфігу. На стенді ми відтворили три пастки:

1. Файл 50-cloud-init.conf з PasswordAuthentication yes (його створює cloud-init на багатьох хмарних образах) і наш файл 99-hardening.conf: sshd -t без помилок, sshd -T показав passwordauthentication yes, вхід за паролем пройшов.
2. Рядок PasswordAuthentication no дописано в кінець основного sshd_config, як радять багато старих інструкцій: результат той самий, паролі працюють.
3. PasswordAuthentication no, але KbdInteractiveAuthentication yes і UsePAM yes: метод password сервер відхилив, а через keyboard-interactive той самий пароль прийняв, у лозі Accepted keyboard-interactive/pam.

Файл 01-hardening.conf виправив усі три випадки. Якщо в конфігурації є блоки Match, перевіряйте конкретне підключення: у нас sshd -T показував no, а sshd -T -C user=deploy,host=x,addr=127.0.0.1 показав yes для адреси з блоку Match Address. Повний чекліст першого налаштування сервера є в матеріалі налаштування VPS Ubuntu 24.04, а про те, навіщо все це робити, розповідає стаття про атаки підбору паролів.

Помилки SSH-ключів: причина і виправлення

Що робити у вашій ситуації

На тарифах віртуального хостингу RichHost сайтами керують через власну панель керування з ШІ-помічником, а з питань доступу допомагає підтримка з 10:00 до 20:00 за Києвом.

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

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

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

Де лежить приватний ключ і чи можна передати його колезі?

У каталозі ~/.ssh (у Windows C:\Users\ім'я\.ssh). Передавати не можна: колега створює власну пару, а ви додаєте його публічний ключ на сервер.

Що робити, якщо я вимкнув паролі і втратив ключ?

Зайти через веб-консоль або KVM у панелі провайдера, додати новий публічний ключ і перезавантажити sshd. На віртуальному хостингу ключ можна додати заново через панель або попросити допомоги в підтримці.

Чи потрібно міняти порт 22?

Це зменшує кількість сміття в логах, але не захищає. Головний захист дають вхід лише за ключем і вимкнені паролі, перевірені через sshd -T.