Настройка доступа на Linux сервер по SSH ключам
Файл authorized_keys используется OpenSSH для хранения публичных SSH-ключей, которым разрешён вход от имени конкретного пользователя. Обычно он находится в ~/.ssh/authorized_keys: например, /root/.ssh/authorized_keys для root или /home/admin/.ssh/authorized_keys для пользователя admin.
Формат authorized_keys #
Каждый ключ занимает отдельную строку и имеет формат:
[options] key-type public-key [comment]
Пример:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF... admin@laptop
| Поле | Назначение |
|---|---|
options |
Необязательные ограничения ключа |
key-type |
Тип ключа, например ssh-ed25519 или ssh-rsa |
public-key |
Публичный ключ в Base64 |
comment |
Произвольный комментарий для администратора |
Наиболее распространённые типы ключей: ssh-ed25519, ssh-rsa, ECDSA и аппаратные FIDO-ключи.
Комментарий не участвует в аутентификации и нужен только для удобства администратора. Если при генерации ключа через ssh-keygen комментарий явно не указан параметром -C, OpenSSH по умолчанию создаёт его в формате user@host, например root@ubuntu. Комментарий можно задать при генерации командой ssh-keygen -t ed25519 -C "admin-laptop" или изменить позже с помощью ssh-keygen -c.
Несколько ключей на одну учётную запись #
На одного Linux-пользователя можно добавить несколько SSH-ключей: например, для ноутбука администратора, рабочей станции, CI/CD или backup-сервера. Каждый ключ располагается на отдельной строке:
ssh-ed25519 AAAAC3... admin-laptop
ssh-ed25519 AAAAC3... admin-workstation
ssh-ed25519 AAAAC3... backup-server
Все эти ключи дают доступ к одной и той же учётной записи. Чтобы отозвать доступ только для одного устройства, достаточно удалить соответствующую строку — остальные ключи продолжат работать. Порядок строк не задаёт приоритет: SSH-клиент предлагает серверу доступные ключи, а sshd проверяет, разрешён ли конкретный предложенный ключ.
В каком порядке sshd проверяет ключи #
Практически процесс выглядит так:
| Этап | Что происходит |
|---|---|
| 1 | Клиент подключается и передаёт имя пользователя |
| 2 | SSH-клиент предлагает публичный ключ |
| 3 | sshd проверяет, разрешена ли аутентификация по ключам |
| 4 | Сервер ищет предложенный ключ в AuthorizedKeysFile |
| 5 | Проверяются options ключа: from, expiry-time, restrict и другие |
| 6 | Если ключ разрешён, сервер проверяет криптографическую подпись клиента |
| 7 | При успешной проверке аутентификация завершается |
Если предложенный ключ не подходит, клиент может предложить следующий. Сервер не перебирает приватные ключи и не пытается «войти каждым ключом из authorized_keys» — он сравнивает предлагаемые клиентом публичные ключи со списком разрешённых.
Пути к файлам задаются параметром AuthorizedKeysFile в конфигурации sshd. Проверить фактически применяемое значение:
sshd -T | grep authorizedkeysfile
Срок действия SSH-ключа #
Для строки в authorized_keys можно использовать option expiry-time, после указанного времени ключ перестанет приниматься сервером.
Например, ключ действует до 31 декабря 2026 года:
expiry-time="20261231" ssh-ed25519 AAAAC3... contractor
До 31 декабря 2026 года 18:00:
expiry-time="202612311800" ssh-ed25519 AAAAC3... contractor
В UTC:
expiry-time="202612311800Z" ssh-ed25519 AAAAC3... contractor
Это удобно для временного доступа подрядчиков, миграций и сервисных работ: строку можно оставить в файле, но после указанного времени sshd перестанет принимать этот ключ. Если в инфраструктуре используются SSH-сертификаты, срок действия можно задавать непосредственно при выпуске сертификата.
Ограничения ключа #
Перед ключом можно задавать options через запятую без пробелов:
from="10.10.10.0/24",expiry-time="20261231",no-port-forwarding ssh-ed25519 AAAAC3... admin
| Option | Назначение |
|---|---|
from="10.10.10.0/24" |
Разрешить ключ только с указанного IP или сети |
expiry-time="20261231" |
Запретить использование после указанной даты |
restrict |
Запретить forwarding, PTY и ряд дополнительных возможностей |
command="/path/script.sh" |
Всегда запускать указанную команду |
no-port-forwarding |
Запретить TCP forwarding |
no-agent-forwarding |
Запретить Agent Forwarding |
no-X11-forwarding |
Запретить X11 Forwarding |
no-pty |
Запретить интерактивный терминал |
permitopen="host:port" |
Разрешить forwarding только к определённому адресу |
Пример временного административного ключа только из внутренней сети:
from="192.168.10.0/24",expiry-time="20261001" ssh-ed25519 AAAAC3... temporary-admin
Сервисный ключ без полноценного интерактивного доступа:
command="/usr/local/bin/backup.sh",restrict ssh-ed25519 AAAAC3... backup-server
Права доступа #
Типичные права:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
Проверить владельца и права:
ls -ld ~/.ssh
ls -l ~/.ssh/authorized_keys
При необходимости:
chown -R user:user /home/user/.ssh
Если права или владелец небезопасны, sshd при стандартном StrictModes yes может отказаться использовать authorized_keys.
Добавление и удаление ключей #
Добавить ключ автоматически:
ssh-copy-id user@server
Или вручную:
cat id_ed25519.pub >> ~/.ssh/authorized_keys
Один ключ должен полностью находиться на одной строке. Удаление соответствующей строки отзывает доступ этого ключа для новых SSH-подключений.
Пример authorized_keys #
# Main administrator
from="192.168.10.0/24" ssh-ed25519 AAAAC3... admin-laptop
# Temporary administrator
from="192.168.10.0/24",expiry-time="20261001" ssh-ed25519 AAAAC3... contractor
# Backup server
command="/usr/local/bin/backup.sh",restrict ssh-ed25519 AAAAC3... backup-server
Краткая шпаргалка #
| Задача | Пример |
|---|---|
| Обычный ключ | ssh-ed25519 AAAAC3... admin |
| Несколько ключей | По одному ключу на каждой строке |
| Ограничение по IP | from="10.10.10.10" ... |
| Ограничение по сети | from="10.10.10.0/24" ... |
| Срок действия | expiry-time="20261231" ... |
| Ограниченный сервисный ключ | restrict ... |
| Только одна команда | command="/path/script.sh",restrict ... |
authorized_keys — это не просто список публичных SSH-ключей: для одной учётной записи можно использовать несколько независимых ключей и отдельно задавать каждому срок действия, допустимые IP-адреса и разрешённые возможности.
Это позволяет выдавать доступ конкретному устройству или сервису без создания отдельного Linux-пользователя.