Аутентификация по ключу

Сгенерируй пару ключей командой ssh-keygen -t ed25519. Ed25519 — текущая лучшая практика: маленькие ключи (256-бит), быстрые, без слабых вариантов параметров в отличие от RSA.

ssh-keygen -t ed25519 -C "deploy key for server.example"

Вывод:

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/alice/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/alice/.ssh/id_ed25519
Your public key has been saved in /home/alice/.ssh/id_ed25519.pub

Создаются два файла:

• ~/.ssh/id_ed25519 — приватный ключ. Относись к нему как к паролю. Права 600, никогда не передаётся, никогда никуда не загружается.
• ~/.ssh/id_ed25519.pub — публичный ключ. Безопасно копировать куда угодно. Именно это ты размещаешь на серверах.

Комментарий -C встроен в публичный ключ и помогает идентифицировать ключ позже. Парольная фраза шифрует приватный ключ на диске; без неё украденный файл ключа немедленно пригоден к использованию.

Приватный ключ никогда не покидает клиент — это гарантия безопасности. При аутентификации:

1. Сервер отправляет случайный вызов (nonce).
2. Твой SSH-клиент подписывает вызов приватным ключом.
3. Подпись отправляется на сервер.
4. Сервер проверяет подпись с помощью публичного ключа, хранящегося в ~/.ssh/authorized_keys.

Сервер никогда не видит приватный ключ. Сетевой атакующий, перехвативший сессию, видит только подпись — бесполезную без приватного ключа, который её создал. Это принципиально отличается от паролей, где сам секрет должен передаваться.

~/.ssh/authorized_keys на сервере авторизует конкретные публичные ключи. Каждая строка — один публичный ключ. При подключении SSH сопоставляет твой публичный ключ со списком. Формат:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFakePublicKeyDataHereForIllustration deploy@workstation.example

Права файла должны быть правильными: каталог ~/.ssh/ должен иметь права 700, а authorized_keys — 600. SSHd отклоняет аутентификацию через authorized_keys, если права слишком открыты — это предотвращает инъекцию чужих ключей другими пользователями сервера.

ssh-copy-id — безопасный автоматический способ добавить публичный ключ:

ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@server.example

Он добавляет твой публичный ключ в ~/.ssh/authorized_keys на удалённом хосте (создавая файл и каталог при необходимости, с правильными правами). После этого можно SSH-ить с ключом вместо пароля.

Ручное добавление ключа (когда ssh-copy-id недоступен):

cat ~/.ssh/id_ed25519.pub | ssh deploy@server.example \
  'mkdir -p ~/.ssh && chmod 700 ~/.ssh && \
   cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys'

ssh-agent кеширует расшифрованный приватный ключ в памяти, чтобы ты вводил парольную фразу один раз. Без агента каждое SSH-подключение запрашивает парольную фразу. С ним:

eval "$(ssh-agent -s)"    # запустить агент, экспортировать SSH_AUTH_SOCK
ssh-add ~/.ssh/id_ed25519 # добавить ключ; один раз спросит парольную фразу
ssh deploy@server.example # нет запроса парольной фразы — агент подписывает вызов

Агент работает как фоновый процесс. Переменная окружения SSH_AUTH_SOCK указывает на Unix-сокет; SSH-клиент использует этот сокет, чтобы попросить агента подписать вызовы от его имени. Приватный ключ никогда не покидает процесс агента — клиент получает только подпись.

Просмотр загруженных ключей:

ssh-add -l

Удаление всех ключей из агента (например, перед тем как уйти):

ssh-add -D

Переброска агента (-A) позволяет удалённым хостам использовать твой локальный агент — но несёт риск. Если ты подключился к бастиону SSH, а затем с бастиона к внутреннему серверу, обычно бастиону нужен свой ключ для внутреннего сервера. С переброской агента вызов SSH внутреннего сервера пробрасывается обратно через бастион к твоему локальному агенту:

ssh -A deploy@bastion.example   # включить переброску для этой сессии

Риск: root на bastion.example может получить доступ к сокету агента и выдавать себя за тебя на любом другом сервере, доступном твоему агенту. Переброска агента должна включаться только на бастионных хостах, которым ты полностью доверяешь и управляешь. Для большинства многоэтапных схем ProxyJump в ~/.ssh/config (рассмотренный в предыдущем уроке) безопаснее, потому что прыжок обрабатывается локально, без раскрытия агента на промежуточном хосте.