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

1. Обзор концепции и системная проблема

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

SSH Keys (Криптографические ключи SSH) решают эту проблему через асимметричную криптографию. Пользователь генерирует пару математически связанных ключей:

• Приватный ключ (Private Key): Хранится исключительно на локальной машине разработчика в зашифрованном виде и никогда не передается по сети.
• Публичный ключ (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)

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

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. Неконтролируемый спралл в 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 для подтверждения каждого использования ключа.