Що таке SSH-ключі і як ними користуватися

Hook

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

Для команди це означає менше блокувань, менше ручної рутини і менше шансів випадково відкрити сервер чужому акаунту. Для себе — один зрозумілий спосіб доступу до багатьох машин: VPS, продакшн, staging, домашні сервери, CI-агенти.

Проблема

Парольний доступ має кілька слабких місць:

його можна підбирати брутфорсом;
його часто перевикористовують на різних сервісах;
його складно нормально контролювати в команді;
його важко ротувати без зайвих дзвінків і переписок;
він не дає зручної прив’язки до конкретного пристрою.

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

Чому важливо

Якщо ти працюєш із серверами, SSH-ключі — це не «просунутий варіант», а базовий стандарт. Вони дають:

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

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

Як зробити

Згенерувати пару ключів ed25519

Сьогодні для більшості сценаріїв найкращий вибір — ed25519. Він короткий, швидкий і без зайвої мороки.

Команда:

ssh-keygen -t ed25519 -C "yura@laptop"

Краще одразу вказати шлях до окремого файлу, якщо ключів буде кілька:

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_work -C "work-laptop"

Під час створення система запропонує passphrase. Її варто задати. Це не пароля на сервер, а захист приватного ключа на твоєму диску.

Після створення в ~/.ssh/ буде два файли:

ls -l ~/.ssh/id_ed25519_work*

id_ed25519_work — приватний ключ
id_ed25519_work.pub — публічний ключ

Переглянути публічний ключ:

cat ~/.ssh/id_ed25519_work.pub

Переглянути fingerprint:

ssh-keygen -l -f ~/.ssh/id_ed25519_work.pub

Це корисно, коли треба звірити, що ключ не підмінено.

Додати публічний ключ на сервер

Найпростіший спосіб — ssh-copy-id:

ssh-copy-id -i ~/.ssh/id_ed25519_work.pub user@server.example.com

Після цього сервер додасть ключ до:

~/.ssh/authorized_keys

Якщо ssh-copy-id недоступний, зроби вручну:

cat ~/.ssh/id_ed25519_work.pub | ssh user@server.example.com 'umask 077; mkdir -p ~/.ssh; cat >> ~/.ssh/authorized_keys'

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

ssh user@server.example.com
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Власник теж має бути правильний:

chown -R user:user ~/.ssh

Якщо права надто відкриті, SSH часто просто відмовляється приймати ключ.

Підключитися і перевірити

Підключення з явним ключем:

ssh -i ~/.ssh/id_ed25519_work user@server.example.com

Якщо все працює, можна перевірити, який ключ використався, з детальним логом:

ssh -vvv -i ~/.ssh/id_ed25519_work user@server.example.com

У виводі шукай рядки про:

запропонований ключ;
accepted key;
successful authentication.

Якщо на сервері хочеш перевірити, чи вхід уже йде по ключу, можна тимчасово вимкнути парольну автентифікацію в конфігурації sshd:

sudo nano /etc/ssh/sshd_config

Додай або зміни:

PasswordAuthentication no
PubkeyAuthentication yes

Потім перезапусти службу:

sudo systemctl restart ssh

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

SSH-agent для зручності

Без SSH-agent доведеться щоразу вводити passphrase. З агентом ключ завантажується в пам’ять, і підключення стають зручнішими.

Запустити агент:

eval "$(ssh-agent -s)"

Додати ключ:

ssh-add ~/.ssh/id_ed25519_work

Перевірити список ключів у агенті:

ssh-add -l

Видалити один ключ:

ssh-add -d ~/.ssh/id_ed25519_work

Очистити всі ключі:

ssh-add -D

Щоб не вказувати ключ щоразу, можна додати конфігурацію в ~/.ssh/config:

Host prod-server
  HostName server.example.com
  User user
  IdentityFile ~/.ssh/id_ed25519_work
  AddKeysToAgent yes
  IdentitiesOnly yes

Після цього:

ssh prod-server

Це зручно, коли серверів багато, а ключів кілька.

Типові помилки і як їх уникнути

Неправильні права в ~/.ssh

Якщо каталог або файл доступні «занадто широко», SSH відмовиться працювати.

Перевір:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519_work
chmod 644 ~/.ssh/id_ed25519_work.pub
chmod 600 ~/.ssh/authorized_keys

Неправильний тип ключа

Старі приклади часто показують rsa. Він досі зустрічається, але для нових налаштувань краще використовувати ed25519.

Якщо на сервері або клієнті є сумісні обмеження, не міксуй усе підряд. Спочатку перевір, що сервіс підтримує сучасні алгоритми.

Не той ключ

Коли ключів багато, SSH може спробувати не той. Тоді допомагає:

ssh -i ~/.ssh/id_ed25519_work -o IdentitiesOnly=yes user@server.example.com

Або ж прописаний ~/.ssh/config.

Неправильний користувач

Ключ доданий не тому акаунту. Наприклад, root і deploy мають різні authorized_keys. Підключення буде відхилене, хоча сам ключ правильний.

Забутий passphrase

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

Неправильний формат переносу ключа

Не вставляй ключ у файл з пробілами, переносами рядків або зайвими символами. Один зайвий символ — і доступ не працює. Якщо копіюєш вручну, звір fingerprint.

Анти-патерни

Один ключ на все життя

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

Без passphrase

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

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

Людський доступ і автоматизація мають жити окремо. Для CI, деплоя або інтеграцій краще робити окремі ключі з мінімальними правами.

Копіювання приватного ключа на сервер

Приватний ключ не має лежати на сервері, до якого ти підключаєшся. На сервері має бути тільки публічний ключ у authorized_keys.

Залишити парольний доступ «на всяк випадок»

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

Не документувати, який ключ за що відповідає

Через пів року ніхто не згадає, чий це id_ed25519_2. Називай ключі зрозуміло:

id_ed25519_home
id_ed25519_work
id_ed25519_ci

Це економить час під час ротації.

Безпека: passphrase, revocation, key rotation

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

У разі втрати пристрою або підозри на компрометацію треба зробити дві речі:

Відкликати ключ на сервері.
Створити новий і замінити старий.

Відкликання зазвичай означає видалення відповідного рядка з authorized_keys:

sed -i.bak '/AAAAC3NzaC1lZDI1NTE5AAAAI.../d' ~/.ssh/authorized_keys

Або вручну видалити старий публічний ключ і зберегти файл.

Якщо доступів багато, веди облік ключів. Хоч би в простому списку:

ім’я ключа;
кому належить;
на яких серверах доданий;
коли створений;
коли треба переглянути знову.

Ротація ключів потрібна не лише після інцидентів. Добра практика — періодично оновлювати ключі, особливо якщо:

змінився ноутбук;
змінилася роль людини;
ключ давно не використовувався;
ти хочеш зменшити “довгоживучі” доступи.

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

Висновок

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

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