SSH-ключі використовують криптографію з відкритим ключем. У вас є два файли: приватний ключ (зберігається у вас) і публічний ключ (розміщується на сервері). Жоден пароль не передається мережею.

Генерація ключів (Linux / Mac)

# Сучасний алгоритм Ed25519 (рекомендується)
ssh-keygen -t ed25519 -C "your@email.com"

# Або RSA-4096 для сумісності
ssh-keygen -t rsa -b 4096 -C "your@email.com"

# Ключі збережуться в ~/.ssh/
# ~/.ssh/id_ed25519      ← приватний (НІКОМУ не передавати)
# ~/.ssh/id_ed25519.pub  ← публічний (можна розміщувати всюди)

Додавання ключа на сервер

# Автоматично (найпростіший спосіб)
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server-ip

# Або вручну:
cat ~/.ssh/id_ed25519.pub | ssh user@server-ip   "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Генерація ключів у Windows (PuTTYgen)

Завантажте PuTTYgen з офіційного сайту PuTTY
Виберіть EdDSA або RSA (4096 біт)
Натисніть Generate і рухайте мишею
Збережіть приватний ключ (Save private key)
Скопіюйте публічний ключ з текстового поля вгорі
Додайте його в ~/.ssh/authorized_keys на сервері

Вимкнення входу за паролем

⚠️ Виконуйте, лише переконавшись, що вхід за ключем працює! Інакше втратите доступ до сервера.

sudo nano /etc/ssh/sshd_config

# Змінити або додати:
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password

sudo systemctl restart sshd

✅ Після налаштування SSH-ключів атаки перебором паролів стають безглуздими — сервер просто не прийме пароль.

Розбір типових помилок SSH

Більшість проблем із ключами вкладаються у пʼять помилок. Дивіться на точний текст — він підказує, в який бік копати.

Permission denied (publickey) — сервер прийняв зʼєднання, але жоден із запропонованих ключів не підійшов. Причини: не той файл ключа, ключ не додано до authorized_keys потрібного користувача, або в ssh-agent просто не той ключ.
Too many authentication failures — клієнт перебрав більше ключів, ніж дозволяє MaxAuthTries на сервері, ще до того як дійшов до потрібного. Вкажіть ключ явно: ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 user@server-ip.
WARNING: UNPROTECTED PRIVATE KEY FILE! — права на файл приватного ключа ширші за 600, і ssh відмовляється його читати. Виправляється командою chmod 600 ~/.ssh/id_ed25519.
Agent admitted failure to sign using the key — ключ значиться в ssh-agent, але сам файл на диску видалено, перейменовано або він недоступний для читання.
REMOTE HOST IDENTIFICATION HAS CHANGED — відбиток сервера в ~/.ssh/known_hosts не збігається з поточним. Якщо сервер не перевстановлювали і IP не передавали іншому клієнту — це привід зупинитися й перевірити, а не одразу видаляти рядок із файлу.

Ed25519, RSA та ECDSA: який алгоритм обрати

Тип ключа задається прапорцем -t під час генерації. Різниця не лише в назві.

Алгоритм	Довжина ключа	Швидкість операцій	Сумісність
Ed25519	256 біт (фіксована)	Висока	OpenSSH 6.5+ (починаючи з 2014 року)
RSA-4096	4096 біт	Середня під час підпису	Працює всюди, включно зі старими системами й панелями
RSA-2048	2048 біт	Висока	Мінімально припустима довжина, використовувати лише за обмежень сервера
ECDSA	256-521 біт	Висока	Підтримується широко, але криптографи радять уникати через особливості NIST-кривих

Для нових серверів і власних робочих машин використовуйте Ed25519 — коротший, швидший, стійкіший до помилок генерації випадковості. RSA-4096 залишайте для застарілого обладнання, яке не розуміє Ed25519.

Коли SSH-ключі не підходять

Ключі — не універсальне рішення на всі випадки.

Спільний сервісний обліковий запис без файлової системи для ~/.ssh, доступ до якого йде лише через вебпанель — там тримаються на паролі чи токені панелі, а не на SSH-ключі.
Разовий доступ підряднику на 10-15 хвилин — простіше видати тимчасовий пароль і одразу змінити його після роботи, ніж заводити ключ і потім гарантовано вичищати його з authorized_keys.
Пристрій без захищеного зберігання приватного ключа, наприклад спільний термінал у коворкінгу — ключ, залишений там, компрометує всі сервери, куди його було додано.
Парк із десятків серверів без bastion-хоста чи центрального керування ключами — після звільнення співробітника доведеться вручну чистити authorized_keys на кожній машині, і один сервер забудуть майже напевно.

Перевірка, що вхід за паролем справді вимкнено

Файл sshd_config може містити директиву, яку перевизначає інший файл у Include, тому перевіряйте не текст файлу, а те, що реально застосував демон.

# Показує чинну конфігурацію sshd, а не вміст файлу
sudo sshd -T | grep -i passwordauthentication

# Явно запросити парольну автентифікацію — сервер повинен відмовити
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password user@server-ip

# Переконатися, що останній вхід відбувся саме за ключем
sudo grep "Accepted" /var/log/auth.log | tail -5

Якщо перша команда вивела passwordauthentication no, друга команда завершилася помилкою доступу, а в журналі видно рядок Accepted publickey — вхід за паролем вимкнено насправді, а не лише у файлі конфігурації.