Вопрос или проблема
У меня есть сервер, на котором sshd слушает нестандартный порт, например, 8022. Я пытался подписать его ключ хоста следующим образом:
ssh-keygen -s ibug_ca -I example -h -n '[example.com]:8022' ssh_host_rsa_key.pub
Затем я добавил это в sshd_config и выполнил команду systemctl reload ssh.service:
HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub
Теперь, когда я пытаюсь подключиться к серверу по SSH, используя ssh -p 8022 [email protected], клиент OpenSSH показывает следующее:
Certificate invalid: name is not a listed principal
The authenticity of host '[example.com]:8022 ([example.com]:8022)' can't be established.
Такого не происходит, когда я подписываю сертификат для сервера с портом SSH 22 (стандартный). Я уверен, что сделал все остальное правильно, потому что проделывал это много раз.
Как правильно подписать сертификат для нестандартного порта SSH?
Я не думаю, что номер порта следует учитывать, когда речь идет о сертификатах. Сертификаты (TLS или SSH) в основном зависят от идентичности. Одним из атрибутов идентичности является Common Name (CN), а другим — principal (как в случае сертификата SSH).
Согласно man-странице ssh-key-gen, параметр -n указывает имя principal. Это имя пользователя Unix, который будет пытаться подключиться по SSH к целевому серверу. Как мы знаем, имена пользователей не могут содержать недопустимые символы. В вашем случае, [example.com]:8022 недопустимо в качестве имени пользователя или principal из-за недопустимых символов.
Когда аутентификация с использованием сертификатов включена (TLS или SSH), номер порта не участвует в проверке сертификата. Валидация сертификата может включать (минимум):
- Общее имя (CN) – в большинстве случаев это DNS-имя сервера,
предоставляющего сертификат клиенту. - Издатель сертификата – это Удостоверяющий центр (CA), который
подписал сертификат. Знаю ли я и доверяю ли я CA, спрашивает клиент. - Действительность – Действителен ли сертификат или просрочен?
- Это серверный или клиентский сертификат?
Я бы предложил продолжать подписывать ваши SSH-сертификаты без указания номера порта. Номера портов не имеют отношения к сертификатам. Добавляя номер порта, вы в конечном итоге получаете недопустимые символы в именах principal.
Полный учебник можно найти здесь:
https://smallstep.com/blog/use-ssh-certificates/
https://smallstep.com/docs/tutorials/ssh-certificate-login/#login-to-vm-via-ssh-user-cert
Ответ или решение
В контексте проблемы, с которой вы столкнулись при подписании хостового ключа SSH на сервере, работающем на нестандартном порту, важно учитывать теорию работы SSH-сертификатов. Сертификаты SSH, аналогично TLS-сертификатам, зависят от идентичности объекта, для которого они выданы. Основные параметры идентичности включают общее имя (Common Name, CN) и список принципалов (principals), но не номер порта.
Теория
Когда вы подписываете хостовый ключ с использованием SSH CA, основное внимание уделяется имени хоста и принципалам, которым сертификат должен быть доверен. Ваша команда:
ssh-keygen -s ibug_ca -I example -h -n '[example.com]:8022' ssh_host_rsa_key.pubиспользует параметр -n для указания принципала, но [example.com]:8022 не является допустимым значением принципала из-за содержащихся в нем недопустимых символов, таких как квадратные скобки и двоеточие. Логика проверки сертификатов не включает в себя номер порта, а сфокусирована на имени хоста и доверенных лицах.
Пример
Вместо попытки указать порт в списке принципалов, следует держаться более простого синтаксиса. Например, команда может выглядеть следующим образом:
ssh-keygen -s ibug_ca -I example -h -n example.com ssh_host_rsa_key.pubЭто обеспечит верную идентификацию сертификата, исключая номер порта из процесса подбора принципала.
Применение
Для правильного использования и соблюдения стандартов, вы должны подписывать сертификаты без привязки к порту. Правильно подписав сертификат, вы можете указать нужный порт при подключении через SSH, используя опцию -p. Это позволяет отделять проверку сертификата от сетевых параметров:
ssh -p 8022 [email protected]Таким образом, корректная практическая реализация будет заключаться в подписании сертификата без учёта порта и использовании мощи SSH для управления соединением через указанный порт.
В заключение, для успешной работы с SSH-сертификатами на нестандартных портах следует сосредоточиться на корректном подходе к указанию имен хостов и принципалов, оставляя порты исключительно для настройки сетевых уровней соединения.