Сначала немного предыстории.
Сегодня, если вы работаете в среде AD, в которой преобладает Windows Server и имеется лишь небольшое количество серверов Linux, у вас есть возможность пройти аутентификацию на серверах через SSH:
- Управляйте серверами Linux через SSH с аутентификацией по сертификату (обычный способ Linux)
- Подключите серверы Linux к вашему домену AD (realm+sssd) и управляйте ими по SSH с аутентификацией по имени пользователя и паролю.
Проблема в том, что вариант 1 оставляет администраторам управление отдельным набором учетных данных от остальной среды, а вариант 2 предполагает, что администраторы предоставляют пароли удаленным серверам напрямую по сети до того, как машины полностью идентифицируют друг друга.
В мире Windows это решается (по крайней мере, для RDP, которого, как я знаю, следует избегать) с помощью аутентификации на уровне сети. Упрощенная версия процесса выглядит так:
- Пользователь начинает подключаться к удаленному компьютеру.
- Удаленный компьютер отвечает токеном учетной записи компьютера AD.
- Локальный компьютер проверяет токен, видит поддержку NLA и показывает пользователю диалоговое окно с данными для ввода.
- Пользователь завершает диалог с учетными данными
- Локальный компьютер проверяет учетные данные с помощью элемента управления домена (а не удаленного компьютера)
- DC предоставляет локальному компьютеру токен аутентификации.
- Локальный компьютер представляет токен удаленному компьютеру.
- Удаленный компьютер проверяет токен на соответствие домену.
- В случае успеха пользователю разрешается доступ к удаленному компьютеру.
На самом деле процесс может быть еще проще, если использовать существующий токен аутентификации, созданный для пользователя при его первом входе в систему на локальном компьютере.
Это сложный процесс, и я, конечно, допустил ошибки, описывая его. Суть в том, что токен аутентификации заменяет сертификат из истории Linux, так что пользователь никогда не предоставляет фактические учетные данные потенциально неизвестной машине. Более того, зависимость всех сторон от доверенного DC делает вещи даже лучше, чем в истории Linux, потому что пользователю не приходится управлять своими собственными сертификатами, даже через свое собственное программное обеспечение (скорее, это программное обеспечение предоставляется ему).
Теперь вопрос. Есть ли способ получить что-то подобное для аутентификации сеанса SSH на сервере Linux, присоединенном к AD, где сервер никогда не видит учетные данные пользователя, но пользовательский опыт по-прежнему представляет собой собственную проверку учетных данных Windows?
решение1
Это много чего требует решения, но по сути то, что нужно, это "керберизованный" SSH или что-то в этом роде. NLA также предоставляет дополнительный шаг (здесь не указан), не предоставляя сеанс консоли (создание которого требует больших ресурсов) до тех пор, пока аутентификация не будет проверена.
Более того, помимо сложностей, которые являются запретительными, я не вижу большого интереса к этому, потому что уже есть обходной путь. Используйте хост-бастион для перехода к хостам Linux, запрещая тип доступа/порт(ы) от других. Этот хост-бастион может быть Windows и поддерживать все отсутствующие функции.
Хосты Bastion Jump также становятся все более распространенными в средах AD для предоставления таких типов доступа, как RDP, к защищенным ресурсам.
Также для примера RDP учетные данные фактически не защищены от сервера. Это решается с помощью переключателя /RemoteGuard.
https://learn.microsoft.com/en-us/windows/security/identity-protection/remote-credential-guard
https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/mstsc