Где хранятся ssh key windows

Обновлено: 05.07.2024

Мне очень сложно настроить и запустить свои SSH-ключи после установки Windows 10. Обычный метод - создать его и добавить в учетную запись пользователя под .ssh. Эта папка недоступна в Windows 10.

Кто-нибудь еще сталкивался с этим? Мне нужно иметь 3 ключа SSH для разных репозиториев, и это меня очень сдерживает.

Нет, это то, о чем я думал сначала, но после установки было добавлено несколько. @MartinPrikryl Поскольку много кода в Linux, использование Github и т. Д. Связано с ключами ssh и .ssh, я бы сказал, что это очень актуально для Stackoverflow. Я согласен с Мартином. Вопрос программирования - это вопрос о написании программы, а не вопрос, который может задать программист.

Откройте командную строку Windows (введите «cmd» в поле поиска и нажмите Enter).
По умолчанию это будет ваша домашняя папка, поэтому вам не нужно cd использовать другую.
Тип ssh-keygen
Следуйте инструкциям, и все готово
Ваши ключи ssh должны храниться в выбранном каталоге, по умолчанию: /c/Users/YourUserName/.ssh/id_rsa.pub

ps: если вы установили git с интеграцией bash (как я), откройте «Git Bash» вместо «cmd» на первом шаге

это выглядит отлично, но не работает. нет команды ssh-keygen по какой-то причине мне пришлось запустить ssh-keygen команду в оболочке git-bash вместо cmd-shell. Для этого вы можете использовать Git Bash sheel или git cmd, вы не можете использовать Windows cmd. По состоянию на декабрь 2018 года в Win 10 у меня все работало из коробки @Suncatcher Да. Для входа в Github, DigitalOcean и т. Д. Вам понадобится открытый ключ, который находится в «id_rsa.pub» в той же папке. Откройте его с помощью текстового редактора, такого как блокнот, и скопируйте и вставьте туда, где вам нужно добавить свой SSH-ключ.

2019-04-07 ОБНОВЛЕНИЕ: Сегодня я тестировал новую версию Windows 10 (сборка 1809, «октябрьское обновление 2018»), и не только открытый SSH-клиент больше не находится в бета-версии, так как он уже установлен. Итак, все, что вам нужно сделать, это создать ключ и настроить клиент на использование открытого SSH вместо замазки (pagent):

открыть командную строку (cmd)
введите ssh-keygen и нажмите ввод
нажмите ввод для всех настроек. теперь ваш ключ сохранен в c: \ Users \ .ssh \ id_rsa.pub
Откройте свой клиент git и настройте его на использование открытого SSH

Я тестировал Git Extensions и Source Tree, и он работал с моим личным репо в GitHub. Если вы используете более раннюю версию Windows или предпочитаете графический клиент для SSH, прочтите ниже.

В Windows 10, начиная с версии 1709 (win + R и введите winver номер сборки), Microsoft выпускает бета-версию клиента и сервера OpenSSH. Чтобы иметь возможность создать ключ, вам необходимо установить сервер OpenSSH. Для этого выполните следующие действия:

откройте стартовое меню
Введите "необязательная функция"
выберите "Добавить дополнительную функцию"
Нажмите "Добавить функцию".
Установите «Open SSH Client»
Перезагрузите компьютер

Теперь вы можете открыть приглашение, и ssh-keygen клиент будет распознан окнами. Я не проверял это. Если у вас нет Windows 10 или вы не хотите использовать бета-версию, следуйте приведенным ниже инструкциям по использованию шпатлевки.

ssh-keygen не устанавливается с окнами. Вот как создать ключ ssh с помощью Putty:

Для ключей openssh требуется еще несколько шагов:

скопируйте текст из текстового поля «Открытый ключ для вставки» и сохраните его как «id_rsa.pub»
Чтобы сохранить закрытый ключ в формате openssh, перейдите в Конверсии-> Экспорт ключа OpenSSH (если вы не определили ключ доступа, он попросит вас подтвердить, что вы не хотите ключ доступа)
Сохраните его как "id_rsa"

Теперь, когда ключи сохранены. Запустите pagent и добавьте туда закрытый ключ (файл ppk в формате Putty)

SSH-ключи используются для идентификации клиента при подключении к серверу по SSH-протоколу . Используйте этот способ вместо аутентификации по паролю.

SSH-ключи представляют собой пару — закрытый и открытый ключ. Закрытый должен храниться в закрытом доступе у клиента, открытый отправляется на сервер и размещается в файле authorized_keys.

Создание SSH-ключей в Linux на примере CentOS

На клиентской стороне должен быть установлен пакет ssh (openssh). На серверах FirstVDS с шаблонами по умолчанию необходимое ПО уже установлено.

На клиентском компьютере в командной строке выполните команду генерации ключей:

Введите путь файла, в который будут помещены ключи. Каталог по умолчанию указан в скобках, в примере /домашний_каталог/.ssh/id_rsa . Если хотите оставить расположение по умолчанию, нажмите Enter .

Пароль (passphrase) используется для ограничения доступа к закрытому ключу. Пароль усложнит использование ключа третьими лицами в случае утраты. Если не хотите использовать секретную фразу, нажмите Enter без заполнения строки.

Успешно сгенерировав пару ключей, вы увидите уведомление:

Открытый ключ хранится в файле /домашний_каталог/.ssh/id_rsa.pub , закрытый — /домашний_каталог/.ssh/id_rsa .

Скопируйте открытый ключ на сервер в файл /домашний_каталог/.ssh/authorized_keys . Одной строкой:

Или откройте этот файл на сервере редактором vi и вставьте строку с открытым ключом после ssh-rsa .

Ещё один способ скопировать ключ в authorized_keys — команда echo , которая помещает строку в конец файла.

Теперь можно отключить на сервере аутентификацию по паролю и использовать только SSH-ключи.

Создание SSH-ключей на Windows с PuTTYgen

Если вы используете ОС Windows, то подключиться по SSH к вашему (Linux) серверу можно через PuTTY или OpenSSH . Генерация ключей в этом случае выполняется также при помощи этих программ. В примере мы используем клиент PuTTY.

Запустите приложение PuTTYgen , которое устанавливается вместе с PuTTY.

Выберите тип ключа SSH2-RSA и нажмите Generate .

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

После завершения создания ключей открытый ключ выводится на экран, закрытый хранится в памяти приложения. Чтобы сохранить эти ключи нажмите Save public key и Save private key . Укажите расположение файлов с ключами.

При сохранении закрытого ключа, если не заполнено поле Key passphrase , появится запрос «Хотите ли вы сохранить ключ без секретной фразы?»

Теперь открытый ключ необходимо скопировать на сервер в файл authorized_keys . Используйте WinSCP или другой клиент для работы с файлами на удалённом Linux-сервере. Вы можете скопировать файл с открытым ключом целиком на сервер, чтоб его копия хранилась в папке .ssh

Откройте файл authorized_keys через WinSCP и файл, в который вы сохранили открытый ключ (public), на локальном компьютере текстовым редактором. Скопируйте значение ключа, сохраните и закройте файл в WinSCP.

При запуске PuTTY укажите путь к закрытому ключу на локальном компьютере. Для этого во вкладке Connections → Auth выберите необходимый путь.

Теперь можно отключить на сервере аутентификацию по паролю и использовать только SSH-ключи.

Отключение аутентификации по паролю

Подключитесь к серверу по SSH, используя пароль, и откройте файл sshd_config для редактирования.

Убедитесь, что указан правильный путь к открытым ключам SSH, поставьте значение параметра PasswordAuthentication no .

Перезапустите службу sshd.

Подключитесь к серверу по SSH без использования пароля. Например, запустите PuTTY, проверьте, что во вкладке Connections -> Auth содержится путь к закрытому ключу и откройте подключение.

Описываются особенности настройки встроенного в Windows 10 SSH сервера для обеспечения доступа к нему по ключам без ввода пароля, в том числе, приёмы для передачи публичных ключей и установки прав доступа к файлам с ними.

Евгений Боздаганян

SSH • Windows • Конфигурирование • OpenSSH • Компьютерные истории • Истории

Введение

Начиная с верcии 1803 , в Windows 10 доступны SSH клиент и SSH сервер, причём, SSH клиент установлен и готов к использованию, как говорится, прямо из коробки, а SSH сервер надо устанавливать, но делается это буквально в пару-тройку кликов мышкой [1] . Что это означает? С точки зрения клиента можно говорить о том, что сторонние программы, такие как PuTTY , вроде как больше не нужны. С точки зрения сервера - не надо устанавливать никакие сторонние серверы, если есть решение интегрированное.

В работе что клиент, что сервер, практически не отличаются от того ПО, к которому я привык в Debian . Но, как ни крути, есть некоторые отличия, и вот об одном из них попробую сейчас рассказать. Речь пойдет о подключении к SSH серверу, работающему на Windows , с клиента, в моем случае, работающего на Debian Jessie , причем, без использования пароля, то есть, задействуя ключи.

На самом деле, начало процесса не отличается от стандартного: если у вас нет набора ключей, вам его надо сгенерировать, если есть - используйте существующий. Речь сейчас идёт о той машине, которая будет клиентом. И я уже как-то писал об этом, но на некоторых моментах всё-таки остановлюсь ещё раз: повторенье - мать ученья 😉.

Про генерацию ключей

Итак, если ключей нет и вы работаете на системе под управлением Linux , то вот эта команда поможет вам их сгенерировать:

Если же вы работаете под Windows , то у вас есть несколько возможностей сгенерировать ключи:

Если вы работаете под Windows 10 и включили возможность использовать встроенный SSH клиент, то смело используйте команду ssh-keygen - должно сработать. 🙄😉
Если вы работаете под Windows 10 и включили возможность использовать WSL, то можете воспользоваться возможностями этой подсистемы, то есть, использовать в ней. всё ту же команду ssh-keygen .
Если вы работаете под Windows 10 и у вас не установлен встроенный SSH клиент и не включена возможность использования WSL , или же у вас более ранняя версия Windows , то придется использовать стороннее ПО, тот же PuTTY с его генератором PuTTYgen - для этого случая есть достаточно подробная документация.

Если пара ключей успешно сгенерирована, или уже была у вас, то необходимо "доставить" публичный ключ на сервер и там сделать его доступным для использования SSH сервером. И вот тут то и начинаются отличия от обычного - для мира Linux - процесса.

Доставка публичного ключа на сервер Linux

Что я делал, когда мне надо было "доставить" ключ на SSH сервер, работающий на Linux ? Всё очень просто - запуск следующей команды на клиентской машине решал все вопросы:

где user_name - имя пользователя, ключ которого передаётся на сервер, а server_name_or_ip - имя или адрес хоста с сервером SSH , к которому есть желание подключаться без ввода пароля (от имени пользователя с ключом). Иногда команда не работала и приходилось явно указывать файл (при помощи параметра командной строки -i ), в котором хранился публичный ключ, но это, в большей степени, зависело от устройства, на котором выполнялась эта команда, вернее, от версии ОС, ну и от реализации и версии криптографического ПО, конечно.

Доставка публичного ключа на сервер Windows

Но, в случае, когда в качестве сервера выступает машина с Windows , этот приём не прокатывает - ключ не передаётся на нужный хост и всё. Не знаю, эксперименты эти я проводил довольно давно, может, в новых версиях Windows эту "особенность" исправили, а может и нет. В любом случае, тогда мне пришлось искать обходной путь.

Собственно, сам этот путь очевиден - раз не получается сделать передачу ключа автоматом, надо всё выполнить вручную. А для этого необходимо знать, где и как Windows хранит публичные ключи, используемые SSH сервером для аутентификации клиентов. К счастью, в документации Microsoft есть необходимая информация и её надо просто использовать. Давайте её детально разберём, при том держа в уме, что документация предполагает работу с клиентской машины под управлением Windows с заранее настроенным доступом по SSH к необходимому серверу.

Создание каталога для хранения ключей

Итак, из документации становится очевидно, что Windows хранит пользовательские ключи, используя тот же принцип, что и Linux : на сервере в файле authorized_keys в подкаталоге .ssh домашнего каталога пользователя (а это, как правило, c:\Users\user_name , где user_name - имя пользователя), от имени которого вы хотите работать в установившемся SSH сеансе. Если этого каталога нет, его надо создать, для чего предлагается использовать команду:

где user_name - имя пользователя, domain_name - имя домена, в который входит пользователь (его можно опустить для локальных пользователей на удалённом сервере), host_name - имя или адрес хоста, к которому подключаемся. Приведённая мною команда несколько отличается от той, которая дана в документации, но следует помнить, что я работаю с клиентской машины под управлением Linux .

Копирование публичного ключа

Далее, предлагается скопировать во вновь созданный каталог файл с публичным ключом пользователя, от имени которого вы работаете на клиентской машине при подключении к серверу по SSH (команда слегка отличается от той, которая приведена в документации, так как я работаю с машины под управлением Debian ):

где public_key_file_name.pub - имя файла публичного ключа, например, id_ed25519.pub или id_rsa.pub (далее в примерах я буду использовать для простоты id_rsa.pub ).

На этом моменте хотелось бы остановиться подробнее. Обычно вы работаете на своём компьютере (или виртуалке) под своим собственным пользователем. Когда вы подключаетесь к удалённой машине по SSH , вы можете подключаться под именем своего текущего пользователя локальной машины, или использовать имя какого-либо пользователя удалённого компьютера, или же - доменное имя. Конечно, в любом случае на удалённом хосте должен существовать соответствующий пользователь (или разрешено использовать доменное имя), даже если его имя будет совпадать с именем пользователя, под которым вы работаете на своём локальном хосте. Так вот, совсем не обязательно, что вы единственный подключаетесь к удалённому хосту под определенным пользователем, вполне возможно, что с других хостов другие люди (или вы сами?) также подключаются по SSH , используя ту же самую учётную запись.

Возможно то, что я написал выше, это "ужас-ужас" с точки зрения безопасности, но такая ситуация весьма вероятна в домашних и небольших офисных сетях (да и не только 🙁), в которых не сильно заморачиваются с администрированием. И вот в таких случаях, копировать файл со своим публичным ключом - плохая идея: вы просто затрёте существующий файл authorized_keys с публичными ключами других пользователей (или ваших собственных ключей на других компьютерах - вряд ли вы переносите свою единственную пару ключей с хоста на хост 😉). Поэтому следует рассмотреть возможность добавлять свой ключ к соответствующему файлу на удалённом хосте.

Добавление публичного ключа

Обратите внимание на использование символов '/' в команде scp и '\' в командах ssh - так как мы работаем на Debian , то в команду scp можно передать путь на хосте с Windows с использованием нестандартного для Windows разделителя '/', а вот в команды, выполняемые при помощи ssh на том же удалённом компьютере, следует передавать символы '\',то есть, стандартный для Windows разделитель '\' с предшествующим символом '\', так называемый "escaped backslash", иначе Windows не найдёт нужные файлы.

Назначение прав доступа к файлу с публичными ключами

Вот мы и подошли к последнему шагу - предоставлению прав доступа к файлу authorized_keys . Именно этим занимается команда:

Основную смысловую нагрузку в этой составной команде несёт функция Repair-AuthorizedKeyPermission из модуля OpenSSHUtils для PowerShell (да, именно PowerShell используется в качестве командной оболочки в этот раз). Этот модуль надо устанавливать отдельно, например, так (выполнять эту команду надо, естественно, из PowerShell ):

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

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

Вот честно, не знаю, так это, или нет, но проверять расхотелось, тем более, что совсем не трудно задать нужные права самостоятельно. После некоторого изучения вопроса - я не большой специалист в PowerShell - получился вот такой вот набор команд [2] (я приведу их полностью, потом разберу для чего нужна каждая из них):

Теперь, как и обещал, небольшие пояснения по командам. Итак, для начала, при помощи cmdlet -а Get-Acl получаем дескриптор безопасности, содержащий ACL (Access Control List) нужного нам объекта файловой системы (параметр командной строки Path можно опустить) и сохраняем результат в переменной $acl . Далее, используя метод SetAccessRuleProtection полученного объекта, запрещаем наследование прав ( true в первом параметре) и отказываемся от сохранения унаследованных ранее прав ( false во втором параметре). Затем создаём два объекта, описывающих правила доступа к объектам файловой системы: один (сохраняется в переменной $adminsRule ) - для Администраторов, второй (сохраняется в переменной $sysRule ) - для специального пользователя SYSTEM . Теперь, при помощи метода SetAccessRule, добавляем только что соданные ACL к дескриптору безопасности нашего файла, хранящегося в переменной $acl . После чего, всё, что нам остаётся сделать - применить полученный дескриптор, для чего используем cmdlet Set-Acl.

Ну вот, теперь, когда мы выполнили все шаги, всё должно заработать. Но, в моём случае, не заработало. Очередная неудача заставила меня вновь полезть в документацию, что обогатило меня новыми знаниями. Рассказываю.

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

Причиной того, что при соединении с SSH сервером мне, несмотря на все предыдущие мытарства, продолжало выводиться требование ввести пароль, было то, что я пытался подключиться под пользователем, который входил в группу локальных Администраторов. У Windows 10 в этом случае есть требование - публичные ключи должны храниться в файле %programdata%/ssh/administrators_authorized_keys , то есть, обычно, в C:\ProgramData\ssh\administrators_authorized_keys .

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

Второй путь чуть более радикальный - изменить настройки SSH сервиса. Настройки эти хранятся в файле %programdata%/ssh/sshd_config . Как оказалось, именно там определяется, где должны храниться публичные ключи тех пользователей, которые подключаются к SSH серверу от имени пользователей, входящих в группу администраторов. Вот, собственно, эти строки:

Так вот, эти строки надо закомментировать или удалить, после чего SSH сервер надо перезапустить.

Какой путь использовать - решать вам. Я же, пожалуй, закончу - пост получился и так слишком длинным.

На самом деле, в виде beta версий эти компоненты были доступны и раньше, но и установка и стабильность работы, были, что называется, не на высоте. ↩︎

Честно признаюсь, очень многое я подсмотрел в документации, например, как отключить наследование прав, или предоставить Администраторам полный контроль над файлом, и лишь немного адаптировал эти примеры к собственным нуждам. ↩︎

22.01.2020

Windows 10, Windows Server 2019

комментариев 10

В этой статье мы настроим SSH аутентификацию в Windows по RSA-ключам для безопасного доступа к удаленным системам. Мы покажем, как сгенерировать RSA-ключи (сертификаты) в Windows и настроить сервер OpenSSH в Windows 10/Windows Server 2019 для авторизации по ключам (без паролей).

Аутентификация по в SSH ключам широко используется в мире Linux, а в Windows этот функционал появился относительно недавно. Идея заключается в том, что на SSH сервере добавляется открытый ключ клиента и при подключении сервер проверяет наличие соответствующего закрытого ключа у клиента.

Генерация RSA ключей на клиенте Windows

На клиентском, компьютере, с которого вы будет подключаетесь к удалённому серверу Windows с OpenSSH, вам нужно сгенерировать пару RSA-ключей (открытый и закрытый). Закрытый ключ хранится на клиенте (не отдавайте его никому!), а открытый ключ помещается на SSH сервер в файл authorized_keys. Чтобы на клиенте Windows сгенерировать RSA ключи, вы должны установить клиент OpenSSH.

В Windows 10 1809 и Windows Server 2019 клиент OpenSSH устанавливается как отдельный встроенный компонент:

Add-WindowsCapability -Online -Name OpenSSH.Client

В предыдущих версиях Windows можно установить порт Win32-OpenSSH с GitHub (см. пример в статье о настройке SFTP сервера в Windows).

Запустите обычную (непривилегированную сессию PowerShell) и сгенерируйте пару RSA 2048 ключей с помощью команды:

Утилита попросит вас указать пароль для защиты закрытого ключа. Если вы укажете пароль, то каждый раз при использовании этого ключа для SSH авторизации, вы должны будете вводить этот пароль. Я не стал указывать пароль для ключа (не рекомендуется).

Утилита ssh-keygen создаст каталог .ssh в профиле текущего пользователя Windows (C:\Users\your_username) и поместит в него 2 файла:

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

SSH Agent может хранить закрытые ключи и предоставлять их в контексте безопасности текущего пользователя. Запустите службу ssh-agent и настройте автоматический запуск с помощью PowerShell команд управления службами:

set-service ssh-agent StartupType ‘Automatic’
Start-Service ssh-agent

Добавьте ваш закрытый ключ в базу ssh-agent:

Настройка OpenSSH в Windows для авторизации по ключам

Теперь открытый ключ, который вы сгенерировали на клиенте, нужно скопировать на ваш SSH сервер (в этом примере это удаленный компьютер с Windows 10 1903 и настроенной службой OpenSSH).

Скопируйте файл id_rsa.pub в каталог .ssh профиля пользователя, под которым вы будете подключаться к SSH серверу. Например, у меня в Windows 10 создан пользователь admin, значит я должен скопировать ключ в файл C:\Users\admin\.ssh\authorized_keys.

Можно скопировать ключ на SSH сервер с клиента с помощью SCP:

scp C:\Users\youruser\.ssh\id_rsa.pub admin@192.168.1.90:c:\users\admin\.ssh\authorized_keys

Теперь вы можете подключиться к SSH серверу без ввода пароля пользователя. А если вы не задали пароль (passphrase) для закрытого ключа, вы сразу автоматически подключитесь к вашему удаленному серверу Windows.

Для подключения через SSH к удаленному хосту используется следующая команда:

ssh (username)@(имя или IP адрес SSH сервера)

Это означает, что вы хотите подключиться к удаленному SSH серверу с адресом 192.168.1.90 под учетной записью admin. Служба SSH Agent автоматически попытается использовать для авторизации сохраненный ранее закрытый ключ.

Если вы не хотите использовать ssh-agent для управления ключами, вы можете указать путь к закрытому ключу, который нужно использовать для SSH аутентификации:

ssh admin@192.168.1.90 -i "C:\Users\youruser\.ssh\id_rsa"

Если вы не смогли подключиться к вашему SSH серверу по RSA ключу, и у вас все равно запрашивается пароль, скорее всего пользователь, под которым вы подключаетесь, входит в группу локальных администраторов сервера (SID группы S-1-5-32-544). Об этом далее.

В OpenSSH используются особые настройки доступа по ключам для пользователей с правами локального администратора Windows.

В первую очередь, вместо ключа authorized_keys в профиле пользователя нужно использовать файл с ключами C:\ProgramData\ssh\administrators_authorized_keys. Вам нужно добавить ваш ключ в этот текстовый файл (в целях безопасности права на этот файл должны быть только у группы Administrators и SYSTEM).

Дополнительно в файле sshd_config вы можете разрешить вход по RSA ключам:

И запретить доступ по паролю:

После сохранения изменений в файле sshd_config не забудьте перезапустить службу sshd.

Еще один небольшой нюанс. В старых версиях OpenSSH нужно было предоставить права службе NT Service\sshd на чтение ключа authorized_keys.

Для этого нужно выполнить одно из следующих действий:

Итак, вы настроили SSH аутентификацию в Windows по открытому RSA-ключу (сертификату). Теперь вы можете использовать такой способ аутентификации для безопасного доступа к удаленным северам, автоматического поднятия проброса портов в SSH туннеле, запуска скриптов и других задачах автоматизации.

Предыдущая статья Следующая статья

Windows 10 не видит компьютеры в сетевом окружении Ошибка 0x80070035: Не найден сетевой путь в Windows 10 Защита RDP от подбора паролей с блокировкой IP правилами Windows Firewall Теневое RDP подключение к рабочему столу пользователя в Windows 10

debug1: Found key in C:\\Users\\\320\237\320\276\320\273\321\214\320\267\320\276\320\262\320\260\321\202\320\265\320\273\321\214/.ssh/known_hosts:9
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug2: key: C:\\Users\\\320\237\320\276\320\273\321\214\320\267\320\276\320\262\320\260\321\202\320\265\320\273\321\214/.ssh/id_rsa (000002372A7B17D0), agent
debug2: key: C:\\Users\\\320\237\320\276\320\273\321\214\320\267\320\276\320\262\320\260\321\202\320\265\320\273\321\214/.ssh/id_dsa (0000000000000000)
debug2: key: C:\\Users\\\320\237\320\276\320\273\321\214\320\267\320\276\320\262\320\260\321\202\320\265\320\273\321\214/.ssh/id_ecdsa (0000000000000000)
debug2: key: C:\\Users\\\320\237\320\276\320\273\321\214\320\267\320\276\320\262\320\260\321\202\320\265\320\273\321\214/.ssh/id_ed25519 (0000000000000000)
debug2: key: C:\\Users\\\320\237\320\276\320\273\321\214\320\267\320\276\320\262\320\260\321\202\320\265\320\273\321\214/.ssh/id_xmss (0000000000000000)
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:5U76PQzmZJ7xce9TDvyt1P/sqNCX/GHOZSLk3TR3x1o C:\\Users\\\320\237\320\276\320\273\321\214\320\267\320\276\320\262\320\260\321\202\320\265\320\273\321\214/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: C:\\Users\\\320\237\320\276\320\273\321\214\320\267\320\276\320\262\320\260\321\202\320\265\320\273\321\214/.ssh/id_dsa

Можете подсказать что не так?

Какую команду используете для SSH подключения? Ключ добавлен в ssh-agent?
Попробуйте указать путь к вашему файлу с закрытым ключом вручную:
ssh root@192.168.1.90 -i "C:\Users\user1\.ssh\id_rsa"

Скорее всего вы запускали cmd\powershell.exe в режиме administrator, поэтому путь по-умолчанию был c:\windows\system32

А как это работает, если сервер на Linux, а клиент на Windows?

Да, все аналогично. Только в linux другое место хранения ключей (в зависимости от дистрибутива)

В файле authorized_keys можно указывать несколько ключей. Просто скопируйте значение второго ключа с новой строки и сохраните файл.

Читайте также: