Может ли агент войти с отозванным SSH-ключом хоста?

Отозванный SSH-ключ хоста должен остановить агента до аутентификации пользователя независимо от имени или адреса. Если тест лишь один раз подключается по привычному имени хоста, он доказывает намного меньше, чем кажется. Конфигурация SSH может сопоставлять одному серверу несколько имен, нестандартный порт меняет идентификатор поиска в known-hosts, а клиент с мультиплексированием открывает новый канал без повторной проверки ключа хоста.

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

Отзыв должен следовать за ключом, а не за именем хоста

Ключ хоста аутентифицирует сервер во время обмена ключами SSH. В RFC 4253 описано, как клиент получает открытый ключ сервера, проверяет его принадлежность нужному серверу и подпись сервера над данными обмена. Отзыв должен срабатывать именно здесь: если сервер предъявляет запрещенный открытый ключ, клиент обязан отвергнуть его до проверки пользовательского ключа, пароля или удаленной команды.

OpenSSH предлагает два похожих механизма с разным охватом. Строка с маркером @revoked в файле known-hosts связывает шаблон хоста с отозванным ключом. Она срабатывает, когда имя поиска для соединения совпадает с этой строкой. Псевдоним или другая форма адреса может не совпасть с шаблоном, хотя сервер предъявит тот же ключ. В руководстве OpenSSH по sshd сказано, что совпавшую отозванную запись нельзя принимать, но условие совпадения здесь принципиально.

Клиентская настройка RevokedHostKeys лучше подходит для отзыва при инциденте. Она указывает на текстовый файл с открытыми ключами или на список отзыва ключей OpenSSH (KRL). OpenSSH сравнивает предъявленную идентичность с этим файлом независимо от того, ввел пользователь build-test, build-test.example или IP-адрес. Я применяю @revoked для адресных записей known-hosts; когда криптографическую идентичность нужно запретить везде, применяю RevokedHostKeys.

Не путайте эти механизмы с StrictHostKeyChecking=yes. Строгая проверка отклоняет неизвестные хосты и измененные ключи, поэтому доверие при первом подключении не возникает без подтверждения. Она не объявляет отозванным ключ, которому клиент в остальных случаях доверяет. Тест, который удаляет старую запись known-host и радуется отказу для неизвестного хоста, проверяет пустую базу доверия, а не отзыв.

Создайте тестовый хост, который можно намеренно сломать

Используйте одноразовый SSH-сервер с отдельным портом, ключом хоста, учетной записью и каталогом клиента. Не репетируйте отзыв на общем стенде. Вам придется менять ключи, останавливать процессы и закрывать управляющие сокеты, не выясняя, кто еще от них зависит.

Следующая структура хранит доказательства в одном каталоге. Точный путь к sshd и модель прав зависят от операционной системы, поэтому запускайте демон в контейнере, виртуальной машине или тестовой оснастке, которую команда уже использует для интеграционных тестов SSH.

set -eu
work="$PWD/ssh-revocation-fixture"
mkdir -p "$work/client" "$work/server"
chmod 700 "$work/client"

ssh-keygen -q -t ed25519 -N '' \
  -C revoked-host-test -f "$work/server/ssh_host_ed25519_key"
ssh-keygen -q -t ed25519 -N '' \
  -C agent-test-user -f "$work/client/id_ed25519"

ssh-keygen -lf "$work/server/ssh_host_ed25519_key.pub"

Последняя команда выводит строку такой формы:

256 SHA256:<base64-fingerprint> revoked-host-test (ED25519)

Запишите отпечаток в журнал теста. Не копируйте отпечаток из заявки, предполагая, что файл в оснастке содержит тот же ключ. Вычисляйте его из файла открытого ключа, который тестовый сервер действительно загружает.

Настройте демон так, чтобы он использовал только этот ключ хоста. Поместите открытый ключ клиента в AuthorizedKeysFile, отключите пароли и привяжите сервер к loopback-адресу или изолированной сети. В минимальной оснастке также нужны явный PidFile и подробное журналирование. Нам нужен повторяемый результат: один слушатель, одна идентичность хоста и один путь аутентификации.

До добавления отзыва выполните одно успешное строгое подключение и безопасную команду-маркер, например printf BASELINE_OK. Получите ключ хоста через аутентифицированный процесс подготовки, а не через непроверенный ssh-keyscan по тому же сетевому пути, который собираетесь защищать. ssh-keyscan получает ключи, но не доказывает, кто их предоставил.

Добавьте отозванную идентичность в KRL

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

work="$PWD/ssh-revocation-fixture"
ssh-keygen -k -f "$work/client/revoked-hosts.krl" \
  "$work/server/ssh_host_ed25519_key.pub"

if ssh-keygen -Q -f "$work/client/revoked-hosts.krl" \
  "$work/server/ssh_host_ed25519_key.pub"; then
  printf '%s\n' 'FAIL: fixture host key is not revoked'
  exit 1
else
  printf '%s\n' 'OK: fixture host key is revoked'
fi

Обратный смысл кода возврата часто сбивает с толку. Руководство ssh-keygen определяет, что -Q возвращает ненулевой код, если хотя бы один проверяемый ключ отозван или возникла ошибка; ноль означает, что отозванных ключей нет. Не отбрасывайте stderr и различайте в журнале нечитаемый KRL и правильное совпадение с отзывом.

Теперь подключите файл к клиентской конфигурации на самом широком уровне, который использует агент:

Host *
    BatchMode yes
    StrictHostKeyChecking yes
    UserKnownHostsFile ./ssh-revocation-fixture/client/known_hosts
    RevokedHostKeys ./ssh-revocation-fixture/client/revoked-hosts.krl
    ConnectTimeout 5
    ConnectionAttempts 1

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

Подойдет и простой текстовый файл с одним открытым ключом в строке. Сложность KRL оправдана при множестве ключей или сертификатов хоста, поскольку он умеет отзывать обычные ключи, серийные номера, идентификаторы сертификатов и ключи, подписанные CA. Выберите самый простой формат, который умеют распространять и проверять ваши процессы, затем тестируйте именно развернутый формат.

Маркер по имени хоста требует проверки с обходом

Оставьте в оснастке один намеренно слабый случай, чтобы показать необходимость KRL. Создайте вторую конфигурацию клиента без RevokedHostKeys, которая полагается только на такую запись known-hosts:

@revoked revoked-lab ssh-ed25519 AAAA...fixture-public-key...

Подключитесь как revoked-lab и подтвердите, что OpenSSH отклоняет совпавшую запись. Затем подключитесь к тому же слушателю как 127.0.0.1, имея отдельную доверенную запись known-host для [127.0.0.1]:2222. Если такая форма адреса сработала, оснастка воспроизвела пробел в охвате: ключ не менялся, но имя поиска больше не совпало с маркером отзыва. Держите эту демонстрацию отдельно от рабочей конфигурации, ведь ее задача состоит в доказательстве недостаточности контроля.

Не вставляйте сокращенное значение AAAA... из примера. Стройте маркер из настоящего файла открытого ключа, чтобы алгоритм и данные base64 совпадали точно. Безопасная команда оснастки может прочитать поля алгоритма и ключа из открытого файла, затем добавить перед ними маркер и шаблон хоста. Проверьте запись командой ssh-keygen -F revoked-lab -f known_hosts; повторите поиск для буквального адреса и покажите отсутствие записи.

Этот отказ объясняет, почему добавлять все известные псевдонимы в строку @revoked ненадежно. Список меняется при добавлении короткого имени, записи DNS, локальной записи hosts, нестандартного порта, псевдонима туннеля или HostKeyAlias. Хешированные имена known-host усложняют ручную проверку, хотя ssh-keygen -F умеет искать их. Шаблон со звездочкой расширяет совпадение, но отзывает ключ только для попавшего в шаблон адреса и затрудняет проверку задуманного охвата.

Случай с KRL должен использовать тот же сервер, пользовательский ключ, сетевой путь и доверенные записи known-host. Меняйте только механизм отзыва. При активном RevokedHostKeys и revoked-lab, и 127.0.0.1 должны получить отказ после предъявления ключа оснастки. Парный эксперимент превращает абстрактное предупреждение о псевдонимах в видимую и повторяемую ошибку.

Проверьте также приоритет настроек. OpenSSH сохраняет первое полученное значение параметра, поэтому ранняя настройка конкретного хоста может нейтрализовать более позднее значение по умолчанию. Выполните ssh -G для каждого адреса и побайтно сравните полученный путь revokedhostkeys. Простое наличие слова RevokedHostKeys где-то в файле еще не доказывает, что агент его использует.

Системная и пользовательская конфигурации создают еще одно расхождение. У инженера /etc/ssh/ssh_config может указывать на корпоративный KRL, а агент запускается через ssh -F private-config, что заставляет OpenSSH читать другой файл. Возможен и обратный случай: чистая учетная запись CI проходит тест, но не моделирует рабочий раннер, который добавляет параметры в командной строке. Сохраните полный вызов на границе действий агента и явно укажите там путь отзыва.

Права входят в критерии приемки. По руководству OpenSSH ошибка чтения RevokedHostKeys запрещает аутентификацию всех хостов. До подключения проверьте файл от имени системного пользователя агента и запросите нужный ключ. Так различаются три результата, каждый из которых выглядит как неудачная команда SSH: правильное совпадение с отзывом, отсутствующий или нечитаемый файл и поврежденный KRL.

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

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

Запись приемки для одной отозванной идентичности должна содержать отпечаток, алгоритм открытого ключа, хеш KRL, проверенные формы адреса, эффективную конфигурацию каждой формы и результат нового обмена. Результат для мультиплексированного сеанса добавляйте отдельно, поскольку он отвечает на другой вопрос. Тогда проверяющий отличит ошибку сопоставления идентичности от пробела маршрута, конфигурации, распространения или очистки транспорта.

Новое подключение должно отказать до запуска маркера

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

work="$PWD/ssh-revocation-fixture"
config="$work/client/config"
log="$work/client/direct.stderr"

set +e
ssh -F "$config" \
  -o ControlMaster=no -o ControlPath=none \
  -i "$work/client/id_ed25519" \
  -p 2222 [email protected] \
  'printf REVOKED_KEY_EXECUTED' \
  >"$work/client/direct.stdout" 2>"$log"
rc=$?
set -e

if [ "$rc" -eq 0 ]; then
  printf '%s\n' 'FAIL: SSH accepted a revoked host identity'
  exit 1
fi
if grep -q REVOKED_KEY_EXECUTED "$work/client/direct.stdout"; then
  printf '%s\n' 'FAIL: remote sentinel ran'
  exit 1
fi
printf 'PASS rc=%s\n' "$rc"

Проверяйте результат, а не точную английскую строку ошибки. Версии OpenSSH и операционные системы могут по-разному формулировать диагностику. При отказе сохраните подробный вывод повторного запуска с -vv и найдите предъявленный отпечаток вместе с сообщением об отзыве. Тайм-аут TCP, закрытый порт, неизвестный хост, отсутствующий пользовательский ключ или запрещенная учетная запись тоже дают ненулевой код, но не доказывают, что соединение остановил отзыв ключа хоста.

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

Выполните контрольный случай с пустым читаемым KRL или другим неотозванным ключом сервера. Соединение должно дойти до BASELINE_OK. Негативный тест без положительного контроля часто проходит из-за заранее сломанных DNS, маршрута, прав или учетной записи оснастки.

Для каждого псевдонима и вида адреса нужен свой случай

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

Начните с небольшой матрицы для оснастки:

1. Настроенный псевдоним, например revoked-lab, чей HostName указывает на тестовый адрес.
2. Полное доменное имя и любое короткое имя, разрешенное локальными правилами.
3. Буквальный IPv4-адрес и, если слушатель его поддерживает, IPv6-адрес.
4. Токен known-host для нестандартного порта, обычно записанный как [host]:port.
5. Псевдоним с HostKeyAlias, поскольку эта настройка заменяет настоящее имя при поиске ключей и проверке сертификатов хоста.

Храните варианты в файле данных или тестовой функции, не копируя блок shell. Для каждого видимого имени выполните ssh -G destination и сохраните значения hostname, port, hostkeyalias, userknownhostsfile, revokedhostkeys, proxycommand, proxyjump, controlmaster и controlpath. ssh -G раскрывает конфигурацию без соединения и ловит секцию Host, которая незаметно подменяет путь KRL.

Hostname и HostKeyAlias решают разные задачи. Hostname выбирает сетевой адрес. HostKeyAlias выбирает имя, по которому OpenSSH читает или сохраняет ключи и проверяет сертификаты. Ни одна настройка не должна ослаблять глобальную проверку RevokedHostKeys, но обе могут менять выбранную доверенную запись known-host. Поэтому ограниченная именем строка @revoked плохо подходит для контроля инцидента.

Если включена канонизация, ей нужен отдельный случай. CanonicalizeHostname yes может дописывать настроенные домены и заставляет OpenSSH повторно обработать конфигурацию с измененной целью. Более поздняя секция способна выбрать другой файл known-hosts или пропустить файл отзыва. Проверьте короткий ввод и полученное каноническое имя, затем подтвердите одинаковый KRL в обеих эффективных конфигурациях.

Не считайте CheckHostIP=yes покрытием псевдонимов. Руководство OpenSSH говорит, что он дополнительно проверяет IP в known-hosts и недоступен при подключении через proxy command. Он обнаруживает измененную связь, но не заменяет отзыв по ключу. Маршруты через прокси и переход требуют сквозной проверки конечной цели и отдельной настройки доверия для каждого промежуточного хоста.

Кешированные соединения задают границу реакции на инцидент

Активное мультиплексированное мастер-соединение SSH уже аутентифицировало сервер. Новый сеанс через управляющий сокет не создает новое TCP-соединение и не повторяет обмен ключом хоста, поэтому только что установленный KRL не может задним числом отклонить ключ. Называть это обходом отзыва неточно. Здесь повторно используется еще живой аутентифицированный транспорт.

Докажите такое поведение в оснастке, не предполагая, что перезапуск все очистит. Сначала откройте мастер-соединение, пока ключ разрешен. Сохраните его через ControlPersist, добавьте ключ в KRL и покажите, что ssh -O check по-прежнему находит мастер. Команда через этот сокет может выполниться. Запишите это как ожидаемый контроль до исправления, а не как успешный результат отзыва.

Затем проведите реакцию: запретите агенту начинать новую работу, завершите соответствующие мастер-соединения и отзовите или остановите владеющий ими сеанс агента. Для отдельного сокета оснастки локальная команда выглядит так:

socket="$PWD/ssh-revocation-fixture/client/cm-testuser-127.0.0.1-2222"
ssh -S "$socket" -O exit [email protected]

После исчезновения сокета повторите соединение с ControlMaster=no и ControlPath=none; оно должно отказать на отозванном ключе. После очистки проверьте обычную конфигурацию мультиплексирования агента. Оппортунистические режимы вроде ControlMaster auto при отсутствии мастера переходят к новому соединению, и оно обязано проверить KRL.

Устаревший файл сокета не равен аутентифицированному соединению. OpenSSH попробует сокет, обнаружит отсутствие слушающего мастера и может перейти к обычному подключению. Оставьте этот случай в наборе, потому что после сбоев остаются старые файлы. Безопасным результатом остается отказ на новом обмене.

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

Сервер может предъявлять несколько идентичностей

Серверы часто загружают несколько ключей хоста либо сертификат вместе с исходным ключом. Отзыв одного отпечатка не обязательно делает узел недоступным. Во время согласования клиент и сервер выбирают общий алгоритм ключа; другой доверенный и неотозванный ключ может аутентифицировать тот же сервер.

Определите смысл заявления об инциденте. Если утек один закрытый ключ хоста, клиент обязан отклонять его, а другой независимо защищенный ключ после проверки может остаться допустимым. Если нарушена целостность машины, отзовите все идентичности, которые она предъявляет, включая сертификаты, и снимите доверие до перестройки. Фраза «хост отозван» в заявке без списка идентичностей оставляет решение согласованию алгоритмов.

Составляйте инвентарь по конфигурации демона и доверенным записям, а не по одному сканированию. Протестируйте каждый включенный алгоритм, ограничив HostKeyAlgorithms исследуемым вариантом. Отозванный ключ должен получить отказ. Для каждой оставленной идентичности нужен положительный случай и записанный отпечаток.

Сертификаты хоста добавляют различие. Можно отозвать сертификат как открытый объект, его серийный номер или ID в KRL либо CA, который разрешает целый класс хостов. У вариантов разный охват. Руководство ssh-keygen описывает директивы KRL для серийных номеров, ID, открытых ключей и отпечатков; проверяйте готовый KRL точным файлом сертификата, предъявляемым сервером.

Внимания требует и UpdateHostKeys. OpenSSH умеет узнавать дополнительные ключи сервера после аутентификации уже доверенным обычным ключом. Это помогает при плановой ротации, но ранее изученные альтернативы остаются кандидатами, если решение об отзыве их не охватило. Выведите записи клиента командой ssh-keygen -F для каждого имени и формы [name]:port, затем сопоставьте каждый открытый ключ с областью инцидента.

Запускайте негативный тест по настоящему пути агента

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

Возвращайте структурированные доказательства для каждого варианта: метку цели, разрешенные имя и порт, предъявленный отпечаток, хеш KRL, состояние совместного соединения, код возврата, появление маркера и этап закрытия попытки сервером. Не включайте секреты. Полезная проверка проста: отозванная идентичность предъявлена, клиент распознал отзыв, после чего не было аутентификации пользователя или команды.

Изоляция среды выявляет случайные зависимости. Явно задайте путь конфигурации SSH, known-hosts, KRL, файл идентичности и управляющий путь. Очистите или замените SSH_AUTH_SOCK, если агент не должен брать чужие ключи. Ограничьте время, чтобы CI не зависал. При отказе сохраняйте stderr и журналы сервера; успешный отчет может хранить их хеши и решающие строки.

Если агенты выполняют SSH через Sallyport, пройдите этим путем и в негативном тесте: встроенный stateless-помощник sp-ssh выполняет SSH-действия, а журналы Sessions и Activity записывают запуск агента и отдельный вызов. Если тест также проверяет целостность доказательств, проверьте цепочку офлайн через sp audit verify; отказ ключа все равно должен исходить из конфигурации доверия SSH, которую использовало реальное действие.

Не ослабляйте клиент ради автоматизации. StrictHostKeyChecking=no, пустой known-hosts или отправка диагностики в /dev/null превращают тест безопасности в проверку доступности. BatchMode=yes убирает запросы, но не заменяет отсутствующие материалы доверия.

Тест отзыва должен падать только по одной причине

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

Отклоняйте сборку, если любая цель доходит до маркера, любая эффективная конфигурация не содержит обязательного файла отзыва или сервер предлагает неклассифицированную идентичность. Неопределенный запуск тоже должен падать. Тайм-аут или нечитаемый KRL означают сломанный тест, хотя SSH вернул ненулевой код.

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

Запускайте набор в процессе агента без возможности показать запрос. Диалог одобрения, запрос пароля или подтверждение хоста может ждать до общего тайм-аута и скрыть причину. BatchMode=yes должен немедленно закрывать эти пути, а положительный контроль подтверждает отсутствие интерактива в оснастке. Ограничьте внешнюю задачу жестким тайм-аутом, но не считайте его доказательством отзыва.

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

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