Подключение по ssh без пароля windows - Доктор Windows

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

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

Содержание:

Генерация SSH ключей на клиенте Windows
Настройка OpenSSH в Windows для авторизации по ключам
Вход по SSH ключу для локальных администраторов Windows

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

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

В Windows 10/11 и Windows Server 2019/2022 клиент OpenSSH устанавливается как отдельный встроенный компонент с помощью PowerShell:

Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

Запустите обычную (непривилегированную сессию PowerShell) и сгенерируйте пару ED25519 ключей:

ssh-keygen -t ed25519

По умолчанию утилита ssh-keygen генерирует ключи RSA 2048. В настоящий момент вместо RSA ключей рекомендуется использовать именно ED25519.

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

Generating public/private ed25519 key pair. Enter file in which to save the key (C:Usersmyuser/.ssh/id_ed25519):  

Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in C:Usersmyuser/.ssh/id_ed25519. Your public key has been saved in C:Usersmyuser/.ssh/id_ed25519.pub. The key fingerprint is: SHA256:C2wXeCQSUcJyq0 [email protected] The key's randomart image is: +--[ED25519 256]--+ | ..*O=..o. | +----[SHA256]-----+

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

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

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

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

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

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

ssh-add "C:Usersuser.sshid_ed25519"

Identity added: C:Userskbuldogov.sshid_ed25519 ([email protected])

Или так:

ssh-add.exe $ENV:UserProfile.sshid_ed25519

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

SSH сервер (в этом примере это удаленный компьютер с Windows 11 и настроенной службой OpenSSH).

Скопируйте файл id_ed25519.pub в каталог .ssh профиля пользователя, под которым вы будете подключаться к SSH серверу. Например, у меня в Windows 11 создан пользователь user1, значит я должен скопировать ключ в файл C:Usersuser1.sshauthorized_keys.

В данном примере подразумевается, что user1 это обычная учетная запись пользователя без прав локального администратора на компьютере с сервером SSH.

Если каталог .ssh в профиле отсутствует, его нужно создать вручную.

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

scp C:Usersyouruser.sshid_rsa.pub [email protected]:c:usersuser1.sshauthorized_keys

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

По умолчанию в OpenSSH сервере в Windows отключена аутентификация по ключам. Вы можете проверить это в конфигурационном файле sshd_config. Проще всего получить список разрешенных способов аутентификации в OpenSSH с помощью такой PowerShell команды (Select-String используется как аналог grep в PowerShell):

cat "C:ProgramDatasshsshd_config"| Select-String "Authentication"

#PubkeyAuthentication yes
#HostbasedAuthentication no
# HostbasedAuthentication
 PasswordAuthentication yes
#GSSAPIAuthentication no

В этом примере строка PubkeyAuthentication закомментирована, значит этот способ аутентификации отключен.

Откройте файл sshd_config с помощью блокнота, раскоментируйте строку:

Notepad C:ProgramDatasshsshd_config

PubkeyAuthentication yes

Также в конфигурационном файле sshd_config придется отключить режим StrictModes. По умолчанию этот режим включен и запрещает аутентификацию по ключам, если закрытый и открытый ключ недостаточно защищены. Раскомментируйте строку
#StrictModes yes
, измените на
StrictModes no
.

Сохраните файл и перезапустите службу sshd:

Restart-Service sshd

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

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

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

Например,

ssh [email protected]

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

Если вы не хотите использовать ssh-agent для управления ключами, вы можете указать путь к закрытому ключу, который нужно использовать для SSH аутентификации:
ssh [email protected] -i "C:Usersuser.sshid_ed25519"
Для подключения с помощью учетной записи пользователя из домена Active Directory используется формат:
ssh [email protected]@168.1.90 -i <private_key_absolute_path>

При первом подключении нужно добавить отпечаток ключа SSH сервера в доверенные. Наберите yes -> Enter.

The authenticity of host '192.168.1.90 (192.168.1.90)' can't be established.
ECDSA key fingerprint is SHA256:LNMJTbTS0EmrsGYTHB3Aa3Tisp+7fvHwZHbTA900ofw.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes

Информацию по аутентификации в Windows с помощью SSH ключей можно найти в журнале события. В современных версиях OpenSSH логи пишутся не в текстовые файлы, а в отдельный журнал Event Viewer (Application and services logs -> OpenSSH -> Operational).

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

EventID 4
sshd: Accepted publickey for locadm from 192.168.14.1 port 55772 ssh2: ED25519 SHA256:FEHDWM/J74FbIzCCoJNbh14phS67kQgh7k8UrKPSvCM

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

Вход по SSH ключу для локальных администраторов Windows

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

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

Вы можете изменить NTFS права на файл с помощью:

утилиты icacls:
icacls.exe "C:ProgramDatasshadministrators_authorized_keys" /inheritance:r /grant "Administrators:F" /grant "SYSTEM:F
или с помощью PowerShell командлетов get-acl и set-acl:
get-acl "$env:programdatasshssh_host_rsa_key" | set-acl "$env:programdatasshadministrators_authorized_keys"

После этого SSH аутентификация по ключам работает даже при отключенном режиме StrictModes

alert]Чтобы использовать ключ authorized_keys из профиля пользователя, и не переносить данные открытого ключа в файл administrators_authorized_keys, вы можете закомментировать строку в файле конфигурации OpenSSH (C:ProgramDatasshsshd_config).

Закомментируйте строки:

#Match Group administrators
# AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys

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

PasswordAuthentication no

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

restart-service sshd

Если вы установили PasswordAuthentication no, и некорректно настроите аутентификацию по ключам, то при подключении по ssh будет появляться ошибка:

[email protected]: Permission denied (publickey,keyboard-interactive).

В OpenSSH на Linux доступна опция PermitRootLogin, позволяющая ограничить доступ к SSH серверу под аккаунтом root. В Windows OpenSSH эта директива не доступна и для ограничения доступа администраторов нужно использовать параметр DenyGroups.

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

Источник

I am trying to use ssh/scp from Windows to Linux without having to enter a password.

This is what I have done, and it doesn’t seem to work:

generated public and private keys using Putty Key Generator (on Windows)
saved the files as id_rsa.pub and id_rsa
copied them into ~/.ssh
added id_rsa.pub to the Linux box in ~/.ssh/authorized_keys
I then try to ssh to the Linux box from Windows and I still have to enter a password

Am I missing something?

asked Jan 13, 2010 at 16:44

You have to run an authentication agent on Windows.

For example, Pageant, used in combination with PuTTY (graphical SSH client) or Plink (its command line equivalent).

You’ll need to tell Pageant your SSH server’s public key. After that it will deal with your server’s authentication requests while running in the background.

answered Jan 13, 2010 at 16:50

Silvio DonniniSilvio Donnini

8222 gold badges8 silver badges10 bronze badges

Giri

5592 silver badges7 bronze badges

answered Jan 13, 2010 at 16:49

EduardoEduardo

2272 silver badges5 bronze badges

I used this:

c:> type c:usersmy_name.sshid_rsa.pub | ssh root@172.110.1.171 "cat >> ~/.ssh/authorized_keys"

Mtl Dev

3351 gold badge3 silver badges12 bronze badges

answered Jun 9, 2019 at 19:53

Try Plink (part of PuTTY)

 plink -v youruser@yourhost.com -pw yourpw "some linux command"

answered Jan 13, 2010 at 16:50

Setting up SSH key authentication can be a bit tricky. It sounds like you’re covering all your bases. One thing that often catches people off guard — you need to make sure the .ssh directory and its contents are owned by you and are read/writeably only by you.

Make sure to run this (on all your .ssh directories):

chmod -R 700 on ~/.ssh

If that doesn’t work, turn on verbose logging by adding -v to your ssh command (you can add up to three -vss for more verbosity).

answered Jan 13, 2010 at 16:57

rcw3rcw3

1413 bronze badges

I’m assuming your keys are not password protected, and what you’re getting is not a request for your key’s password.

~/.ssh isn’t used by putty on the windows side, and putty doesn’t have a default private key setting. If you’re using a command line ssh client such as cygwin, creating a .ssh directory off of your home would work. From putty, you’ll need to configure and save a session.

From the putty configuration dialog, look at connection -> data, and fill in the auto-login username field. Then go to connection -> ssh -> auth, and set your private key correctly. Then go back to the session dialog, and save this session. You can also set the hostname if you’d like.

Once you have a saved session, you can use ‘putty -load «savedsession»‘.

answered Jan 18, 2010 at 19:31

You may also need to change permissions on your home directory:

chmod 755 ~

answered Aug 4, 2010 at 12:18

HaydnHaydn

211 bronze badge

git for Windows installs the cross-platform ssh tools you need:

ssh-keygen
ssh-copy-id.

Depending your preference of bash or PowerShell,

Either do this from the git-installed bash shell:

#By default this puts keyfile pair in ~/.ssh/id_rsa & ~/.ssh/id_rsa.pub :

ssh-keygen.exe -t rsa -b 2048 
ssh-copy-id -i ~/.ssh/id_rsa.pub  $remoteuser@$remotehost

# These two chmod lines are needed on unix platforms, probably not on Windows. 
# typically ssh refuses to use a private key file 
# if it is less-well protected than this:
chmod 700 ~/.ssh
chmod 640 ~/.ssh/id_rsa

Or run this script in PowerShell:

Param(
  [Parameter()][string]$keyfile="id_rsa",
  [Parameter()][string]$remotehost,
  [Parameter()][string]$remoteuser
  )
write-host "# ---------------------------------------------------------------------------------#"
write-host "# Create an RSA public/private key pair, and copy the public key to remote server  #"
write-host "#                                                                                  #"
write-host "# https://superuser.com/questions/96051                                            #"
write-host "#         ssh-from-windows-to-linux-without-entering-a-password/1194805#1194805    #"
write-host "#                                                                                  #"
write-host "# ---------------------------------------------------------------------------------#"

write-host "Keyfile pair will be saved at : ~/.ssh/$keyfile, ~/.ssh/$keyfile.pub"
write-host "And copied to $remoteuser@$remotehost"
write-host ""
write-host "You will need a password for the copy operation."
write-host ""

if( -not $(ls ~/.ssh) ) { mkdir ~/.ssh }
$sshdir=$(get-item ~/.ssh/).Fullname

#By default this puts keyfile pair in ~/.ssh/id_rsa & ~/.ssh/id_rsa.pub :
ssh-keygen.exe -t rsa -b 2048 -f "$sshdir$keyfile"

# ssh-copy-id somehow didn't work in Powershell so I called it via bash
bash -c "ssh-copy-id -i ~/.ssh/$keyfile.pub $remoteuser@$remotehost"

# I'm not sure if these two chmod lines work on windows but 
# typically ssh refuses to use a private key file 
# if it is less-well protected than this:
chmod.exe 700 $sshdir
chmod.exe 640 "$sshdir$keyfile"

After this, passwordless login should work for both ssh and scp.

answered Apr 2, 2017 at 17:28

I was able to do this exactly from Windows 7 by using the -i option for supplying an identity private key:

ssh -i X:win-pathtoprivate-key remoteuser@remote.host.com

except that on the remote host, my authorized keys are in /etc/ssh/authorized_keys/remoteuser and in /etc/ssh/sshd_config, I changed

#AuthorizedKeysFile     .ssh/authorized_keys
AuthorizedKeysFile      /etc/ssh/authorized_keys/%u

but I don’t know if the SSH remote config should matter.

answered Oct 25, 2017 at 21:46

amphibientamphibient

2,1139 gold badges29 silver badges41 bronze badges

Источник

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

Введение

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

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

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

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

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

ssh-keygen -t rsa

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

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

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

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

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

ssh-copy-id user_name@server_name_or_ip

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

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

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

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

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

ssh user_name@domain_name@host_name "mkdir C:\users\user_name\.ssh\"

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

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

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

scp ~/.ssh/public_key_file_name.pub user_name@domain_name@host_name:C:Usersuser_name.sshauthorized_keys

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

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

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

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

Естественно, возникает вопрос, как это можно сделать. И на этот вопрос существует множество ответов. Например, если у вас есть доступ к удалённому хосту по RDP, то можно отредактировать на нём файл authorized_keys с помощью того же notepad-а, добавив содержимое своего файла с публичным ключом. Или же, можно скопировать свой файл с публичным ключом на нужный сервер и объединить его с существующим файлом, а затем — удалить (конечно, при этом у вас, вернее, у вашего пользователя на удалённом компьютере, должны быть права на редактирование файла authorized_keys):

scp ~/.ssh/id_rsa.pub user_name@domain_name@host_name:C:/Users/user_name/.ssh/my_public_key_file_name.pub
ssh user_name@domain_name@host_name "type C:\Users\user_name\.ssh\my_public_key_file_name.pub >> C:\Users\user_name\.ssh\authorized_keys"
ssh user_name@domain_name@host_name "del /Q C:\Users\user_name\.ssh\my_public_key_file_name.pub"

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

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

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

ssh --% user_name@domain_name@host_name powershell -c $ConfirmPreference = 'None'; Repair-AuthorizedKeyPermission C:Usersuser_name.sshauthorized_keys

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

Install-Module -Force OpenSSHUtils -Scope AllUsers

Так вот, когда я запустил эту команду, ответом мне стало сообщение об ошибке:

Совпадения для указанных условий поиска и имени пакета "OpenSSHUtils" не найдены.

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

Суть в том, что Windows 10 предъявляет определённые требования к безопасности файла authorized_keys (на самом деле, к безопасности публичных ключей). Причины, по которым это происходит, наверное, не надо объяснять. Так вот, в документации Microsoft указывается, что при использовании Windows 10 доступ может быть предоставлен только администаторам и специальному пользователю SYSTEM. Там же советуется использовать модуль OpenSSHUtils, который должен оказать помощь при установке нужных прав. Собственно, при использовании предложенного в документации подхода я и наткнулся на ошибку. Но кроме документации от Microsoft я нашёл довольно много информации о проблемах, вызванных использованием этого модуля. Если попробовать кратко изложить содержимое ответов на возникающие у пользователей вопросы и проблемы, то получится что-то типа:

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

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

$acl = Get-Acl C:Usersuser_name.sshauthorized_keys
$acl.SetAccessRuleProtection($true, $false)
$adminsRule = New-Object system.security.accesscontrol.filesystemaccessrule("Администраторы","FullControl","Allow")
$sysRule = New-Object system.security.accesscontrol.filesystemaccessrule("SYSTEM","FullControl","Allow")
$acl.SetAccessRule($adminsRule)
$acl.SetAccessRule($sysRule)
Set-Acl -Path C:Usersuser_name.sshauthorized_keys -AclObject $acl

Теперь, как и обещал, небольшие пояснения по командам. Итак, для начала, при помощи 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:ProgramDatasshadministrators_authorized_keys.

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

scp ~/.ssh/id_rsa.pub user_name@domain_name@host_name:C:/Users/user_name/.ssh/my_public_key_file_name.pub
ssh user_name@domain_name@host_name "type C:\Users\user_name\.ssh\my_public_key_file_name.pub >> C:\ProgramData\ssh\administrators_authorized_keys"
ssh user_name@domain_name@host_name "del /Q C:\Users\user_name\.ssh\my_public_key_file_name.pub"
$acl = Get-Acl C:ProgramDatasshadministrators_authorized_keys
$acl.SetAccessRuleProtection($true, $false)
$adminsRule = New-Object system.security.accesscontrol.filesystemaccessrule("Администраторы","FullControl","Allow")
$sysRule = New-Object system.security.accesscontrol.filesystemaccessrule("SYSTEM","FullControl","Allow")
$acl.SetAccessRule($adminsRule)
$acl.SetAccessRule($sysRule)
Set-Acl -Path C:ProgramDatasshadministrators_authorized_keys -AclObject $acl

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

...
Match Group administrators
       AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys
...

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

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

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

Subscribe to Записки на полях

Get the latest posts delivered right to your inbox

Great! Check your inbox and click the link to confirm your subscription.

Please enter a valid email address!

Источник

If you’re tired of putting a password everything you login via SSH into your server via ssh root@your_server, there are ways to automatically login to your server without requiring you input a password. This is by using the built-in ssh-keygen command available in your Windows 10.

Basically, the ssh-keygen will create an authentication key pairs that you can use for Secure Shell protocol login.

To start, open up a command prompt on your Windows 10. Type in your Cortana CMD.

Now, enter the command ssh-keygen, this will asked to enter a file name for it, make sure to leave it as blank so that it will save the pair as the default filename id_rsa:

Generating public/private rsa key pair.
Enter file in which to save the key (C:UsersYOUR_USERNAME/.ssh/id_rsa):

Now, you’ll be asked to enter a passphrase. To improved security of your RSA key pair add your passphrase in it. You’ll also be asked to re-enter it again.

Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in C:UsersYOUR_USERNAME/.ssh/id_rsa.
Your public key has been saved in C:UsersYOUR_USERNAME/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:3lk4xS/1udKUWtPqo1BtSFpGIufIlZYLhEHxOtiXDQI YOUR_USERNAME@YOUR_DESKTOP
The key's randomart image is:
+---[RSA 2048]----+
|  .  .+=o +=o   o|
|   .  .o.*+o=  +.|
|    . o oo.*o+=.o|
|   o o o  o.o+=+.|
|  . + o S .. o..+|
|     o o o.   o o|
|        o  . . . |
|            .    |
|                 |
+----[SHA256]-----+

It will then create the id_rsa and id_rsa.pub file in your C:UsersYOUR_USERNAME.ssh directory and in the command screen it will show a randomart image.

Since ssh-copy-id is not a built-in command in Windows 10 (See explanation at the bottom), you need to manually add your public key to your server.

open up the id_rsa.pub file with a notepad and copy the whole text. The file is in C:UsersYOUR_USERNAME.ssh folder. Example id_rsa.pub file below.

ssh-rsa AAAAC3NzaC1yc2EAAAADAQABAABBAQDs4aYDW+/XeeewahNS3JO9lxxREYdEcJEccQIMHixnVcaQOzXwiNIJ5HNbHpv5lk2YgcPSffPLcX6lQruLbSt3HDjNl3Q76P81xuPUscCeP37ulZXVuQoaWeqTlW36AXWeZsqQowLxih8+ydl2FlIv/Zytv2AAJk3SKEiGuDBJciCAvVTgb0bNGn93X3tohBpM79mRWuCCWSoRbi+u8kumUpt9eeXgmte82UI9JVKb0qj/G3XJp84s0Evtk7L+HhZ+/v6VmfQCsC/lrOKwGezbVGwI/3Xz64kudCmvkfmWOEGFOG+v0MMCA91mDrKr4Tc7nj6yYTE1kIm0y3DdLS7l YOUR_USERNAME@YOUR_DESKTOP

Now, you need to login to your server via SSH with password as of now ssh root@YOUR_SERVER. Then you need to edit or make a file authorized_keys via vim. Enter this command:

vim ~/.ssh/authorized_keys

Then paste the content of your id_rsa.pub on it or if it has existing keys, just paste it on the bottom. Then don’t forget to save it :wq.

If you have problem where there is ^M showing, especially if there are existing keys, just type this command e ++ff=dos and those ^M will be converted to normal lines.

After that, you can now login to your CMD via ssh root@YOUR_SERVER without requiring for entering your password.

SSH-Copy-ID is not available on Windows 10

The only problem with windows 10 is there is no ssh-copy-id command available in the OS and you need to manually add the pair into your server. You’ll get an error ‘ssh-copy-id’ is not recognized as an internal or external command, operable program or batch file.’ when you try to input it.

Load Key Operation not Permitted

If you’re getting an error saying “Load key “C:UsersYOUR_USERNAME/.ssh/id_rsa”: Operation not permitted”, this means you’re trying to create a folder in your .ssh directory named id_rsa.

Some people create these folder because they though the key was saved in that folder when they entered the ssh-keygen which says the following:

Generating public/private rsa key pair.
Enter file in which to save the key (C:UsersYOUR_USERNAME/.ssh/id_rsa): sample
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in sample.
Your public key has been saved in sample.pub.

This happens, when you named the file when saving the ssh-keygen, make sure to leave it as blank to make sure the private key is save as the default id_rsa and id_rsa.pub.

Источник