Подключение по ssh с использованием ключей windows

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

В этой статье мы настроим 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 авторизации, вы должны будете вводить этот пароль. Я не стал указывать пароль для ключа (не рекомендуется).

windows ssh-keygen генерация пары 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 ключи в windows

После того, как ключи созданы, вы можете добавить закрытый ключ в службу 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 агент windows
Или так:

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 authorized_keys

Можно скопировать ключ на 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

включить ssh аутентфикацию по ключам в windows

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

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

Notepad C:ProgramDatasshsshd_config

PubkeyAuthentication yes

параметр PubkeyAuthentication yes в файле sshd_config

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

sshd_config отключить StrictModes

Сохраните файл и перезапустите службу 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>

первое подключение к windows по ssh добавить отпечаток ключа

При первом подключении нужно добавить отпечаток ключа 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 аутентфикации по ключу в event viewer windows 11

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

ssh подключение по ключу под администратором

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

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

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

файл administrators_authorized_keys ключи для ssh входа под локальными администраторами

Вы можете изменить 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"

настройка ntfs прав доступа к файлу administrators_authorized_keys для ssh доступа по ключам в windows

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

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

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

#Match Group administrators
# AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys

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).

ошибка ssh аутентфикации в windows по ключу Permission denied publickey keyboard interactive

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

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

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

Доступ по ключам к SSH серверу Windows 10

Введение

Начиная с вер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 сервер надо перезапустить.

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


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

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

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!

предыдущая глава | содержание | следующая глава

  • 8.1 Public key authentication — an introduction
  • 8.2 Using PuTTYgen, the PuTTY key generator
    • 8.2.1 Generating a new key
    • 8.2.2 Selecting the type of key
    • 8.2.3 Selecting the size (strength) of the key
    • 8.2.4 The «Generate» button
    • 8.2.5 The «Key fingerprint» box
    • 8.2.6 Setting a comment for your key
    • 8.2.7 Setting a passphrase for your key
    • 8.2.8 Saving your private key to a disk file
    • 8.2.9 Saving your public key to a disk file
    • 8.2.10 «Public key for pasting into OpenSSH authorized_keys file»
    • 8.2.11 Reloading a private key
    • 8.2.12 Dealing with private keys in other formats
  • 8.3 Getting ready for public key authentication

8.1 Public key authentication — an introduction

Public key authentication is an alternative means of identifying yourself to a login server, instead of typing a password. It is more secure and more flexible, but more difficult to set up.

In conventional password authentication, you prove you are who you claim to be by proving that you know the correct password. The only way to prove you know the password is to tell the server what you think the password is. This means that if the server has been hacked, or spoofed (see section 2.2), an attacker can learn your password.

Public key authentication solves this problem. You generate a key pair, consisting of a public key (which everybody is allowed to know) and a private key (which you keep secret and do not give to anybody). The private key is able to generate signatures. A signature created using your private key cannot be forged by anybody who does not have that key; but anybody who has your public key can verify that a particular signature is genuine.

So you generate a key pair on your own computer, and you copy the public key to the server. Then, when the server asks you to prove who you are, PuTTY can generate a signature using your private key. The server can verify that signature (since it has your public key) and allow you to log in. Now if the server is hacked or spoofed, the attacker does not gain your private key or password; they only gain one signature. And signatures cannot be re-used, so they have gained nothing.

There is a problem with this: if your private key is stored unprotected on your own computer, then anybody who gains access to that will be able to generate signatures as if they were you. So they will be able to log in to your server under your account. For this reason, your private key is usually encrypted when it is stored on your local machine, using a passphrase of your choice. In order to generate a signature, PuTTY must decrypt the key, so you have to type your passphrase.

This can make public-key authentication less convenient than password authentication: every time you log in to the server, instead of typing a short password, you have to type a longer passphrase. One solution to this is to use an authentication agent, a separate program which holds decrypted private keys and generates signatures on request. PuTTY’s authentication agent is called Pageant. When you begin a Windows session, you start Pageant and load your private key into it (typing your passphrase once). For the rest of your session, you can start PuTTY any number of times and Pageant will automatically generate signatures without you having to do anything. When you close your Windows session, Pageant shuts down, without ever having stored your decrypted private key on disk. Many people feel this is a good compromise between security and convenience. See chapter 9 for further details.

There is more than one public-key algorithm available. The most common are RSA and ECDSA, but others exist, notably DSA (otherwise known as DSS), the USA’s federal Digital Signature Standard. The key types supported by PuTTY are described in section 8.2.2.

8.2 Using PuTTYgen, the PuTTY key generator

PuTTYgen is a key generator. It generates pairs of public and private keys to be used with PuTTY, PSCP, and Plink, as well as the PuTTY authentication agent, Pageant (see chapter 9). PuTTYgen generates RSA, DSA, ECDSA, and Ed25519 keys.

When you run PuTTYgen you will see a window where you have two main choices: «Generate», to generate a new public/private key pair, or «Load» to load in an existing private key.

8.2.1 Generating a new key

This is a general outline of the procedure for generating a new key pair. The following sections describe the process in more detail.

  • First, you need to select which type of key you want to generate, and also select the strength of the key. This is described in more detail in section 8.2.2 and section 8.2.3.
  • Then press the «Generate» button, to actually generate the key. Section 8.2.4 describes this step.
  • Once you have generated the key, select a comment field (section 8.2.6) and a passphrase (section 8.2.7).
  • Now you’re ready to save the private key to disk; press the «Save private key» button. (See section 8.2.8).

Your key pair is now ready for use. You may also want to copy the public key to your server, either by copying it out of the «Public key for pasting into OpenSSH authorized_keys file» box (see section 8.2.10), or by using the «Save public key» button (section 8.2.9). However, you don’t need to do this immediately; if you want, you can load the private key back into PuTTYgen later (see section 8.2.11) and the public key will be available for copying and pasting again.

Section 8.3 describes the typical process of configuring PuTTY to attempt public-key authentication, and configuring your SSH server to accept it.

8.2.2 Selecting the type of key

Before generating a key pair using PuTTYgen, you need to select which type of key you need.

The current version of the SSH protocol, SSH-2, supports several different key types. PuTTYgen can generate:

  • An RSA key for use with the SSH-2 protocol.
  • A DSA key for use with the SSH-2 protocol.
  • An ECDSA (elliptic curve DSA) key for use with the SSH-2 protocol.
  • An Ed25519 key (another elliptic curve algorithm) for use with the SSH-2 protocol.

PuTTYgen can also generate an RSA key suitable for use with the old SSH-1 protocol (which only supports RSA); for this, you need to select the «SSH-1 (RSA)» option. Since the SSH-1 protocol is no longer considered secure, it’s rare to need this option.

8.2.3 Selecting the size (strength) of the key

The «Number of bits» input box allows you to choose the strength of the key PuTTYgen will generate.

  • For RSA, 2048 bits should currently be sufficient for most purposes.
  • For ECDSA, only 256, 384, and 521 bits are supported. (ECDSA offers equivalent security to RSA with smaller key sizes.)
  • For Ed25519, the only valid size is 256 bits.

8.2.4 The «Generate» button

Once you have chosen the type of key you want, and the strength of the key, press the «Generate» button and PuTTYgen will begin the process of actually generating the key.

First, a progress bar will appear and PuTTYgen will ask you to move the mouse around to generate randomness. Wave the mouse in circles over the blank area in the PuTTYgen window, and the progress bar will gradually fill up as PuTTYgen collects enough randomness. You don’t need to wave the mouse in particularly imaginative patterns (although it can’t hurt); PuTTYgen will collect enough randomness just from the fine detail of exactly how far the mouse has moved each time Windows samples its position.

When the progress bar reaches the end, PuTTYgen will begin creating the key. The progress bar will reset to the start, and gradually move up again to track the progress of the key generation. It will not move evenly, and may occasionally slow down to a stop; this is unfortunately unavoidable, because key generation is a random process and it is impossible to reliably predict how long it will take.

When the key generation is complete, a new set of controls will appear in the window to indicate this.

8.2.5 The «Key fingerprint» box

The «Key fingerprint» box shows you a fingerprint value for the generated key. This is derived cryptographically from the public key value, so it doesn’t need to be kept secret; it is supposed to be more manageable for human beings than the public key itself.

The fingerprint value is intended to be cryptographically secure, in the sense that it is computationally infeasible for someone to invent a second key with the same fingerprint, or to find a key with a particular fingerprint. So some utilities, such as the Pageant key list box (see section 9.2.1) and the Unix ssh-add utility, will list key fingerprints rather than the whole public key.

8.2.6 Setting a comment for your key

If you have more than one key and use them for different purposes, you don’t need to memorise the key fingerprints in order to tell them apart. PuTTYgen allows you to enter a comment for your key, which will be displayed whenever PuTTY or Pageant asks you for the passphrase.

The default comment format, if you don’t specify one, contains the key type and the date of generation, such as rsa-key-20011212. Another commonly used approach is to use your name and the name of the computer the key will be used on, such as simon@simons-pc.

To alter the key comment, just type your comment text into the «Key comment» box before saving the private key. If you want to change the comment later, you can load the private key back into PuTTYgen, change the comment, and save it again.

8.2.7 Setting a passphrase for your key

The «Key passphrase» and «Confirm passphrase» boxes allow you to choose a passphrase for your key. The passphrase will be used to encrypt the key on disk, so you will not be able to use the key without first entering the passphrase.

When you save the key, PuTTYgen will check that the «Key passphrase» and «Confirm passphrase» boxes both contain exactly the same passphrase, and will refuse to save the key otherwise.

If you leave the passphrase fields blank, the key will be saved unencrypted. You should not do this without good reason; if you do, your private key file on disk will be all an attacker needs to gain access to any machine configured to accept that key. If you want to be able to log in without having to type a passphrase every time, you should consider using Pageant (chapter 9) so that your decrypted key is only held in memory rather than on disk.

Under special circumstances you may genuinely need to use a key with no passphrase; for example, if you need to run an automated batch script that needs to make an SSH connection, you can’t be there to type the passphrase. In this case we recommend you generate a special key for each specific batch script (or whatever) that needs one, and on the server side you should arrange that each key is restricted so that it can only be used for that specific purpose. The documentation for your SSH server should explain how to do this (it will probably vary between servers).

Choosing a good passphrase is difficult. Just as you shouldn’t use a dictionary word as a password because it’s easy for an attacker to run through a whole dictionary, you should not use a song lyric, quotation or other well-known sentence as a passphrase. DiceWare (www.diceware.com) recommends using at least five words each generated randomly by rolling five dice, which gives over 2^64 possible passphrases and is probably not a bad scheme. If you want your passphrase to make grammatical sense, this cuts down the possibilities a lot and you should use a longer one as a result.

Do not forget your passphrase. There is no way to recover it.

8.2.8 Saving your private key to a disk file

Once you have generated a key, set a comment field and set a passphrase, you are ready to save your private key to disk.

Press the «Save private key» button. PuTTYgen will put up a dialog box asking you where to save the file. Select a directory, type in a file name, and press «Save».

This file is in PuTTY’s native format (*.PPK); it is the one you will need to tell PuTTY to use for authentication (see section 4.23.8) or tell Pageant to load (see section 9.2.2).

8.2.9 Saving your public key to a disk file

RFC 4716 specifies a standard format for storing SSH-2 public keys on disk. Some SSH servers (such as ssh.com‘s) require a public key in this format in order to accept authentication with the corresponding private key. (Others, such as OpenSSH, use a different format; see section 8.2.10.)

To save your public key in the SSH-2 standard format, press the «Save public key» button in PuTTYgen. PuTTYgen will put up a dialog box asking you where to save the file. Select a directory, type in a file name, and press «Save».

You will then probably want to copy the public key file to your SSH server machine. See section 8.3 for general instructions on configuring public-key authentication once you have generated a key.

If you use this option with an SSH-1 key, the file PuTTYgen saves will contain exactly the same text that appears in the «Public key for pasting» box. This is the only existing standard for SSH-1 public keys.

8.2.10 «Public key for pasting into OpenSSH authorized_keys file»

The OpenSSH server, among others, requires your public key to be given to it in a one-line format before it will accept authentication with your private key. (SSH-1 servers also used this method.)

The «Public key for pasting into OpenSSH authorized_keys file» gives the public-key data in the correct one-line format. Typically you will want to select the entire contents of the box using the mouse, press Ctrl+C to copy it to the clipboard, and then paste the data into a PuTTY session which is already connected to the server.

See section 8.3 for general instructions on configuring public-key authentication once you have generated a key.

8.2.11 Reloading a private key

PuTTYgen allows you to load an existing private key file into memory. If you do this, you can then change the passphrase and comment before saving it again; you can also make extra copies of the public key.

To load an existing key, press the «Load» button. PuTTYgen will put up a dialog box where you can browse around the file system and find your key file. Once you select the file, PuTTYgen will ask you for a passphrase (if necessary) and will then display the key details in the same way as if it had just generated the key.

If you use the Load command to load a foreign key format, it will work, but you will see a message box warning you that the key you have loaded is not a PuTTY native key. See section 8.2.12 for information about importing foreign key formats.

8.2.12 Dealing with private keys in other formats

SSH-2 private keys have no standard format. OpenSSH and ssh.com have different formats, and PuTTY’s is different again. So a key generated with one client cannot immediately be used with another.

Using the «Import» command from the «Conversions» menu, PuTTYgen can load SSH-2 private keys in OpenSSH’s format and ssh.com‘s format. Once you have loaded one of these key types, you can then save it back out as a PuTTY-format key (*.PPK) so that you can use it with the PuTTY suite. The passphrase will be unchanged by this process (unless you deliberately change it). You may want to change the key comment before you save the key, since some OpenSSH key formats contained no space for a comment, and ssh.com‘s default comment format is long and verbose.

PuTTYgen can also export private keys in OpenSSH format and in ssh.com format. To do so, select one of the «Export» options from the «Conversions» menu. Exporting a key works exactly like saving it (see section 8.2.8) — you need to have typed your passphrase in beforehand, and you will be warned if you are about to save a key without a passphrase.

For OpenSSH there are two options. Modern OpenSSH actually has two formats it uses for storing private keys. «Export OpenSSH key» will automatically choose the oldest format supported for the key type, for maximum backward compatibility with older versions of OpenSSH; for newer key types like Ed25519, it will use the newer format as that is the only legal option. If you have some specific reason for wanting to use OpenSSH’s newer format even for RSA, DSA, or ECDSA keys, you can choose «Export OpenSSH key (force new file format)».

Most clients for the older SSH-1 protocol use a standard format for storing private keys on disk. PuTTY uses this format as well; so if you have generated an SSH-1 private key using OpenSSH or ssh.com‘s client, you can use it with PuTTY, and vice versa. Hence, the export options are not available if you have generated an SSH-1 key.

8.3 Getting ready for public key authentication

Connect to your SSH server using PuTTY with the SSH protocol. When the connection succeeds you will be prompted for your user name and password to login. Once logged in, you must configure the server to accept your public key for authentication:

  • If your server is OpenSSH, you should change into the .ssh directory under your home directory, and open the file authorized_keys with your favourite editor. (You may have to create this file, if this is the first key you have put in it.) Then switch to the PuTTYgen window, select all of the text in the «Public key for pasting into OpenSSH authorized_keys file» box (see section 8.2.10), and copy it to the clipboard (Ctrl+C). Then, switch back to the PuTTY window and insert the data into the open file, making sure it ends up all on one line. Save the file.

    (In very old versions of OpenSSH, SSH-2 keys had to be put in a separate file called authorized_keys2. In all current versions, the same authorized_keys file is used for both SSH-1 and SSH-2 keys.)

  • If your server is ssh.com‘s product and is using SSH-2, you need to save a public key file from PuTTYgen (see section 8.2.9), and copy that into the .ssh2 directory on the server. Then you should go into that .ssh2 directory, and edit (or create) a file called authorization. In this file you should put a line like Key mykey.pub, with mykey.pub replaced by the name of your key file.
  • For other SSH server software, you should refer to the manual for that server.

You may also need to ensure that your home directory, your .ssh directory, and any other files involved (such as authorized_keys, authorized_keys2 or authorization) are not group-writable or world-writable; servers will typically ignore the keys unless this is done. You can typically do this by using a command such as

chmod go-w $HOME $HOME/.ssh $HOME/.ssh/authorized_keys

Your server should now be configured to accept authentication using your private key. Now you need to configure PuTTY to attempt authentication using your private key. You can do this in any of three ways:

  • Select the private key in PuTTY’s configuration. See section 4.23.8 for details.
  • Specify the key file on the command line with the -i option. See section 3.8.3.18 for details.
  • Load the private key into Pageant (see chapter 9). In this case PuTTY will automatically try to use it for authentication if it can.

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

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

  • Создание SSH-ключей в Linux на примере CentOS
  • Создание SSH-ключей в Windows с PuTTYgen
  • Отключение аутентификации по паролю

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

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

yum -y install openssh-server openssh-clients

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

ssh-keygen

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

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

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

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

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

cat ~/.ssh/id_rsa.pub | ssh root@ip-адрес-сервера 'cat >> ~/.ssh/authorized_keys'

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

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

echo ssh-rsa строка-публичного-ключа >> /root/.ssh/authorized_keys

Теперь можно отключить на сервере аутентификацию по паролю и использовать только 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 для редактирования.

vi /etc/ssh/sshd_config

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

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

service sshd restart

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

В случае успешной аутентификации по SSH-ключу вы получите доступ к командной строке сервера и сообщение вида Authenticating with public key «rsa-key-20170510», где rsa-key-20170510 — имя применённого закрытого ключа, указанное вами в файле authorized_keys.

Этот материал был полезен?

Понравилась статья? Поделить с друзьями:
  • Подключение через wan miniport pppoe ошибка 651 как исправить windows
  • Подключение по ssh без пароля windows
  • Подключение по rdp без пароля windows 10
  • Подключение физического диска к virtualbox windows
  • Подключение по rdp linux к windows server