@RyoidenshiAokigahara
Начинающий

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

День добрый. Возник вопрос с авторизацией в 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: По той же ссылке добавлен и лог сервера с небольшим отличием - на текущий момент не было доступа к нужному устройству, поэтому ситуация продублирована в виртуальной машине.
  • Вопрос задан
  • 4077 просмотров
Решения вопроса 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
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы