SSH Keys (Криптографічні SSH-ключі)(Криптографічні SSH-ключі)

1. Огляд концепції та системна проблема

Традиційна автентифікація за допомогою логіна та пароля на віддалених серверах має критичні архітектурні вади: вразливість до атак повного перебору (brute-force), перехоплення у разі компрометації каналу (man-in-the-middle) та людський фактор (використання слабких або повторюваних паролів). Щойно порт 22 стає відкритим у публічний інтернет, ботнети генерують тисячі спроб підбору паролів щохвилини.

SSH Keys (Криптографічні ключі SSH) вирішують цю проблему через асиметричну криптографію. Користувач генерує пару математично пов'язаних ключів:

• Приватний ключ (Private Key): Зберігається виключно на локальній машині розробника у зашифрованому passphrase-вигляді та ніколи не передається мережею.
• Публічний ключ (Public Key): Розміщується на цільовому сервері у файлі ~/.ssh/authorized_keys.

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

+------------------+                    +--------------------+
|  Локальний клієнт|                    |  Віддалений сервер |
|  (~/.ssh/id_ed)  |                    |  (~/.ssh/auth_keys)|
+--------+---------+                    +---------+----------+
         |                                        |
         |  1. Запит на з'єднання (User, PubKey)  |
         |--------------------------------------->|
         |                                        | 2. Перевірка наявності
         |                                        |    публічного ключа
         |  3. Криптографічний челендж (Nonce)    |
         |<---------------------------------------|
         |                                        |
         | 4. Підпис nonce приватним ключем       |
         |--------------------------------------->|
         |                                        | 5. Валідація підпису
         |                                        |    публічним ключем
         |  6. Сесія відкрита (Authenticated)    |
         |<---------------------------------------|

2. Архітектурна таксономія та ментальна модель

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

1. Ed25519 (Edwards-curve Digital Signature Algorithm):
   • Сучасний де-факто золотий стандарт індустрії.
   • Базується на еліптичній кривій Curve25519.
   • Довжина ключа: 256 біт.
   • Висока стійкість проти side-channel та timing-атак, блискавична швидкість виконання операцій.
2. ECDSA (Elliptic Curve Digital Signature Algorithm):
   • Використовує стандартизовані NIST-криві (наприклад, nistp256 або nistp521).
   • Має потенційні ризики бекдорів у виборі параметрів генератора NIST та критичну чутливість до якості генератора випадкових чисел (RNG): повтор випадкового значення k повністю розкриває приватний ключ.
3. RSA (Rivest-Shamir-Adleman):
   • Класичний алгоритм на факторизації великих простих чисел.
   • Ключі довжиною менше 2048 біт вважаються скомпрометованими. Безпечним мінімумом є 4096 біт.
   • Масивний публічний та приватний ключ, повільніша генерація та підпис.
4. FIDO2 / Hardware Security Keys (ed25519-sk / ecdsa-sk):
   • Апаратна автентифікація через фізичні токени (YubiKey).
   • Приватний ключ генерується та ніколи не покидає захищений чіп токена; кожна SSH-сесія вимагає фізичного дотику.

3. Технічний пайплайн та внутрішня механіка

Генерація та деплоймент безпечного ключа

Генерація виробничого ключа Ed25519 із підвищеною кількістю раундів деривації ключа (KDF) для захисту від GPU-перебору passphrase:

# Генерація Ed25519 з коментарем та 100 раундами KDF
ssh-keygen -t ed25519 -a 100 -C "admin@production-cluster" -f ~/.ssh/id_ed25519_prod

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

ssh-copy-id -i ~/.ssh/id_ed25519_prod.pub deploy@vps.internal.net

Структура дозволів файлової системи Linux

Некоректні права доступу є причиною 90% збоїв SSH-автентифікації (Permission denied (publickey)):

# Локальна машина клієнта:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519_prod
chmod 644 ~/.ssh/id_ed25519_prod.pub
chmod 600 ~/.ssh/config

# Віддалений сервер:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh

Конфігурація клієнта (~/.ssh/config)

Для уникнення передачі довгих прапорців командного рядка використовується declarative client config:

Host prod-node-01
    HostName 198.51.100.24
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_prod
    IdentitiesOnly yes
    ServerAliveInterval 60
    ServerAliveCountMax 3

Host bastion-jumphost
    HostName 203.0.113.10
    User gatekeeper
    IdentityFile ~/.ssh/id_ed25519_bastion

Host internal-db
    HostName 10.0.4.15
    User postgres
    ProxyJump bastion-jumphost
    IdentityFile ~/.ssh/id_ed25519_db

4. Практичні інженерні сценарії в продакшені

01. Безпарольний доступ для автоматизованого CI/CD пайплайну

У середовищах GitHub Actions або GitLab CI/CD деплой здійснюється автоматично через виділений технічний SSH-ключ. Приватний ключ зберігається в зашифрованих Secrets репозиторію, а публічний ключ на сервері прив'язується до обмеженого shell або конкретної команди за допомогою директиви command="..." у authorized_keys:

command="/usr/local/bin/deploy-webhook.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-ed25519 AAAAC3NzaC1lZDI1NTE5... ci-deploy-key

Навіть якщо секрет CI/CD буде скомпрометовано, зловмисник зможе виконати лише детермінований деплой-скрипт, а не довільні команди в терміналі.

02. Доступ до ізольованих інфраструктурних нод через Bastion (ProxyJump)

У VPC приватні бази даних або сервери AI-агентів не мають публічних IP-адрес. Інженер підключається через проміжний Bastion хост без потреби експортувати приватний ключ на Bastion:

ssh -J gatekeeper@bastion.example.com deploy@10.0.1.50

SSH тунелює трафік TCP на рівні сокета через проксі-вузол, шифруючи сесію кінцевим ключем цільового сервера (ProxyJump не розкриває вміст трафіку бастіону).

03. Апаратні ключі FIDO2 для Zero Trust інфраструктури

У високонавантажених або регульованих фінтех-системах розробники зобов'язані використовувати апаратні токени YubiKey. Створюється ключ типу ed25519-sk. Кожна дія git push або SSH-сесія вимагає фізичного натискання пальцем на сенсор токена. Це повністю нівелює загрозу викрадення приватних ключів інфостілерами або шкідливим софтом на ноутбуці розробника.

5. Підводні камені, типові помилки та безпека

1. Генерація ключів без Passphrase: Збереження приватного ключа без надійного пароля створює критичну загрозу: будь-який шкідливий процес, скрипт або фізичний доступ до розблокованого ноутбука дозволяє миттєво скопіювати приватний ключ і отримати доступ до всієї інфраструктури. Завжди захищайте ключі паролем та використовуйте ssh-agent.
2. Неконтрольований sprawl у authorized_keys: З часом у файлі накопичуються десятки ключів колишніх розробників або тимчасових підрядників. Відсутність регулярного аудиту відкриває бекдори. Використовуйте централізоване управління ключами через Ansible, Teleport, HashiCorp Vault або SSH Certificate Authority (CA).
3. Використання SSH Agent Forwarding (-A): Увімкнення ForwardAgent yes у глобальному конфігу дозволяє віддаленим машинам отримувати доступ до вашого локального сокета ssh-agent. Ніколи не вмикайте Agent Forwarding глобально; використовуйте ProxyJump або ssh-add -c для підтвердження кожного використання ключа.