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

У 2023 році компанія Cloudflare зафіксувала цікаву статистику: 36% успішних зломів серверів почалися з банального підбору пароля до SSH. Не через хитру вразливість нульового дня, не через соціальну інженерію рівня фільму з Джеймсом Бондом. Просто хтось поставив пароль admin123 або qwerty2024 і пішов пити каву. А бот, який перебирає 10 000 комбінацій на секунду, навіть не спітнів. Знайомо? Якщо ви досі логінитесь на свій сервер паролем - цей текст для вас. Бо є метод, який перетворює двері вашого сервера з картонних на бронйовані. І називається він SSH-ключі.

Що не так з паролями і чому боти вас вже знайшли

Давайте чесно: пароль - це замок на поштовій скриньці. Він зупинить чесну людину, але не того, хто цілеспрямовано хоче всередину. Середній сервер з відкритим SSH-портом отримує від 3 000 до 50 000 спроб підбору пароля на добу. Це не перебільшення - просто подивіться логи свого сервера командою grep "Failed password" /var/log/auth.log | wc -l і лякайтесь.

Проблема паролів не тільки в тому, що їх можна підібрати. Вони мають цілий букет вад:

• Люди повторюють паролі - той самий пароль на сервері, у пошті, у Netflix. Зламали одне - отримали все.
• Паролі крадуть - кейлогери, фішинг, витоки баз даних. Ваш пароль міг потрапити в даркнет ще минулого року.
• Складні паролі забувають - і записують на стікер, приклеєний до монітора. Або в текстовий файл на робочому столі з промовистою назвою паролі.txt.
• Brute-force атаки стали дешевими - оренда ботнету для перебору коштує менше, ніж ваша кава за тиждень.

SSH-ключі: як працює цей магічний файл

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

Система використовує асиметричне шифрування - два математично пов'язаних файли:

1. Приватний ключ (private key) - зберігається тільки у вас на комп'ютері. Нікому. Ніколи. Не передавайте.
2. Публічний ключ (public key) - лежить на сервері. Його можна показувати всьому світу, це безпечно.
3. При підключенні сервер створює математичну задачу, яку може розв'язати тільки ваш приватний ключ.
4. Ваш комп'ютер розв'язує задачу, сервер перевіряє відповідь - і двері відчинені.
5. Жодний пароль не передається мережею. Зовсім. Перехоплювати нічого.

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

"Якщо ваш SSH-ключ використовує RSA 4096 біт, то для його злому методом перебору знадобиться приблизно 300 трильйонів років. Навіть на найпотужнішому суперкомп'ютері планети. Пароль з 8 символів зламується за 2 години." - NIST Special Publication 800-57, рекомендації з криптографічного захисту.

Покроковий рецепт: від пароля до ключа за 10 хвилин

Досить теорії. Давайте зробимо це. Весь процес займає менше часу, ніж заварити нормальний чай.

Крок 1: Генеруємо пару ключів на вашому комп'ютері.

Відкрийте термінал (на Windows - PowerShell або WSL) і введіть:

ssh-keygen -t ed25519 -C "ваш_email@example.com"

Чому саме Ed25519, а не RSA? Він швидший, коротший і безпечніший. Якщо ваш сервер зовсім старий - використовуйте ssh-keygen -t rsa -b 4096. Система запитає, куди зберегти файл (натисніть Enter для дефолтного шляху) і попросить встановити passphrase. Встановіть його обов'язково - це як PIN-код для вашого ключа.

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

ssh-copy-id user@ваш_сервер_ip

Ця команда зробить усе за вас: підключиться паролем востаннє, створить потрібні директорії, встановить правильні права доступу. На Windows без ssh-copy-id доведеться скопіювати вміст файлу ~/.ssh/id_ed25519.pub вручну в ~/.ssh/authorized_keys на сервері.

Крок 3: Перевіряємо і відключаємо парольний вхід.

Спершу переконайтесь, що ключ працює - підключіться без пароля: ssh user@ваш_сервер_ip. Працює? Чудово. Тепер - найважливіший крок, який 60% людей забувають - вимкніть можливість входу паролем:

Відредагуйте /etc/ssh/sshd_config на сервері:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

Перезапустіть SSH: sudo systemctl restart sshd. Все. Тепер ваш сервер глухий до будь-яких спроб підбору пароля. Боти можуть стукати скільки завгодно - їх ніхто не чує.

Порівняння: паролі проти ключів у цифрах

Я люблю, коли безпека вимірюється не абстрактним "краще-гірше", а конкретними цифрами. Ось вони:

Різниця навіть не в рази. Вона на порядки. Це як порівнювати дерев'яний паркан з бетонною стіною.

П'ять помилок, які зводять захист SSH-ключами нанівець

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

1. Не встановлена passphrase на приватний ключ. Якщо хтось вкраде ваш ноутбук - отримає доступ до всіх серверів миттєво. Passphrase - це другий рівень захисту, не ігноруйте його.
2. Приватний ключ зберігається в хмарі. Google Drive, Dropbox, iCloud - ні. Просто ні. Це те саме, що повісити ключ від квартири на дошку оголошень біля під'їзду.
3. Один ключ на всю команду. Кожен розробник повинен мати свій унікальний ключ. Коли хтось звільняється - ви просто видаляєте його публічний ключ. А якщо ключ спільний? Доведеться перегенерувати для всіх.
4. Забули вимкнути парольну автентифікацію. Ви додали ключ, але залишили можливість входу паролем. Вітаю - ваш захист такий самий, як і був. Боти продовжують атакувати.
5. Ніколи не ротують ключі. Так, ключі теж варто оновлювати. Раз на рік - хороша практика. Особливо якщо хтось із колишніх колег міг мати доступ до вашої машини.

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

Якщо ви вже перейшли на SSH-ключі - вітаю, ви випередили 60% адміністраторів серверів. Але є кілька речей, які піднімуть ваш захист ще вище:

Змініть стандартний порт SSH. Так, це security through obscurity, і досвідчений хакер знайде новий порт за хвилину. Але 99% ботів стукають виключно на порт 22. Зміна на, скажімо, 49152 зменшує кількість автоматичних атак на 95%. Це як прибрати вивіску "тут гроші" з вікна - зміст не змінився, але випадкові грабіжники пройдуть повз.

Налаштуйте Fail2Ban. Навіть з вимкненою парольною автентифікацією логи будуть забиватися спробами підключення. Fail2Ban автоматично блокує IP-адреси після кількох невдалих спроб. Менше шуму - легше помітити справжню загрозу.

Використовуйте SSH-агент. Щоб не вводити passphrase щоразу, додайте ключ до SSH-агента: ssh-add ~/.ssh/id_ed25519. Агент тримає розшифрований ключ у пам'яті поточної сесії - зручно і безпечно.

Обмежте доступ за IP. Якщо ви підключаєтесь до сервера з фіксованої IP-адреси (офіс, VPN) - дозвольте SSH тільки з неї. У sshd_config або через firewall-правила. Це радикально звужує поверхню атаки.

• ssh-agent - для зручності без жертв безпеці
• Fail2Ban - для чистих логів і автоматичного бану
• Port knocking - для параноїків (і це комплімент)
• 2FA для SSH - Google Authenticator працює і тут, через PAM-модуль

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

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