Как устроена аутентификация по ключу
Вместо пароля SSH может использовать пару ключей. Закрытый ключ хранится только на вашем компьютере, открытый копируется на сервер. При входе сервер отправляет задачу, которую можно решить лишь с закрытым ключом, и по ответу убеждается, что вы владелец, не получая сам ключ. Перехватить и подобрать такой вход гораздо сложнее, чем пароль, а при защите ключа парольной фразой безопасность повышается ещё.
Главное правило: закрытый ключ, файл без расширения .pub, нельзя отправлять по почте, класть в общие папки и копировать на чужие компьютеры. Открытый, с расширением .pub, безопасен для передачи: его и предназначено раздавать серверам. Если закрытый ключ попал в чужие руки, удалите соответствующую строку из authorized_keys на всех серверах и создайте новую пару.
Команды в статье одинаковы в Linux, macOS и Windows 10 и 11, где клиент OpenSSH встроен как дополнительный компонент; при его отсутствии включите его в дополнительных возможностях системы.
Создание пары ключей
Основная команда: ssh-keygen -t ed25519 -C "laptop-home". Ключ -t задаёт тип, -C добавляет комментарий, который помогает потом отличить ключи друг от друга, например название устройства. Алгоритм ed25519 считается современным и компактным; для старых систем, которые его не поддерживают, подойдёт ssh-keygen -t rsa -b 4096.
- Запустите команду. Программа спросит, куда сохранить файл. Путь по умолчанию: папка .ssh в домашнем каталоге, файл id_ed25519. В Windows это C:\Users\имя\.ssh.
- Введите парольную фразу и повторите её. Пустая фраза допустима, но тогда любой, кто получил файл, сразу сможет им пользоваться. Для рабочих ключей задавайте фразу.
- Программа создаст два файла: id_ed25519 (закрытый) и id_ed25519.pub (открытый) и покажет отпечаток и графическое изображение ключа.
- Убедитесь в наличии файлов: ls ~/.ssh в Linux и macOS, dir $env:USERPROFILE\.ssh в PowerShell.
- Посмотреть отпечаток позднее можно командой ssh-keygen -lf ~/.ssh/id_ed25519.pub.
Для отдельных серверов удобно создавать разные ключи и называть их через ключ -f: ssh-keygen -t ed25519 -f ~/.ssh/id_work. Изменить парольную фразу существующего ключа можно командой ssh-keygen -p -f путь-к-ключу.
Добавление открытого ключа на свой сервер
Нужен вход на сервер по паролю хотя бы один раз. Проще всего команда ssh-copy-id: ssh-copy-id -i ~/.ssh/id_ed25519.pub user@198.51.100.10. Она подключается по паролю и дописывает ключ в файл ~/.ssh/authorized_keys на сервере. Адрес в примере из блока документации, подставьте адрес и пользователя своего сервера. Если SSH слушает нестандартный порт, добавьте ключ -p с номером порта.
В Windows ssh-copy-id нет. Пример ручного способа для PowerShell (пример): type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh user@198.51.100.10 "cat >> ~/.ssh/authorized_keys". Если на сервере нет папки .ssh, создайте её и выставьте права.
| Объект на сервере | Правильные права |
|---|---|
| Домашний каталог | Не доступен для записи другим пользователям |
| ~/.ssh | 700 (chmod 700 ~/.ssh) |
| ~/.ssh/authorized_keys | 600 (chmod 600 ~/.ssh/authorized_keys) |
Слишком широкие права заставляют сервер игнорировать файл, и вход по ключу молча не работает: SSH просит пароль. Это самая частая причина неудачи.
Проверка входа и использование агента
Проверьте вход: ssh user@198.51.100.10. Если ключ имеет нестандартное имя, укажите его: ssh -i ~/.ssh/id_work user@198.51.100.10. При работе с парольной фразой программа спросит её один раз за сеанс. Чтобы не вводить фразу каждый раз, используйте агент: в Linux и macOS ssh-add ~/.ssh/id_ed25519 добавляет ключ в работающий агент; в Windows включите службу OpenSSH Authentication Agent и вызовите ssh-add. В macOS ключ можно сохранить в связке ключей, но параметры отличаются между версиями системы, поэтому смотрите справку ssh-add.
Для удобства задайте псевдонимы в файле ~/.ssh/config: строки Host, HostName, User, IdentityFile. Тогда вместо длинной команды достаточно ssh работа. Это не меняет безопасность, зато исключает ошибки.
Проверить, что именно происходит при входе, поможет подробный режим: ssh -v user@198.51.100.10 покажет, какие ключи пробуются и почему сервер их отвергает.
Отключение входа по паролю и типичные ошибки
Когда вход по ключу подтверждён, можно отключить вход по паролю на сервере: в файле /etc/ssh/sshd_config значение PasswordAuthentication выставляют в no и перезапускают службу. Делайте это осторожно: не закрывайте текущий сеанс, пока не проверите новый вход во втором окне, иначе вы рискуете лишиться доступа к серверу. Перед изменением настроек сохраните копию файла конфигурации.
Частые проблемы. Сообщение Permission denied (publickey) означает, что сервер не принял ключ: проверьте права, правильность строки в authorized_keys, имя пользователя. Предупреждение об «unprotected private key file» — слишком широкие права на закрытый ключ, в Linux и macOS исправляется командой chmod 600. Сообщение о смене ключа хоста возникает после переустановки сервера и убирается командой ssh-keygen -R адрес, но сначала убедитесь, что это ваш сервер, а не подмена.
Делайте резервную копию закрытых ключей в надёжном месте и не храните их в облачных папках без шифрования. Используйте ключи только для своих серверов и учётных записей, к которым у вас есть законный доступ.
Хранение, резервное копирование и смена ключей
Ключ — такая же учётная информация, как пароль, поэтому с ним нужна дисциплина. Держите закрытые ключи только на устройствах, которыми вы пользуетесь, и включайте шифрование диска. Для каждого устройства создавайте собственную пару, а не копируйте один ключ на все компьютеры: тогда потерянный ноутбук можно отключить, удалив одну строку в authorized_keys, и остальные устройства продолжат работать.
Подпишите ключи комментарием: по нему видно, какая строка кому принадлежит. Раз в несколько месяцев просматривайте содержимое authorized_keys на своём сервере и удаляйте записи давно не используемых устройств. Если владельцем ключа был сотрудник или знакомый, которому вы давали доступ, удалите его запись сразу после прекращения работы.
Резервная копия закрытого ключа нужна, но хранить её надо так же осторожно, как сам ключ: в зашифрованном хранилище или на отдельном носителе. Смена пары ключей — простая процедура: создайте новую, добавьте её открытую часть на сервер, проверьте вход, затем удалите старую строку. Так вы никогда не остаётесь без доступа. Не публикуйте в открытых репозиториях и мессенджерах файлы из папки .ssh: в них лежит закрытый ключ, а у автоматических сканеров на поиск таких файлов уходят минуты.