authorized_keys

Почему права доступа к файлу важны

SSH молча откажется использовать файл authorized_keys или директорию .ssh, содержащую его, если права доступа слишком открытые. Это специальная защита от ситуации, когда неправильно настроенный сервер позволяет любому локальному пользователю добавить себе ключ для скрытого доступа.

Частый источник забытого доступа

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

Как проверять ключи и ужесточать доступ по SSH, описано здесь: руководство по усилению защиты SSH.

Ограничьте, что может делать каждый ключ

Строка в authorized_keys может содержать параметры перед типом ключа, и они позволяют дать ключу меньше полномочий, чем полноценный вход. Они перечислены в руководстве sshd. restrict включает сразу все ограничения: отключает перенаправление портов, агента и X11, выделение терминала и скрипт пользователя ~/.ssh/rc, а также ограничения, которые появятся в будущих версиях. Затем вы включаете обратно только то, что нужно ключу. from="..." принимает ключ только с подходящих имён хостов или адресов, поддерживается запись CIDR. command="..." принудительно запускает одну команду при каждом использовании ключа и игнорирует то, что запросил клиент.

restrict,from="203.0.113.0/24",command="/usr/local/bin/run-backup" ssh-ed25519 AAAA... backup@nas

Параметры разделяются запятыми без пробелов, а ключ идёт после пробела. Такой шаблон подходит для автоматизации, например для выгрузки резервных копий и задач развёртывания: если ключ утечёт, он сможет выполнить только одну задачу из одной сети, а не открыть оболочку. Исходная команда клиента доступна вашему скрипту в SSH_ORIGINAL_COMMAND, поэтому проверяйте её, а не передавайте в оболочку. Учтите, что ForceCommand в sshd_config может переопределить команду ключа. Ограничения на уровне ключа это практичный способ применить минимальные привилегии к служебным ключам.

Как провести аудит ключей на сервере

Начните с вопроса, кому вход действительно разрешён. В актуальном OpenSSH ssh-keygen -lf, направленный на файл authorized_keys, печатает по строке на ключ с отпечатком и комментарием, что можно сверить со списком выданных ключей:

sudo ssh-keygen -lf /home/alice/.ssh/authorized_keys
sudo sh -c 'ls -l /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys'
sudo sshd -T | grep -i authorizedkeysfile

Считайте комментарий меткой, а не доказательством: любой может написать там что угодно, поэтому ключ определяет отпечаток. Проверьте каждую учётную запись, включая root, и посмотрите значение из последней команды. Согласно руководству sshd_config, по умолчанию это .ssh/authorized_keys .ssh/authorized_keys2, поэтому забытый второй файл тоже может содержать ключи. В том же руководстве сказано, что StrictModes по умолчанию yes, и sshd отказывается использовать файлы со слишком открытыми правами.

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

Связанные термины: Аутентификация по ключу, SSH, sshd_config, UID 0, ssh-copy-id (установка ключа на сервер), ssh-keygen (создание ключей OpenSSH).

В новостях: CVE-2026-35414 это недавний обход OpenSSH, связанный именно с тем ограничением principals в authorized_keys, которое описывает этот термин.