authorized_keys и ssh-copy-id: как настроить вход на свой сервер по SSH-ключу и не потерять доступ

Вход по ключу основан на паре файлов. Закрытый ключ остаётся на вашем компьютере и никому не передаётся. Публичный ключ можно копировать свободно: его помещают на сервер в файл authorized_keys в домашней папке нужного пользователя, в подпапке .ssh. Когда вы подключаетесь, сервер проверяет, что у вас есть закрытый ключ, соответствующий одному из перечисленных публичных, и не спрашивает пароль учётной записи.

Создать пару можно командой ssh-keygen. Современный разумный выбор — тип ed25519: ssh-keygen -t ed25519. Утилита предложит задать парольную фразу для закрытого ключа. Она защищает ключ, если файл попадёт в чужие руки, поэтому пропускать её не стоит. Подробности генерации разобраны на отдельной странице про ssh-keygen.

Ключевое различие по имени файла: id_ed25519 — закрытый ключ, id_ed25519.pub — публичный. Путаница между ними самая опасная ошибка: на сервер отправляется только файл с окончанием .pub. Закрытый файл не отправляют по почте, в мессенджеры и не кладут в облачные папки.

Самый простой способ — команда ssh-copy-id. Она подключается к серверу по паролю, добавляет публичный ключ в authorized_keys и сама выставляет нужные права. Пример: ssh-copy-id -i ~/.ssh/id_ed25519.pub имя@сервер, где вместо этих слов подставляют имя пользователя и адрес вашего сервера. Утилита есть в Linux и во многих сборках для macOS; если её нет, делают вручную.

Ручной порядок:

1. Подключитесь к серверу по паролю обычным способом.
2. Создайте каталог, если его нет: mkdir -p ~/.ssh.
3. Откройте файл ~/.ssh/authorized_keys в редакторе и вставьте содержимое публичного ключа. Одна строка — один ключ, строка не должна переноситься.
4. Выставьте права: chmod 700 ~/.ssh и chmod 600 ~/.ssh/authorized_keys.
5. Откройте новую сессию с вашего компьютера и проверьте вход, не закрывая прежнюю.

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

Если ключ добавлен, а сервер всё равно спрашивает пароль или пишет «Permission denied (publickey)», чаще всего виноваты права. Сервер OpenSSH в стандартной настройке проверяет, чтобы домашняя папка, папка .ssh и файл authorized_keys не были доступны на запись посторонним, и при нарушении тихо игнорирует ключ.

Также проверьте владельца: файлы должны принадлежать тому пользователю, под которым вы входите, а не root, если вы правили их через администратора. Исправляется командой chown. Если ключ в файле перенесён на несколько строк или к нему приклеен лишний символ, он не распознаётся; сравните строку с содержимым файла .pub. Подробный разбор сообщений об отказе есть на странице про ошибку «Permission denied (publickey)». Для диагностики подключайтесь с ключом -v: программа ssh напишет, какие ключи пробует.

Когда вход по ключу работает, пароль для SSH можно отключить: это снимает риск подбора пароля перебором. Но это и самый простой способ запереть себя за дверью, поэтому действуйте строго по порядку.

1. Откройте вторую, отдельную сессию и не закрывайте её до самого конца.
2. Убедитесь в третьей сессии, что вход по ключу работает без запроса пароля учётной записи.
3. Сделайте копию файла настроек: /etc/ssh/sshd_config.
4. Поменяйте параметр PasswordAuthentication на no. Проверьте, нет ли дополнительных файлов в папке /etc/ssh/sshd_config.d, которые переопределяют значение.
5. Проверьте синтаксис командой sudo sshd -t: тишина означает отсутствие ошибок.
6. Перезагрузите службу: на разных дистрибутивах она называется ssh или sshd, командой systemctl reload.
7. С новой сессии проверьте вход по ключу; с другой машины или без ключа убедитесь, что пароль больше не принимается.

Только после этого закрывайте страховочную сессию. Если вы работаете с удалённым сервером провайдера, заранее выясните, есть ли у него консоль управления из панели, не зависящая от SSH: она спасает при ошибке.

Ключ — это доступ, а значит, им нужно управлять, а не просто создавать.

Держите отдельную пару на каждое устройство. Тогда при потере ноутбука достаточно убрать одну строку из authorized_keys на серверах, а остальные устройства продолжат работать. Один общий ключ на все компьютеры превращает потерю любого из них в проблему для всех.

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

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

Для удобства есть файл ~/.ssh/config на вашем компьютере: в нём задают имя, адрес, пользователя и ключ для каждого сервера, и подключаться можно коротким именем. Файлу, как и остальным в папке, нужны строгие права.

Строка в authorized_keys может содержать параметры перед самим ключом, которые сужают возможности этого входа. Например, можно разрешить ключу запускать только одну команду или принимать подключения лишь с определённого адреса. Это полезно для автоматических задач вроде резервного копирования: если ключ утечёт, вред будет ограничен.

Точные названия параметров и их синтаксис описаны в справке sshd (команда man sshd, раздел про формат authorized_keys), и переписывать их по памяти не стоит: ошибка в строке приведёт к тому, что ключ не заработает. Меняйте по одному параметру и проверяйте вход в отдельной сессии.

Отдельно подумайте об учётной записи root. Вход под ней по ключу технически возможен, но для повседневной работы разумнее создать обычного пользователя, который при необходимости получает права через sudo, и ограничить прямой вход администратора в настройках службы. Так в журналах видно, кто и что делал, а компрометация одного ключа не даёт сразу полного контроля.