Где мы должны найти authorized_keys, когда мы используем сервер Windows 10 OpenSSH и WSL2?

Я настроил сервер OpenSSH в Windows 10 для установления ssh-соединения с WSL2 bash методом, описанным в этой статье: «ЛЕГКИЙ СПОСОБ, как подключиться по SSH к Bash и WSL2 в Windows 10 с внешнего компьютера», и этот документ: «Управление ключами OpenSSH».

Таким образом, я запускаю следующие команды в PowerShell от имени администратора:

Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Start-Service sshd
New-ItemProperty -Path "HKLM:SOFTWAREOpenSSH" -Name DefaultShell -Value "C:WINDOWSSystem32bash.exe" -PropertyType String -Force

После этого я мог подключиться по ssh из PowerShell к WSL2 bash на локальном хосте с помощью ssh <my Windows username>@localhost используя пароль Windows.

Далее я хочу подключиться не с помощью пароля, а с помощью пары ключей. Итак, я создал пару ключей в PowerShell и расположил ее как C:Users<my Windows username>.sshauthorized_keys.

cd C:Users<my Windows username>.ssh
ssh-keygen -t ed25519 -f id_ed25519
copy id_ed25519.pub authorized_keys

Но это не могло позволить мне подключить localhost с помощью пары ключей. Команда ssh -vvv -i C:Users<my Windows username>.sshid_ed25519 <my Windows username>@localhost возвращает ошибку разрешения со строкой журнала debug3: receive packet: type 51 сразу после предложения открытого ключа закрытого ключа.

В качестве еще одной попытки я нашел authorized_keys в домашнем каталоге WSL2 /home/<my WSL2 username>/.ssh и беги chmod 600, но результат ssh в PowerShell такой же, как указано выше.

Итак, мой вопрос: как подключить сервер OpenSSH в Windows 10, оболочкой которого по умолчанию является WSL2 bash, с помощью пары ключей? Где мне найти authorized_keys?

Я использую аналогичную конфигурацию, и есть несколько вещей, с которыми я столкнулся при устранении неполадок этого типа. Два из них уже упоминались в вашем вопросе, так что у вас хорошее начало. Я просто упоминаю об этом здесь для тех, кто приходит посмотреть на этот ответ:

• Убедитесь, что вы используете ключи ECDSA, а не RSA. Сервер Windows OpenSSH имеет ошибку (исправленную в последней версии, но не включенную в Windows), которая приводит к сбою ключей RSA. Тебе здесь хорошо.

• Устранение неполадок с разрешениями — убедитесь, что .ssh Каталог (расположение будет обсуждаться позже) доступен в лучшем случае только SYSTEM, пользователю и группе администраторов. То же самое для любых файлов закрытых ключей в нем.

Администраторы Match Group

Вот наиболее вероятная причина … Если ваш пользователь Windows является администратором, то конфигурация Windows OpenSSH по умолчанию, вероятно, «мешает» нашим разумным ожиданиям от Unix / Linux ;-). Проверьте свои C:ProgramDatasshsshd_config. По умолчанию он, вероятно, имеет следующие строки внизу:

Match Group administrators
       AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys

Я предполагаю, что это сделано для безопасности многопользовательской системы. Наличие единого централизованного хранилища для ведения списка авторизованных ключей упрощает просмотр и обновление этого файла. Необходимость поиска в нескольких каталогах пользователей потребует дополнительных усилий.

Итак, у вас есть два варианта:

• Поскольку вы работаете в однопользовательской системе Windows 10, вы можете просто закомментировать эти строки, перезапустить службу OpenSSH Server, и тогда вы сможете использовать свой authorized_keys в %userprofile%.sshauthorized_keys.

• Если вы тот, кто делает поддерживать многопользовательские системы, вы можете просто использовать передовой опыт размещения авторизованных ключей в %programdata%sshadministrators_authorized_keys.

Проблемы с DefaultShell

Наконец, я видел, как отказано в ключе, когда есть ошибка в DefaultShell ключ реестра. Вы, вероятно, уже заметили это в своем ssh -vvv выход. Это бы вернуло что-то вроде:

User not allowed because shell C:\WINDOWS\System32\bash.exe does not exist

Полагаю, это не твоя проблема. Тем не менее, я бы рекомендовал использовать wsl.exe вместо bash.exe. Последняя не совсем устарела, но Microsoft называет ее «исторической» командой для запуска WSL и теперь рекомендует гораздо более многофункциональную (не говоря уже о поддерживаемой и протестированной), wsl.exe.

Обратите внимание, что вы также можете запустить сеанс WSL с дополнительными параметрами — подробности см. В моем вопросе / ответе здесь, где я первоначально столкнулся с ошибкой «не существует», которая вызвала отказ ключей типа 51 .

Другие шаги отладки

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