Де зберігаються SSH ключі в Linux — і як ними безпечно керувати

SSH (Secure Shell) — один з найкритичніших інструментів в екосистемі Linux. Системні адміністратори, розробники та інженери DevOps покладаються на нього щодня для віддаленого доступу до серверів, безпечної передачі файлів, автоматизації розгортання та управління інфраструктурою. Хоча більшість користувачів взаємодіють з SSH через просту команду терміналу, справжній безпечний фундамент лежить в парах SSH ключів — криптографічних облікових даних, які забезпечують автентифікацію без пароля, автоматизовані робочі процеси та посилений контроль доступу.

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

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

Що таке SSH ключі і чому вони важливі?

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

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

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

Місце зберігання ключів SSH за замовчуванням (ключі користувача)

Для будь-якого стандартного користувача Linux ключі SSH зберігаються у прихованій папці в домашній папці:

~/.ssh/

Це розширюється до повної шляху:

/home/username/.ssh/

Для користувача root конкретно:

/root/.ssh/

Звичайні файли всередині ~/.ssh/

Коли ви запускаєте ssh-keygen, ключі за замовчуванням записуються в цю папку, якщо ви не вказали іншу шляху під час генерування ключа.

Системні розташування SSH ключів (ключі хосту)

Крім користувацьких ключів, SSH daemon (sshd) — компонент на стороні сервера — зберігає власний набір ключів хосту. Вони зберігаються на рівні системи за адресою:

/etc/ssh/

Файли ключів хосту в /etc/ssh/

Ці ключі хосту служать іншій меті, ніж користувацькі ключі. Коли клієнт вперше підключається до сервера, сервер представляє свій публічний ключ хосту. Клієнт зберігає цей відбиток у ~/.ssh/known_hosts. При наступних підключеннях SSH перевіряє, чи відбиток збігається — захищаючи від атак типу man-in-the-middle.

> Важливо: Ключі хосту генеруються автоматично під час встановлення SSH сервера. Вам ніколи не потрібно створювати їх вручну, але ви повинні знати, де вони розташовані для аудиту та резервного копіювання.

Користувацькі розташування SSH ключів

Ви не обмежені директорією за замовчуванням ~/.ssh/. SSH ключі можуть генеруватися та зберігатися будь-де в файловій системі. Щоб використовувати ключ, збережений у нестандартному розташуванні, вкажіть його явно:

ssh -i /path/to/custom_key user@host

Використання ~/.ssh/config для кількох ключів

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

Host production-server
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/production_ed25519

Host staging-server
    HostName 203.0.113.20
    User deploy
    IdentityFile ~/.ssh/staging_ed25519

Host github.com
    User git
    IdentityFile ~/.ssh/github_key

З цією конфігурацією запуск ssh production-server автоматично використовує правильний ключ без будь-яких додаткових прапорців.

Як використовуються SSH ключі: клієнт проти сервера

Вихідні з’єднання (сторона клієнта)

Коли ви ініціюєте SSH з’єднання, SSH клієнт шукає приватні ключі в ~/.ssh/ за замовчуванням. Ці ключі використовуються для аутентифікації вас на віддаленому сервері.

Інструменти, які використовують SSH клієнтські ключі, включають:

• ssh — прямий доступ до віддаленої оболонки
• scp — безпечне копіювання файлів
• rsync — синхронізація файлів через SSH
• git — при використанні SSH-базованих віддалених репозиторіїв

Вхідні з’єднання (сторона сервера)

На сервері SSH перевіряє конкретний файл, щоб визначити, які користувачі мають право підключатися:

~/.ssh/authorized_keys

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

Практичний приклад: Якщо користувач alice хоче SSH на сервер як користувач webadmin, публічний ключ Alice повинен бути присутній в /home/webadmin/.ssh/authorized_keys — не в домашній директорії Alice на цьому сервері.

Дозволи файлів — критичні для безпеки SSH

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

Необхідні параметри дозволів

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
chmod 600 ~/.ssh/config

Таблиця посилань дозволів

Щоб виправити дозволи однією командою:

chmod 700 ~/.ssh && chmod 600 ~/.ssh/* && chmod 644 ~/.ssh/*.pub

Безпечне генерування SSH ключів

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

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

Для застарілих систем, які вимагають RSA, використовуйте щонайменше 4096 бітів:

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

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

Управління ключами за допомогою ssh-agent

Введення вашої парольної фрази кожного разу, коли ви використовуєте SSH ключ, стає непрактичним. ssh-agent вирішує це, кешуючи розшифровані ключі в пам’яті протягом вашої сесії.

Запуск ssh-agent та додавання ключа

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

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

Корисні команди ssh-agent

# List currently loaded keys
ssh-add -l

# Remove a specific key from the agent
ssh-add -d ~/.ssh/mykey

# Remove all keys from the agent
ssh-add -D

Копіювання публічних ключів на віддалені сервери

Найпростіший спосіб встановити ваш публічний ключ на віддаленому сервері — це ssh-copy-id:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@remote-host

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

Якщо ssh-copy-id недоступна, зробіть це вручну:

cat ~/.ssh/id_ed25519.pub | ssh user@remote-host "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Аудит та налагодження проблем з SSH ключами

Детальне логування підключень

Коли автентифікація SSH не вдається, режим детальності показує точно, що відбувається:

ssh -v user@host

Для ще більше деталей:

ssh -vvv user@host

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

Перевірте журнал SSH на сервері

На віддаленому сервері події автентифікації SSH записуються в:

# Debian/Ubuntu
tail -f /var/log/auth.log

# CentOS/RHEL/Fedora
tail -f /var/log/secure

# Systems using journald
journalctl -u sshd -f

Перевірте свій файл authorized_keys

# Check the file exists and has correct permissions
ls -la ~/.ssh/authorized_keys

# View its contents
cat ~/.ssh/authorized_keys

# Count how many keys are authorized
grep -c "ssh-" ~/.ssh/authorized_keys

Найкращі практики безпеки SSH ключів

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

1. Використовуйте один ключ для однієї мети

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

2. Регулярно оновлюйте ключі

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

3. Аудит authorized_keys файлів

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

# Find all authorized_keys files on a system
find / -name "authorized_keys" 2>/dev/null

4. Вимкніть автентифікацію за паролем

Після налаштування SSH ключів повністю вимкніть вхід SSH на основі пароля в /etc/ssh/sshd_config:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password

Перезавантажте sshd після змін:

systemctl restart sshd

5. Обмежте використання кореневого ключа

Уникайте використання кореневих SSH ключів у кількох середовищах. Замість цього використовуйте облікові записи користувачів з увімкненим sudo та окремими ключами.

6. Використовуйте аутентифікацію на основі сертифікатів для масштабування

Для великих інфраструктур розглядайте SSH сертифікати (через SSH Certificate Authority) замість управління окремими authorized_keys записами. Це значно спрощує управління доступом на багатьох серверах.

SSH ключі в хмарних та хостинг-середовищах

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

Для команд, які керують кількома середовищами, розгляньте можливість поєднання вашої стратегії SSH ключів зі структурованою конфігурацією VPS Control Panels, яка може спростити управління користувачами та контроль доступу в межах вашої інфраструктури.

Якщо ви запускаєте веб-додатки або сервіси, які вимагають безпечного зв’язку поза SSH, поєднання налаштування вашого сервера з належно налаштованими SSL Certificates забезпечує наскрізне шифрування для всього трафіку — не лише адміністративного доступу.

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

Швидкий довідник: розташування файлів SSH ключів

Висновок

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

Підсумовуючи ключові висновки:

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

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

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