SSH authorized keys: как добавить ключ на сервер — инструкция для новичка

Что такое ssh authorized keys и зачем это нужно

Файл ~/.ssh/authorized_keys — это список открытых ключей, которым сервер доверяет. Когда вы подключаетесь по SSH (Secure Shell, защищённая оболочка), сервер сверяет ваш ключ с этим списком и пускает вас без пароля. Одна строка в файле — один ключ, а файл относится к конкретному пользователю на сервере.

Вход по ключу надёжнее пароля по двум причинам. Во-первых, ключ нельзя подобрать перебором: Ed25519 использует фиксированную длину 256 бит, а у RSA длина обычно составляет 3072–4096 бит. Во-вторых, закрытый ключ не передаётся по сети: он остаётся на вашем компьютере, а на сервер попадает только открытая часть.

Такой способ пригодится владельцам VPS (виртуального выделенного сервера), системным администраторам и разработчикам, которые деплоят код на удалённые машины. Дальше в статье мы используем сквозной пример: подключение user@192.0.2.10 по стандартному порту 22.

Что вы получите, настроив вход по ключу:

• защиту от подбора пароля ботами, которые стучатся на порт 22 круглосуточно;
• вход одной командой ssh user@192.0.2.10 без ввода пароля;
• возможность отозвать доступ, удалив одну строку из файла;
• отдельный ключ для каждого устройства и сотрудника.

Как работает вход по ключу и где лежит файл authorized_keys

Вход по ключу использует пару файлов: закрытый ключ хранится на вашем компьютере, открытый лежит на сервере. Когда вы запускаете ssh user@192.0.2.10, клиент подключается к порту 22 и предлагает открытый ключ. Подключение принимает sshd (SSH daemon, демон SSH-сервера).

Сервер ищет предложенный ключ в файле ~/.ssh/authorized_keys того пользователя, под которым вы входите. Если ключ найден, sshd отправляет клиенту случайный запрос, клиент подписывает его закрытым ключом, а сервер проверяет подпись открытым. Сам закрытый ключ по сети не передаётся и не покидает компьютер.

Путь к файлу задаёт параметр AuthorizedKeysFile в /etc/ssh/sshd_config. По умолчанию это ~/.ssh/authorized_keys в домашней папке. У каждого пользователя файл свой: ключ из /home/anna не даст входа под root.

Содержимое файла покажет команда cat ~/.ssh/authorized_keys. Одна строка в нём равна одному открытому ключу:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIq8Xk anna@laptop

Строка состоит из таких частей:

• ssh-ed25519 — тип ключа; у Ed25519 длина фиксированная, 256 бит;
• длинная base64-последовательность — сам открытый ключ;
• anna@laptop — необязательный комментарий, чтобы отличать ключи друг от друга.

Какой тип ключа выбрать: Ed25519 или RSA

Для новых серверов выбирайте Ed25519: это алгоритм подписи на эллиптических кривых с фиксированной длиной 256 бит. Ключ короткий, строка в authorized_keys занимает одну компактную линию, а генерация проходит за доли секунды.

RSA (по первым буквам фамилий авторов: Rivest, Shamir, Adleman) нужен, когда на сервере или в клиенте очень старое программное обеспечение. Берите длину от 3072 до 4096 бит: чем больше, тем надёжнее, но вход чуть медленнее. ECDSA (алгоритм цифровой подписи на эллиптических кривых) встречается реже, и для нового ключа его обычно не выбирают.

Сравнение типов в одной таблице:

Итог: Ed25519 для новых систем, RSA 4096 для очень старого ПО. При генерации ssh-keygen предложит ввести парольную фразу. Задайте её: если файл закрытого ключа id_ed25519 из папки ~/.ssh попадёт к постороннему, без фразы он не сможет им воспользоваться.

Как добавить ключ в authorized_keys: пошаговая инструкция

Весь процесс занимает 2–3 минуты. Вы создадите пару ключей на своём компьютере и положите открытый ключ в файл ~/.ssh/authorized_keys на сервере. Закрытый ключ остаётся у вас и на сервер не копируется никогда. Если виртуального сервера (VPS) у вас ещё нет, найдите ответы на вопросы о VPS и вернитесь к инструкции.

Команды ниже работают в Linux и macOS. В Windows ключ создают через PuTTYgen, программу с графическим интерфейсом: порядок работы с ней описан в статье как создать ключ в PuTTYgen. Встроенный OpenSSH в Windows 10 и 11 понимает те же команды, что и терминал Linux.

В примерах используется пользователь user и адрес 192.0.2.10, подставьте свои значения. Выполните шаги по порядку и не закрывайте текущую сессию на сервере до проверки:

1. Создайте ключи. Выполните ssh-keygen -t ed25519 -C "имя@ноутбук". На вопрос о пути нажмите Enter, затем задайте парольную фразу. В папке ~/.ssh появятся файлы id_ed25519 (закрытый) и id_ed25519.pub (открытый). Длина ключа Ed25519 фиксирована: 256 бит.
2. Покажите открытый ключ. Команда cat ~/.ssh/id_ed25519.pub выведет одну строку, начинающуюся с ssh-ed25519.
3. Скопируйте ключ на сервер. Выполните ssh-copy-id user@192.0.2.10 и введите пароль пользователя. Команда подключается к порту 22; если порт другой, добавьте ключ -p, например ssh-copy-id -p 2222 user@192.0.2.10.
4. Добавьте ключ вручную, если ssh-copy-id нет. Войдите на сервер по паролю и выполните mkdir -p ~/.ssh и chmod 700 ~/.ssh. Затем допишите строку из шага 2 в файл: echo "ssh-ed25519 AAAA... имя@ноутбук" >> ~/.ssh/authorized_keys. Завершите командой chmod 600 ~/.ssh/authorized_keys.
5. Проверьте вход. Откройте новое окно терминала и выполните ssh user@192.0.2.10. Старую сессию держите открытой, пока не убедитесь, что вход работает.
6. Убедитесь, что пароль не нужен. Сервер не должен спрашивать пароль пользователя. Если вы задали парольную фразу, запрашивается только она, и это нормально. Пароль на сервере отключайте только после этой проверки.

Формат строки и параметры в authorized_keys

Каждая строка в файле ~/.ssh/authorized_keys — один открытый ключ. Формат: [параметры] тип-ключа base64-ключ [комментарий]. Для Ed25519 (256 бит) запись выглядит так: ssh-ed25519 AAAAC3Nz... имя@ноутбук. Это тип ключа, текст в кодировке base64 длиной около 70 символов и комментарий, по которому вы узнаете владельца.

Ключ должен занимать ровно одну строку без переносов. Если редактор разорвал base64-текст, служба sshd (серверная часть SSH) не прочитает запись. Пустые строки и строки, начинающиеся с #, допустимы, так что под заметки их можно использовать свободно.

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

• from="198.51.100.7" — пускает только с указанного IP-адреса (Internet Protocol); подойдёт и подсеть, например 198.51.100.0/24;
• command="..." — выполняет только заданную команду, любая другая игнорируется;
• no-port-forwarding — запрещает проброс портов;
• restrict — одним словом отключает проброс, терминал и другие дополнительные возможности.

Безопасный пример для резервного копирования с машины 198.51.100.7:

from="198.51.100.7",restrict,command="/usr/local/bin/backup.sh" ssh-ed25519 AAAAC3Nz... backup@server

Даже если такой ключ украдут, он не откроет оболочку и не сработает с чужого адреса.

Права доступа и настройка sshd_config

Служба sshd (SSH daemon, серверная часть SSH) отклоняет ключ, если права на файлы слишком открыты. Владелец ~/.ssh и authorized_keys должен быть сам пользователь. Папке ~/.ssh нужны права 700, файлу authorized_keys — 600, а домашняя папка не должна разрешать запись группе и остальным. Исправьте всё тремя командами: chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys и chmod go-w ~.

Параметры входа лежат в /etc/ssh/sshd_config. Убедитесь, что там есть PubkeyAuthentication yes и AuthorizedKeysFile .ssh/authorized_keys. Когда ключ заработает, добавьте PasswordAuthentication no, и подбор паролей на порту 22 перестанет работать.

Отключайте пароль в таком порядке:

1. Оставьте первую сессию открытой и откройте вторую: ssh user@192.0.2.10.
2. Убедитесь, что вход по ключу прошёл без запроса пароля.
3. В первой сессии поставьте PasswordAuthentication no в /etc/ssh/sshd_config.
4. Перезагрузите службу: sudo systemctl reload ssh на Debian и Ubuntu, sudo systemctl reload sshd на AlmaLinux.
5. Откройте третье окно и снова проверьте вход.

Как дополнительную защиту настройте Fail2ban: он блокирует адреса после нескольких неудачных попыток входа.

Частые ошибки с authorized_keys и как их исправить

Почти все сбои входа по ключу заканчиваются сообщением Permission denied (publickey). Чаще всего причина в одном из пяти мест: права на файлы, не тот пользователь, испорченная строка ключа, настройка sshd_config или SELinux. Примеры ниже используют сервер 192.0.2.10 и пользователя user.

Начните с диагностики. На клиенте запустите ssh -v user@192.0.2.10, а на сервере откройте журнал: /var/log/auth.log на Debian и Ubuntu или journalctl -u sshd -n 50 на AlmaLinux.

Permission denied (publickey): как читать вывод ssh -v

Сообщение значит, что сервер отклонил все предложенные ключи. В выводе ssh -v ищите такие строки:

• Offering public key — клиент предлагает ключ; если строки нет, ключ не найден в ~/.ssh.
• Authentications that can continue: publickey — сервер ждёт вход по ключу.
• No more authentication methods to try — ключ не принят; причину ищите в журнале сервера.

Слишком открытые права на ~/.ssh или файл

Если папка или файл доступны другим пользователям, sshd отклоняет ключ. В журнале это строка bad ownership or modes. Выполните chmod 700 ~/.ssh и chmod 600 ~/.ssh/authorized_keys.

Ключ добавлен не тому пользователю

Строка лежит в /home/admin/.ssh/authorized_keys, а вход идёт под user. Добавьте ключ в файл того пользователя, под которым подключаетесь, например командой ssh-copy-id user@192.0.2.10.

Вставлен закрытый ключ или строка разбита переносом

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

В sshd_config отключён PubkeyAuthentication

Откройте /etc/ssh/sshd_config и проверьте, что там не стоит PubkeyAuthentication no. Замените на yes и перезапустите службу: ssh на Debian и Ubuntu, sshd на AlmaLinux.

AlmaLinux и SELinux

SELinux (Security-Enhanced Linux) проверяет контекст файлов, и ключ, скопированный вручную, может получить неверную метку. Выполните restorecon -R ~/.ssh под нужным пользователем.

В 90% случаев ключ не принимают из-за прав или не того пользователя, поэтому проверяйте их первыми. Если не помогло, прочитайте последние 50 строк журнала: сервер почти всегда называет причину прямо.

Как управлять ключами: несколько серверов, отзыв доступа и когда ключи не подходят

Создавайте отдельную пару ключей на каждое устройство: ноутбук, рабочий компьютер, телефон. В комментарии строки в authorized_keys указывайте владельца и устройство, например имя@ноутбук. Через полгода вы сразу поймёте, какую строку оставить, а какую убрать.

Чтобы отозвать доступ, удалите строку ключа из ~/.ssh/authorized_keys. Перезапускать службу не нужно: новое подключение с этим ключом сервер отклонит сразу. Уже открытую сессию закройте отдельно. Если на сервере работают несколько пользователей, у каждого свой файл в его домашней папке, а ключ действует только для этой учётной записи.

В Windows OpenSSH (встроенный SSH-сервер) ключи администраторов лежат не в профиле, а в C:\ProgramData\ssh\administrators_authorized_keys. Обычным пользователям подходит файл в их папке .ssh.

Ключи подходят не для каждой задачи. Вот что выбрать вместо них:

• Командный доступ: заведите каждому сотруднику отдельную учётку, а не один общий ключ. Так видно, кто что делал, и отзыв не ломает вход остальным.
• Большой парк серверов: когда машин десятки, вместо правки файлов на каждой используйте SSH-сертификаты с ограниченным сроком действия.
• Общий хостинг без SSH: файл authorized_keys там бесполезен, войти по ключу некуда.

Если вам нужен полный контроль над доступом, возьмите сервер с root-правами. Разберите, как выбрать VPS для работы с SSH-ключами.