Практическая защитная инструкция для AsyncSSH и ghsa-qr67-gv47-xwwh: как сопоставить runtime с официальной границей версий, провести один ограниченный обратимый тест и передать владельцу проверяемый результат без опасного payload.
Граница применимости AsyncSSH
Начинать нужно не с воспроизведения дефекта, а с применимости. Reviewed advisory ghsa-qr67-gv47-xwwh описывает отдельный механизм: подстановка имени пользователя в AuthorizedKeysFile могла разрешать путь за пределами ожидаемого каталога ключей. Зафиксированные package ranges: asyncssh: <= 2.23.0; first patched 2.23.1. Package manager, SBOM и lockfile показывают заявленную зависимость, но решение принимают по реально загруженному artifact: сохраняют версию, checksum или digest и команду получения этого значения. Если компонента нет, статус not-applicable. Если он найден, но путь не активен, ставят affected-unverified. Новая запись в lockfile при старом процессе означает patched-unverified. Backport признают только после сопоставления upstream change и сборочного происхождения. Дата обновления 2026-08-26 объясняет, почему карточка проверяется сейчас; она ничего не сообщает о конкретном сервере читателя.
Baseline и доказательства до изменения AsyncSSH
До обновления составляют короткий снимок: версию AsyncSSH, шаблон AuthorizedKeysFile, корень тестовых ключей, системного пользователя стенда, effective environment и аудит открытых файлов. Каждое поле получает значение fact, not-applicable или unknown; пустое поле не трактуется как безопасность. Отдельно сохраняют health, владельца остановки, допустимый resource budget, checksum конфигурации и обратимый план. Смешанные версии разбивают по процессам, контейнерам или узлам, потому что средняя версия скрывает старый runtime. В отчёт не переносят tokens, cookies, credentials, реальные адреса, содержимое пользовательских данных, приватные логи и домашние пути. Для этой темы baseline нужен, чтобы отличить механизм ghsa-qr67-gv47-xwwh от прежней ошибки настройки, proxy, cache или dependency drift. Если health уже красный, сначала закрывают прежний инцидент и не приписывают его текущему update.
Один ограниченный опыт для AsyncSSH
После обновления выполняют только заранее ограниченный опыт: в контейнере создать разрешённый файл ключа и отдельный canary вне корня, затем проверить безвредное имя с граничным символом подстановки без реального входа пользователя. Проверка проходит в disposable VM, контейнере, tempfs, копии базы или отдельном namespace в зависимости от продукта; общий production объект в неё не входит. Схема A/B/A2 обязательна: обычное действие A, один безопасный граничный случай B, затем повтор обычного действия A2. Между шагами не меняют одновременно dependency, права, network и storage. Ввод содержит только canary и не включает рабочий exploit, приватные сведения или чужой сервис. Ожидаемый исход записан до запуска: разрешённый путь читается по политике, граничное имя отклоняется до открытия canary, audit log не показывает доступ за пределами корня. Timeout, crash, необъяснимый 500, новый побочный объект или потеря health — не подтверждение исправления, а failed-safe-check.
Матрица решения по ghsa-qr67-gv47-xwwh
Результат оценивают по наблюдаемой границе, а не по отсутствию exception. Для AsyncSSH passed-bounded-check допустим только когда разрешённый путь читается по политике, граничное имя отклоняется до открытия canary, audit log не показывает доступ за пределами корня. В строке решения должны совпасть artifact digest, активность функции, A/B/A2, health после cleanup и версия из официальной границы. Контролируемый отказ должен соответствовать механизму advisory: validation, authorization, bounds, resource limit или protocol policy. Пустой ответ, ручная правка после B, старый процесс при новом файле или различие между узлами оставляют unknown. Статусы ограничены набором not-applicable, update-required, patched-unverified, passed-bounded-check, failed-safe-check и unknown. Даже passed относится только к указанной конфигурации и времени; он не является общей оценкой безопасности AsyncSSH и не заменяет дальнейший мониторинг.
Стоп-линия, возврат и пакет владельцу AsyncSSH
Проверку прекращают сразу, если нужно использовать реальную учётную запись, домашний каталог администратора или менять системный sshd. После стопа не повышают нагрузку, права, глубину входа или длительность. Запланированный возврат: удалить контейнер и canary, вернуть исходный шаблон AuthorizedKeysFile и подтвердить обычную проверку тестового ключа. Cleanup считается завершённым после повторного baseline, нулевого diff вне тестового объекта и закрытия временных sessions, listeners, handles, processes или credentials. Владельцу передают только минимизированный пакет: версия AsyncSSH, нормализованный шаблон, корень стенда, класс отказа, список открытых путей без содержимого и digest контейнера. Добавляют время, ожидаемый и фактический исход, две прямые ссылки ниже и ответственного за cleanup. Полные дампы, секреты, реальные payload и сведения о чужой инфраструктуре исключают. Материал описывает безопасный путь проверки; он не утверждает, что тест уже выполнен на системе читателя, и не обещает отсутствие других дефектов, индексацию страницы или поисковые позиции.
Таблица разрешения пути именно для AsyncSSH
Для AsyncSSH полезно не смешивать четыре разных уровня: исходный шаблон AuthorizedKeysFile, подставленное имя, нормализованный абсолютный путь и фактически открытый файловый дескриптор. В стендовой таблице каждая строка содержит эти четыре значения и итог allow или deny. Разрешённый контрольный пользователь должен привести к файлу внутри выделенного key root. Граничное имя проверяется только как строка и не должно приводить к открытию canary за root; содержимое canary не читают. Отдельно фиксируют, кто выполняет expansion: приложение, оболочка или файловая система, потому что одинаковая строка при разных исполнителях имеет разные границы. Audit события связывают с одним correlation ID, затем убеждаются, что descriptor для внешнего пути не возникал. Если путь выглядит безопасным в логе, но syscall trace показывает другое, приоритет получает syscall evidence и статус остаётся failed-safe-check. Такая матрица отвечает именно на вопрос подстановки AuthorizedKeysFile и не переносится на общий SSH login, права ключа или настройку системного sshd.
Материал подготовлен редакцией VOne с помощью ИИ по открытым официальным и первичным источникам; факты, даты, версии и ссылки перепроверены. Реальные пользовательские данные, активные опасные payload и вымышленные результаты тестов не использовались.
Источники и проверка
- GitHub Advisory Database GHSA-qr67-gv47-xwwh по AsyncSSH проверено 2026-08-30
- Прямая upstream-страница AsyncSSH проверено 2026-08-30
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.