OmegabcHost key SSH и ключ пользователя подтверждают разные стороны
Фотография конкретного исполнения не приложена.
Успешный вход по пользовательскому ключу не заменяет проверку сервера. Клиенту нужно знать, что он передаёт данные ожидаемому узлу. Общее наличие шифрования не отвечает на вопрос, чей именно transport endpoint установлен.
Архитектура SSH разделяет транспортную аутентификацию host и последующую user authentication. Host key относится к серверу, а public key пользователя участвует в другом этапе. Подтверждение одного ключа не является автоматическим подтверждением другого.
Основание доверия к host key должно соответствовать принятой процедуре: заранее известное соответствие, проверенный fingerprint или другой поддержанный механизм. Получение неизвестного ключа по тому же ещё не проверенному соединению само по себе не создаёт независимого доказательства личности узла.
В приёмке отдельно фиксируют результат проверки host и результат входа пользователя. Проверяют ожидаемый сервер и контролируемый случай другого ключа. Отчёт должен показывать обе границы доверия. Одно сообщение «publickey authentication succeeded» не подтверждает, что исходно был выбран и проверен именно требуемый сервер инфраструктуры.
Основание — Numbered SSH RFCs with historical base mechanics and scoped later extensions; not complete current cryptographic allowlist, разделы RFC4251 4 Architecture; host keys; RFC4252 Authentication protocol framework. Сохранён текст публичной справочной публикации; конкретная реализация может поддерживать только часть возможностей. Основание — указанные номерные RFC SSH. Базовые документы 2006 года используются для семантики протокола, а не как полный актуальный список разрешённых алгоритмов. Реальные версии клиента/сервера, ключи и политика доступа не проверялись; команды, подключения и forwarding не выполнялись.