SSH-ключи и аутентификация

Зачем ключи, если есть пароль

Вход на сервер по паролю работает, но плохо масштабируется и легко ломается. Пароль можно подобрать перебором, он утекает в логи и историю, его приходится вводить руками или хранить в открытом виде в скриптах. На проде по SSH ходят десятки людей и автоматических систем (CI, Ansible, бэкапы), и пароль тут быстро становится дырой.

Аутентификация по ключу решает это. На сервер ты приходишь не с секретом, который нужно передать, а с доказательством, что у тебя есть приватный ключ. Сам ключ при этом сервер не покидает.

Пара ключей: приватный и публичный

Ключ — это не одна строка, а пара связанных файлов:

• Приватный ключ (id_ed25519) — лежит только у тебя, в ~/.ssh/. Его никому не отдают и не копируют на серверы.
• Публичный ключ (id_ed25519.pub) — можно раздавать свободно. Его кладут на серверы, в GitLab, в GitHub.

Математика устроена так, что публичным ключом можно проверить подпись, сделанную приватным, но восстановить приватный из публичного нельзя. Поэтому публичную половину не страшно публиковать.

Создать пару:

$ ssh-keygen -t ed25519 -C "deploy@laptop"
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/user/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Your identification has been saved in /home/user/.ssh/id_ed25519
Your public key has been saved in /home/user/.ssh/id_ed25519.pub

-t ed25519 выбирает современный алгоритм: ключи короткие, быстрые, стойкие. RSA тоже работает, но тогда бери длину не меньше 4096 (-t rsa -b 4096). -C добавляет комментарий-метку, по нему потом удобно понять, чей это ключ.

Passphrase — это пароль на сам приватный ключ. Если ноутбук украдут, без passphrase ключом сразу воспользуются. С passphrase ключ сначала надо расшифровать. Здесь помогает ssh-agent, чтобы не вводить её каждый раз.

authorized_keys: кого пускает сервер

Сервер пускает по ключу того, чей публичный ключ записан в файле ~/.ssh/authorized_keys нужного пользователя. Одна строка — один разрешённый ключ.

Положить свой ключ на сервер удобнее всего командой:

ssh-copy-id deploy@server

Она допишет твой id_ed25519.pub в ~/.ssh/authorized_keys пользователя deploy. После этого ssh deploy@server пустит без пароля.

Права на файлы здесь критичны. SSH намеренно игнорирует ключи, если к каталогу или файлу есть лишний доступ:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Если вход по ключу «молча не работает», первым делом проверь права и владельца ~/.ssh — это самая частая причина.

ssh-agent: ввести passphrase один раз

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

$ eval "$(ssh-agent -s)"
Agent pid 4123

$ ssh-add ~/.ssh/id_ed25519
Enter passphrase for /home/user/.ssh/id_ed25519:
Identity added: /home/user/.ssh/id_ed25519

На десктопе агент обычно уже запущен системой. Внутри CI агент поднимают вручную и скармливают ему ключ из защищённой переменной — так пайплайн ходит по SSH, не печатая ключ в лог.

Тот же ключ для git

GitLab и GitHub используют ровно тот же механизм. Ты добавляешь свой публичный ключ в настройках профиля, и git push по адресу git@... проходит без пароля. Проверить связь:

$ ssh -T git@gitlab.com
Welcome to GitLab, @username!

Один ключ закрывает и серверы, и git-хостинг. Отдельный пароль на каждый сервис не нужен.

Что важно запомнить

Приватный ключ не покидает твою машину; на серверы и хостинги уходит только публичный.

Сервер пускает того, чей публичный ключ лежит в ~/.ssh/authorized_keys. Права 700 на каталог и 600 на файл обязательны, иначе SSH-ключ проигнорирует.

ssh-agent хранит расшифрованный ключ, чтобы не вводить passphrase на каждое соединение. Тот же ключ работает и для git по SSH.

В следующем уроке разберём как ~/.ssh/config и bastion упрощают доступ к множеству серверов.