Определение простыми словами
SSH-ключ заменяет пароль при подключении к серверу: на стороне клиента лежит приватный ключ (~/.ssh/id_ed25519), на стороне сервера в файле ~/.ssh/authorized_keys — публичный. При подключении сервер проверяет, что у клиента есть приватная половина пары, и пускает без ввода пароля. Парольное окно остаётся только для самого ключа, если вы выбрали зашифровать его passphrase.
Публичный ключ можно безопасно публиковать, например в GitHub или передавать админу VPS. Приватный — нет: он эквивалентен полному доступу. Лучшая практика — генерировать ключи с алгоритмом Ed25519, хранить с passphrase и подгружать в ssh-agent.
Сравнение
| Алгоритм | Длина по умолчанию | Скорость | Когда использовать |
|---|---|---|---|
| Ed25519 | 256 бит | Очень высокая | Современный выбор по умолчанию |
| ECDSA (nistp256) | 256 бит | Высокая | Совместимость со старыми системами |
| RSA | 3072–4096 бит | Средняя | Старые серверы без поддержки Ed25519 |
| DSA | 1024 бита | Низкая | Не использовать (устарел, отключён в OpenSSH 7+) |
Кейсы использования
- Беспарольный вход на арендованный VPS и отключение PasswordAuthentication в /etc/ssh/sshd_config — главный шаг по защите от брутфорса.
- Деплой кода: CI получает приватный ключ через секреты, заходит на сервер и запускает rsync.
- Аутентификация в GitHub/GitLab по публичному ключу для git push без токенов.
- Подключение через bastion-host: ProxyJump и проброс ssh-agent позволяют ходить на внутренние машины одной командой.
- Негативный сценарий: утечка приватного ключа из репозитория или забытого ноутбука даёт атакующему root-доступ. Помогает passphrase, аппаратные токены (YubiKey) и быстрый отзыв через удаление из authorized_keys.
Технические детали
# Генерация современного ключа Ed25519 с комментарием
ssh-keygen -t ed25519 -C "stas@laptop" -f ~/.ssh/id_ed25519
# Добавить публичный ключ на сервер одной командой
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@1.2.3.4
# Если ssh-copy-id недоступен — вручную
cat ~/.ssh/id_ed25519.pub | ssh user@1.2.3.4
'mkdir -p ~/.ssh && chmod 700 ~/.ssh &&
cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys'
# Запретить вход по паролю на сервере
sed -i 's/^#?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl reload ssh
# Загрузить ключ в агент, чтобы не вводить passphrase каждый раз
ssh-add ~/.ssh/id_ed25519🔥 Где это применяется
Частые вопросы
Можно ли использовать один SSH-ключ для всех серверов?
Технически да, но риск выше: компрометация одной пары даёт доступ ко всем системам. Лучше генерировать отдельные ключи для важных контуров (production, личное, CI) и хранить разные passphrase.
Что делать, если приватный ключ утёк?
Сразу удалить соответствующий публичный ключ из ~/.ssh/authorized_keys на всех серверах и из настроек GitHub/GitLab. Сгенерировать новую пару и заменить во всех местах. После аудита проверить логи входов на предмет постороннего доступа.
Зачем passphrase, если ключ и так уникален?
Passphrase шифрует приватный ключ на диске. Если ноутбук украдут или скопируют файл, атакующий не сможет использовать ключ без подбора фразы. В ssh-agent passphrase запрашивается один раз за сессию.