Как подключиться к Windows через SSH под доменным пользователем без связи с доменом?

Question

[Петровский]

Есть ноутбук на Windows, связь с доменом через VPN. Иногда надо использовать другие VPN.

Настроил подключение через SSH, но при отсутствии связи с доменом SSH не пускает.

ssh -v заканчивается на:

debug1: kex_ext_info_check_ver: [e-mail]=<0>
debug1: kex_ext_info_check_ver: [e-mail]=<0>
debug1: SSH2_MSG_SERVICE_ACCEPT received
Connection reset by 192.168.1.2 port 22

Если остановить службу Stop-Service sshd (sshd работает под пользователем СИСТЕМА) и запустить sshd -d (sshd работает под пользователем Я), то подключение происходит даже при отсутствии связи с доменом.

Права на файл C:\ProgramData\ssh\administrators_authorized_keys выдавал следующие: СИСТЕМА, Администраторы (я в группе локальных администраторов), Я.

В логах Windows-Безопасность есть некие записи, но я их не понимаю и не знаю, как сюда привести.

Comments

[rPman]

больше информации, что настроил, куда подключаешься, причем тут 'другие vpn'? что за vpn (сейчас такое, что одним словом называют и http прокси, и socks, и особый протокол, и tap и tun..)

[rPman]

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

[Valentin Barbolin]

rPman, Ты просто не в теме.

Петровский, Почему просто не создать локального пользователя?

[Ziptar]

Я, наверное, не в тему, но для меня это выглядит так, что либо ключи должны быть выпущены доменной PKI, либо sshd должен производить олицетворение нужного пользователя сам по предоставленным ему его sshd'шным ключам - только как он сопоставлять это должен - это в доки; ни в том, ни в другом случае подключение к домену у машины, с которой производится подключение по ssh, не требуется (если в первом случае не надо жёстко crl проверять).
Но вообще из текста не очень понятно у кого нет подключения к домену, откуда куда производится попытка подключения по ssh, и т.п.

[Ziptar]

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

[Ziptar]

Петровский, ну так ты и будешь ограничен правами той сущности, из под которой запущен сервис. В данном случае учётной записью компьютера в домене.

[Valentin Barbolin]

Петровский,

(sshd под пользователем Я пускает),

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

[Петровский]

Valentin Barbolin, спасибо за понимание.



это при наличии связи с доменом.

также пробовал выставить права для "Все" на файл с ключом.

[Valentin Barbolin]

Петровский, О, это какая-то политика теба ограничивает, у меня такая же фигня была. Моя учетка в локальной группе админ но поставить sql express я не мог, т.к. политикой было ограничена возможность запуска служб от этой учетки.

надо как-то вспомнить...

[MaxKozlov]

Комп/Винда/БезопасностьЛокальные/Права пользователя/Вход в качестве службы

Но там действительно домен сертификаты проверяет или как ? не увидел что-то таких подробностей

[Петровский]

MaxKozlov, OpenSSH не работает с доменом, а домен в свою очередь ничего не знает о моем сертификате

[MaxKozlov]

Петровский, файл administrators_authorized_keys используется или только обычное местоположение ?
Права на файлы/ключи верные ?
Можно пофиксить через
C:\Windows\System32\OpenSSH\FixHostFilePermissions.ps1
C:\Windows\System32\OpenSSH\FixUserFilePermissions.ps1
или где у вас OpenSSH может лежать

Логов маловато, непонятно на каком этапе отваливается, успел ключ принять или нет. и какой. можно -vvv добавить побольше
Ну и виндовых логов можно за тот же промежуток с ошибками/предупреждениями повнимательнее глянуть
Трафик опять же, как гуляет ?
по вопросу непонятно что куда настроено. Сервер куда идём за тем же VPN что домен или нет. Как идёт подключение с\без VPN. по тому же маршруту или что-то меняется ?

btw, через psexec можно запустить sshd -d -vvv из под системы и тоже внимательно почитать

[Петровский]

MaxKozlov,
> Вход в качестве службы
посмотрел, там есть ДОМЕН\Я. Но под пользователем Я служба не запускается.

> Права на файлы/ключи верные ?
Да. Сейчас установил полные права всем, не меняет ситуацию.

Обмен ключами не идёт. Было бы интересно посмотреть лог сервера OpenSSH, но он не пишется под пользователем СИСТЕМА, даже если добавить LogLevel DEBUG. VPN тут только о том, что через него связь с доменом; никаким другим подключениям (RDP, SMB) он не мешает. В качестве файрволла Касперский, которым управлять нельзя.

runas /user:СИСТЕМА sshd -d не работает

> Сервер куда идём за тем же VPN
Служба OpenSSH запускается на ноутбуке.

Вот лог клиента.

ssh -v HOST
OpenSSH_9.8p1, LibreSSL 3.3.6
debug1: Reading configuration data /Users/USER/.ssh/config
debug1: Reading configuration data /Users/USER/.orbstack/ssh/config
debug1: /Users/USER/.ssh/config line 106: Applying options for HOST
debug1: /Users/USER/.ssh/config line 110: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/* matched no files
debug1: /etc/ssh/ssh_config line 54: Applying options for *
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to HOST.lan port 22.
debug1: Connection established.
debug1: identity file /Users/USER/.ssh/id_ed25519 type 3
debug1: identity file /Users/USER/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/USER/.ssh/rbr type 3
debug1: identity file /Users/USER/.ssh/rbr-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_9.8
debug1: Remote protocol version 2.0, remote software version OpenSSH_for_Windows_9.5
debug1: compat_banner: match: OpenSSH_for_Windows_9.5 pat OpenSSH* compat 0x04000000
debug1: Authenticating to HOST.lan:22 as '[e-mail]'
debug1: load_hostkeys: fopen /Users/USER/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: [e-mail] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [e-mail] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:i1QOQ...c/2RZkzQ
debug1: load_hostkeys: fopen /Users/USER/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host 'HOST.lan' is known and matches the ED25519 host key.
debug1: Found key in /Users/USER/.ssh/known_hosts:264
debug1: ssh_packet_send2_wrapped: resetting send seqnr 3
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: ssh_packet_read_poll2: resetting read seqnr 3
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_ext_info_client_parse: server-sig-algs=<ssh-ed25519,[e-mail],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[e-mail],[e-mail],ssh-dss,ssh-rsa,rsa-sha2-256,rsa-sha2-512>
debug1: kex_ext_info_check_ver: [e-mail]=<0>
debug1: kex_ext_info_check_ver: [e-mail]=<0>
debug1: SSH2_MSG_SERVICE_ACCEPT received
Connection reset by 192.168.5.32 port 22

[Петровский]

Нашёл лог сервера.

sshd: error: lookup_principal_name: User principal name lookup failed for user 'DOMAIN\\user' (explicit: 1355, implicit: 1355)
sshd: error: lookup_principal_name: User principal name lookup failed for user 'DOMAIN\\user' (explicit: 1355, implicit: 1355)
sshd: error: get_user_token - unable to generate token on 2nd attempt for user DOMAIN\\user
sshd: fatal: ga_init, unable to resolve user DOMAIN\\user

[MaxKozlov]

Вот как раз полные права всё ломают, ssh сервер работает только с ограниченными.

А если сервер за тем же vpn, то как тогда случается ситуация "при отсутствии связи с доменом SSH не пускает"
то есть нет связи между сервером и доменом, получается ?

sshd: error: get_user_token - unable to generate token on 2nd attempt for user DOMAIN\\user
sshd: fatal: ga_init, unable to resolve user DOMAIN\\user

[Петровский]

MaxKozlov,
Вот тут проблема описана: https://github.com/PowerShell/Win32-OpenSSH/issues...

> ssh сервер работает только с ограниченными.
Не уверен, что он вообще умеет проверять виндовые ACL. Тогда в логе были бы сообщения соответствующие.

> то есть нет связи между сервером и доменом, получается ?
Конечно нет, нет возможности постоянно поддерживать VPN до контроллера.

[MaxKozlov]

Петровский, ошибка касается запуска сервиса, как я понял, а не проблем с аутентификацией, так что интересно и полезно, но не то

>Сервер куда идём за тем же VPN
>Конечно нет, нет возможности постоянно поддерживать VPN до контроллера
С этого места вообще непонятно стало :)

/ ---vpn ---->Сервер
Юзер          | - а тут что, тоже связь через VPN ?
 \---vpn----->DC

Это ж сервер не может "resolve user DOMAIN\\user"

>Не уверен, что он вообще умеет проверять виндовые ACL
Зато я уверен :)
Если мы о sshd под windows, конечно

[MaxKozlov]

runas /user:СИСТЕМА sshd -d не работает

Я говорил про psexec, а не runas

[Петровский]

Вот тут тоже есть. https://serverfault.com/questions/1067665/unable-t...

Ошибка говорит о том, что в отсутствии связи с AD процесс sshd не может найти пользователя DOMAIN\Я. Хотя остальные сервисы (RDP, SMB, локальный логин) могут. Так, после перезагрузки я могу входить в систему без связи с AD, то есть credentials закэшировано на некоторое, достаточно большое время.

> С этого места вообще непонятно стало :)
Очень просто, это рабочий ноутбук, который работает включенным с закрытой крышкой. Я захожу на него удалённо со своего домашнего компьютера и так работаю. На ноутбуке десяток разных рабочих VPN (не имеют отношения к обходу блокировок). Поддерживать VPN до AD постоянно возможности нет.

RDP оказалось мало, нужно SSH.

[Петровский]

> Зато я уверен :)

По вашей ссылке проблема слишком узких прав, а не слишком широких. Только что проверил: широкие права никак не мешают логину (при наличии связи с AD).

psexec уже не нужен, так как логи найдены и сообщения прочитаны

[MaxKozlov]

Петровский, Да не, там как раз про широкие права на определённые файлы (надо было убрать S-1-5-11)
Допускаю что, так реагирует не на все группы и не на все файлы.

Вот, похоже, ваша проблема, нерешённая
https://github.com/PowerShell/Win32-OpenSSH/issues/1889

Судя по описанию, может проявляться если вдруг у вас в sshd ещё и GSSAPIAuthentication yes
можно попробовать отключить

Можно ещё посмотреть на
GSSAPICleanupCredentials
Specifies whether to automatically destroy the user's credentials cache on logout.
The default is yes.
По дефолту как раз yes - отключить

Я б в данной ситуации если ничего не помогает, завёл на этом ноуте локального юзера и ходил по ssh под ним

Answer 1

[MaxKozlov]

Вот, похоже, ваша проблема, нерешённая
https://github.com/PowerShell/Win32-OpenSSH/issues/1889

Судя по описанию, может проявляться если вдруг у вас в sshd ещё и GSSAPIAuthentication yes
можно попробовать отключить

Можно ещё посмотреть на
GSSAPICleanupCredentials
Specifies whether to automatically destroy the user's credentials cache on logout.
The default is yes.
По дефолту как раз yes - отключить

Comments

[Петровский]

"As it's currently coded, I don't believe there is any way cached credentials can be used. "
ответ исчерпывающий, спасибо