OpenSSH в Windows 10. По какой причине доступ запрещен?

Question

[Евгений]

День добрый. Возник вопрос с авторизацией в Windows OpenSSH по ключу.
До этого несколько раз доводилось настраивать без ключей (только по паролю) и вроде бы все было ок.
В этот раз решил сделать авторизацию только по SSH-ключу и напоролся на Permission denied (publickey,keyboard-interactive).

Кратко о сервере:
Сервер - винда 10
Юзер - локальная учетная запись (с правами администратора)
Публичный ключ лежит в authorized_keys в дирректории пользователя (C:\Users\LocalUser\.ssh\authorized_keys).
Всевозможные перезапуски и перезагрузки были.
OpenSSH сервер установлен: (на всякий случай испробованы оба варианта)
1) Параметры -> Приложения -> Дополнительные компоненты -> Сервер OpenSSH
2) Через PowerShell согласно официальной инструкции

Поискав некоторые моменты из лога наткнулся на закрытую issue от 2017 года в которой было упомянуто, что

Windows inbox Beta version currently supports one key type (ed25519).

До этого использовал RSA-ключи и в логе мелькала информация о ключах в духе

debug1: identity file C:\\Users\\LocalUser/.ssh/id_rsa type 0
debug1: identity file C:\\Users\\LocalUser/.ssh/id_ed25519 type -1

Под каждым из которых была строка о том что файл не найден.

После чтения той issue стал использовать ed25519-ключ, теперь стало так:

debug1: identity file C:\\Users\\LocalUser/.ssh/id_ed25519 type 3
debug3: Failed to open file:C:/Users/LocalUser/.ssh/id_ed25519-cert error:2
debug3: Failed to open file:C:/Users/LocalUser/.ssh/id_ed25519-cert.pub error:2
debug1: identity file C:\\Users\\LocalUser/.ssh/id_ed25519-cert type -1

Собственно в конечном счете в логе мелькает (если я правильно понимаю) отправка ключа

debug1: Offering public key: C:\\Users\\LocalUser/.ssh/id_ed25519 ED25519 SHA256:xKMs9i1ZJyeQjvIY3jL2WIZnGNwOr6v/7QLUPu9t2Nw explicit
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51

Однако после него SSH пытается пройти авторизацию по другим включенным способам авторизации - если по паролю включена - спрашивает пароль (даже в случае когда ключ явно указан), если выключена - сразу Permission denied (publickey,keyboard-interactive).

Подскажите в чем проблема в этом случае?

Полный лог c клиента доступен на https://gist.github.com/NEK-RA/e3656f98ca7e1b6c4d7... (т.к. если вставить его напрямую тут, будет превышен лимит в 10 000 символов в тексте вопроса)
UPD: По той же ссылке добавлен и лог сервера с небольшим отличием - на текущий момент не было доступа к нужному устройству, поэтому ситуация продублирована в виртуальной машине.

Comments

[MaxKozlov]

А где логи сервера? Наверняка там ответ.
Публичный ключ у него в authorized _keys там лежит?
Сервер вообще кто? Если винда и юзер - админ, там своя тонкость

[Евгений]

MaxKozlov,
Сервер - винда 10
Юзер - локальная учетная запись (с правами администратора)
Публичный ключ лежит в authorized_keys в дирректории пользователя.
Всевозможные перезапуски и перезагрузки были.
С логами сервера протупил (не записал), т.к. подумал что из логов клиента можно информацию вытянуть и понять что к чему.

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

[MaxKozlov]

Евгений, на винде ,если юзер админ, ключ должен лежать в отдельном файлике рядом с конфигами-в c:\programdata\ssh. Не помню точного названия, но что-то типа adminautorized_keys - там найдёте

Answer 1

[MaxKozlov]

Добрался до компа, напишу уж тут :)
В логах сервера видно что за проблема - не те права у того самого файлика, что я упоминал в комментарии

debug3: Bad permissions. Try removing permissions for user: S-1-5-11 on file C:/ProgramData/ssh/administrators_authorized_keys.
Authentication refused.

При подключении к OpenSSH-серверу, установленному, на win и использовании аутентификации по ключу, необходимо обращать внимание на два момента:
1. Если пользователь админ - его публичный ключ должен быть указан в C:\ProgramData\ssh\administrators_authorized_keys
2. Убедиться что владелец файлов *authorized_keys правильный: системных - система, юзерских - юзер, и без лишних доступов.
Например, установить права для системного можно скопировав их с другого файла:

$acl = Get-Acl C:\ProgramData\ssh\ssh_host_dsa_key.pub
Set-Acl -Path C:\ProgramData\ssh\administrators_authorized_keys -Acl $acl

Ещё в комплекте c GitHub идут специальные скрипты для тех же целей:
FixHostFilePermissions.ps1
FixUserFilePermissions.ps1
Они что-то ещё в реестре вроде бы правят

Вариант обхода настроек для этого файла -закомментировать в конфигах его упоминание:

Match Group administrators
       AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys

Но это не рекомендуется

Ну, и, как замечено в комментариях, необходимо убедиться в правильной кодировке файла
https://github.com/PowerShell/Win32-OpenSSH/issues...
Если коротко, то оказалось что кодировкой *authorized_keys по дефолту является UCS-2 LE BOM, вместо ожидаемого UTF-8. После смены кодировки все заработало так как надо.

Мои лично файлы все в ASCII

Comments

[Евгений]

Ещё в комплекте идут специальные скрипты для тех же целей:
FixHostFilePermissions.ps1
FixUserFilePermissions.ps1
Они что-то ещё в реестре вроде бы правят

Если я правильно понял - они идут только в комплекте архива с Github Releases, т.к. при установке из "Доп.компонентов" в параметрах установка идет в C:\Windows\System32\OpenSSH и ни по этому пути, ни в C:\ProgramData\ssh таких скриптов не обнаружено (в C:\Program Files и %appdata% я никаких следов не нашел)

[Евгений]

Выполнил собственно говоря эти скрипты, сервер перестал жаловаться на разрешения, однако administrators_authorized_keys ему по прежнему не нравится:

debug1: read_keyfile_line: __PROGRAMDATA__/ssh/administrators_authorized_keys line 1 exceeds size limit
debug3: mm_answer_keyallowed: publickey authentication test: ED25519 key is not allowed

В итоге тот же

Failed publickey for VBOX

[Евгений]

Однако эта проблема решилась довольно быстро - https://github.com/PowerShell/Win32-OpenSSH/issues...
Если коротко, то оказалось что кодировкой *authorized_keys по дефолту является UCS-2 LE BOM, вместо ожидаемого UTF-8. После смены кодировки все заработало так как надо.

Добавьте пожалуйста эти моменты в Ваш ответ, чтобы его можно было отметить окончательным решением проблемы. Большое спасибо за участие :)

[MaxKozlov]

Евгений, Я конечно добавлю, но в моём случае банальный ASCII спасает :)
тем более что там нечему быть другому - не стоит комментарии к ключам по-русски писать ;-)

Видимо какой-то чел в микрософте создавал этот файл через перенаправление >filename, оно как раз по дефолту multibyte unicode. а я его просто заменял на свой