Windows ssh connect with key

В этой статье мы настроим 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:\Users\myuser/.ssh/id_ed25519):  

Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in C:\Users\myuser/.ssh/id_ed25519. Your public key has been saved in C:\Users\myuser/.ssh/id_ed25519.pub. The key fingerprint is: SHA256:C2wXeCQSUcJyq0 myuser@computername 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:\Users\user\.ssh\id_ed25519"

Identity added: C:\Users\kbuldogov\.ssh\id_ed25519 (kbuldogov@computername)

добавить ключ в ssh агент windows
Или так:

ssh-add.exe $ENV:UserProfile\.ssh\id_ed25519

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

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

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

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

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

файл с открытым ключом на сервере ssh authorized_keys

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

scp C:\Users\youruser\.ssh\id_rsa.pub [email protected]:c:\users\user1\.ssh\authorized_keys

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

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

cat "C:\ProgramData\ssh\sshd_config"| Select-String "Authentication"

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

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

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

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

Notepad C:\ProgramData\ssh\sshd_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:\Users\user\.ssh\id_ed25519"
  • Для подключения с помощью учетной записи пользователя из домена Active Directory используется формат:
    ssh kbu[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:\ProgramData\ssh\administrators_authorized_keys. Вам нужно добавить ваш ключ в этот текстовый файл (в целях безопасности права на этот файл должны быть только у группы Administrators и SYSTEM).

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

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

  • утилиты icacls:
    icacls.exe "C:\ProgramData\ssh\administrators_authorized_keys" /inheritance:r /grant "Administrators:F" /grant "SYSTEM:F
  • или с помощью PowerShell командлетов get-acl и set-acl:
    get-acl "$env:programdata\ssh\ssh_host_rsa_key" | set-acl "$env:programdata\ssh\administrators_authorized_keys"

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

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

alert]Чтобы использовать ключ authorized_keys из профиля пользователя, и не переносить данные открытого ключа в файл administrators_authorized_keys, вы можете закомментировать строку в файле конфигурации OpenSSH (C:\ProgramData\ssh\sshd_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:\Users\user_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:\Users\user_name\.ssh\authorized_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:\Users\user_name\.ssh\authorized_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:\Users\user_name\.ssh\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:\Users\user_name\.ssh\authorized_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:\ProgramData\ssh\administrators_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:\ProgramData\ssh\administrators_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:\ProgramData\ssh\administrators_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!

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

Что такое SSH-ключ

Аббревиатура SSH означает Secure Shell, что дословно переводится как «безопасная оболочка». Если говорить точнее, SSH — это защищенный сетевой протокол с проверкой подлинности и шифрованием. Он используется для передачи файлов, управления сетью и удаленного доступа к операционной системе. Аббревиатура SSH также используется для описания набора инструментов, используемых для взаимодействия с одноименным протоколом.

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

Так как SSH работает по системе «клиент-сервер», обязательное условие для работы этого протокола — наличие на удаленном узле демона SSH. Демон SSH — это ПО, которое прослушивает определенный сетевой порт и при прохождении аутентификации другим узлом создает необходимую среду для работы с ним.

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

Пользователи Linux могут установить OpenSSH с помощью команды:

sudo apt-get install ssh

В некоторых ОС компоненты OpenSSH можно установить отдельно для клиента  openssh-client и отдельно для сервера openssh-server.

Структура ключа

Можно сказать, что определение «SSH-ключ» составное, так как на самом деле это два ключа — открытый и закрытый. На узле A создаются и хранятся оба ключа, а на узел B передается только копия публичного SSH-ключа, что позволяет подключаться к узлу B с узла A.

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

  • id_rsa — закрытый ключ,
  • id_rsa.pub — публичный (открытый) ключ.

В чем же разница открытого и закрытого ключа?

Открытые и закрытые SSH-ключи

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

Закрытый (приватный) SSH-ключ — это ключ к данным. Он расшифровывает сами сообщения. Хранится он на устройстве, которое будет подключаться к удаленному узлу (на котором находится открытый ключ). Приватный ключ ни в коем случае нельзя передавать в чужие руки, в том числе через мессенджеры или файлообменники, во избежание утечки информации и персональных данных. Также рекомендуем сразу установить пароль на закрытый ключ, чтобы обеспечить ему дополнительную защиту.

Как работает SSH-авторизация?

Давайте представим, что Selectel — это сервер, а вы — клиент. Вы хотите подключиться к нам с использованием SSH-ключа. Предварительно вы уже создали пару ключей и передали публичный ключ нам. Алгоритм взаимодействия будет следующим:

  1. Вы должны изъявить свое желание подключиться к нам, то есть отправить запрос на подключение по TCP-порту.
  2. В случае установки TCP-соединения мы бмениваемся информацией о версиях наших  SSH-протоколов. С помощью этой информации можно понять, какую именно конфигурацию (версию протоколов и алгоритмы работы) использовать. Самостоятельно узнать версию OpenSSH можно с помощью команды ssh -V.
  3. После согласования мы (сервер) направляем вам (клиенту) открытый ключ. Теперь уже вы решаете, доверять такому ключу или нет. В случае положительного ответа мы с вами генерируем сеансовый ключ, который будет использоваться для симметричного шифрования канала. Этот ключ существует, только пока существует канал (текущая сессия).
  4. Теперь следует аутентифицировать вас. Для этого вы отсылаете нам свой открытый ключ. Мы в свою очередь проверяем его со своим списком открытых SSH-ключей. Если совпадение найдено, мы генерируем случайное число, шифруем его открытым ключом и отправляем обратно. Вы как клиент расшифровываете сообщение закрытым ключом и отправляете полученные данные нам. В случае совпадения присланного числа с первоначальным аутентификация признается успешной. 

Поздравляем! Теперь вам открыт доступ на сервер.

Алгоритм SSH-авторизации

Типы ключей SSH

Как вы уже знаете, существуют два основных типа ключей — открытый и закрытый. Но также ключи можно разделить по типу шифрования.

Если мы введем в терминал команду ssh-keygen ?, то увидим справку, где у параметра -t указаны алгоритмы, которые можно использовать в данной системе:

~# ssh-keygen ?
…
[-t dsa | ecdsa | ecdsa-sk | ed25519 | ed25519-sk | rsa]

RSA — по умолчанию ssh-keygen использует в качестве параметра -t именно RSA, так как этот алгоритм обеспечивает наилучшую совместимость из всех, но требует большего размера ключа для обеспечения достаточной безопасности. Длина ключа по умолчанию составляет 3072 бит, но вы можете самостоятельно задать его размер от 1024 до 16384 бит с помощью опции -b команды ssh-keygen. 

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

DSA — криптографический алгоритм с использованием открытого ключа для создания электронной подписи, но не для шифрования. Это значит, что только один узел сможет подписать сообщение, а другие смогут только проверить ее на корректность. Алгоритм основан на вычислительной сложности взятия логарифмов в конечных полях. Алгоритм DSA в сравнении с RSA показывает лучшие показатели при генерации подписи, но уступает по времени при ее проверке. Также отметим, что максимальная длина ключа данного типа — 1024 бит. Это не самый безопасный показатель в защите от взлома.

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

ED25519 — это схема подписи на эллиптической кривой, которая обеспечивает лучшую безопасность, чем ECDSA и DSA, и хорошую производительность. Его главными преимуществами являются скорость. Однако данный алгоритм поддерживается только в версиях от OpenSSH 6.5.

ECDSA-SK и ED25519-SK — это те же ECDSA и ED25519, но поддерживающие аппаратный аутентификатор. Данные алгоритмы появились не так давно в версии OpenSSH 8.2. Они позволяют реализовать двухфакторную аутентификацию с помощью устройств, которые поддерживают протокол FIDO/U2F. Существует множество разновидностей физической аутентификации, например USB-токен, или другие виды устройств, подключаемые к оборудованию с помощью Bluetooth или NFC.

Добавить публичный ключ можно сразу при заказе сервера. Все добавленные ключи хранятся в разделе Серверы и оборудование → SSH-ключи.

Создание SSH-ключа

Параметры утилиты ssh-keygen

В Linux для создания SSH-ключей используется команда ssh-keygen. Далее приведены наиболее популярные параметры для этой команды и их описание.

-C comment

Создание нового комментария. Например, одной из самых известных команд является добавление комментария с информацией о том, кто, на какой машине и когда создал ключ:

ssh-keygen -C "$(whoami)@$(uname -n)-$(date -I)"

p

Если указать данный параметр при вводе ssh-keygen, то вам будет предложено изменить старую секретную фразу на новую. Ввод команды будет выглядеть следующим образом:

ssh-keygen -p

Также вы можете задать все параметры для изменения секретной фразы сразу:

ssh-keygen -p [-P old_passphrase] [-N new_passphrase] [-f keyfile]

t type

Задает тип создаваемого ключа. Чтобы узнать какие типы доступны для вашей версии, введите: 

ssh-keygen -t ?

-v

Подробный режим. ssh-keygen будет печатать отладочные сообщения о ходе выполнения. Несколько опций -v увеличивают степень подробности информации (максимум 3).

Генерация SSH-ключей в Linux

Процесс создания SSH-ключей на базе Linux предельно прост. Вам необходимо лишь указать некоторые параметры, которые мы опишем далее.

Мы будем создавать ключ RSA. При вводе команды ssh-keygen опцию -t RSA можно не указывать явно, так как RSA является алгоритмом по умолчанию.

~# ssh-keygen
Generating public/private RSA key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):

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

Enter passphrase (empty for no passphrase):

В данной строке предлагается создать кодовую фразу. Оставив строку пустой, дополнительной защиты не будет. 

С одной стороны, не вводить кодовую фразу опасно. Если закрытый ключ попадет в руки злоумышленников, то у них может появиться доступ к серверу. В то же время, если вы введете кодовую фразу, в будущем это может доставить вам неудобства. Пароль придется вводить каждый раз при использовании SSH-подключения с этим ключом. Поэтому использование кодовой фразы остается на ваше усмотрение.

Как мы упоминали ранее, кодовую фразу можно будет установить (или заменить) самостоятельно, введя ssh-keygen -p, когда ключ уже будет создан. 

Your identification has been saved in /root/.ssh/id_rsa
Your public key has been saved in /root/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:Uh6CVy4Voz0/70Am8j+hXOLBV21l4rMmiMLG5BTz3cE root@trexclient
The key's randomart image is:
+---[RSA 3072]----+
|    	=. . 	|
| 	.o* .  E . o|
|	. =+*. . + + |
| 	.o=.+. o =  |
| 	*o.S.=o . o |
|  	*+=+=o. o  |
| 	. +.*...o   |
|    	+..o 	|
|      	...	|
+----[SHA256]-----+

Созданные файлы хранятся в директории /home/*SystemName*/.ssh/.

Генерация SSH-ключей в Windows с помощью Putty

Если вы хотите создать SSH-ключи на базе ОС Windows, самым популярным решением для этого будет использование программного обеспечения Putty. Скачать его можно с официального сайта по ссылке (актуальная версия на момент написания статьи — Putty 0.78). После установки программы вам будет доступно несколько .exe файлов.

Для создания SSH-ключей откройте puttygen.exe, выберите необходимый тип ключа и задайте его размер. Мы будем использовать RSA с длиной 3072.

Генерация ключей в Putty

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

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

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

Выбор пути сохранения ключей

Putty сохраняет закрытые ключи с разрешением .ppk, что означает, что такой ключ можно будет использовать только с Putty. Чтобы сохранить секретный ключ в формате, пригодном для OpenSSH, нужно во вкладке Конвертация выбрать пункт «Экспортировать ключ в формате OpenSSH (новый формат)» и указать расположение нового файла (старый формат при конвертации из .pkk в OpenSSH сохраняет не все поля — например, комментарий).

Генерация SSH-ключей в Windows с помощью OpenSSH

Не так давно в ОС Windows добавили возможность использования инструментов OpenSSH. Пакет добавлен в ОС, начиная с Windows 10 и Windows Server 2019.

Установить клиент OpenSSH можно с помощью следующей команды в PowerShell:

Add-WindowsCapability -Online -Name OpenSSH.Client

Или же с помощью графического интерфейса: Параметры → Приложения → Дополнительные возможности → Добавить компонент. В списке предложенных компонентов необходимо найти Клиент OpenSSH и нажать кнопку Установить.

Проверить статус компонента можно командой:

Get-WindowsCapability -Online | ? Name -like 'OpenSSH.Client*'

Если в ответе команды статус Installed, то загрузка выполнена успешно.

Генерация SSH-ключей происходит таким же образом, как и в ОС Linux, с помощью ssh-keygen:

PS C:\Users\Administrator> ssh-keygen -t ed25519
Generating public/private ed25519 key pair.
Enter file in which to save the key (C:\Users\Administrator/.ssh/id_ed25519):
Created directory 'C:\Users\Administrator/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in C:\Users\Administrator/.ssh/id_ed25519.
Your public key has been saved in C:\Users\Administrator/.ssh/id_ed25519.pub.
The key fingerprint is:
SHA256:1qBO0MIgYM+A80G1zZgUzW4QCYHKNuLgwaIR77sY2/U administrator@winselectel
The key's randomart image is:
+--[ED25519 256]--+
|===+=*       	|
|*.=+oBo      	|
|+= +Bo+ .    	|
|**o  oo. o   	|
|Ooo  .o S .  	|
|.o.  o .     	|
|.  .. .      	|
| =.. .       	|
|o o.  E      	|
+----[SHA256]-----+

Созданные ключи можно найти в папке C:\Users\Administrator\.ssh, если она не была изменена при генерации.

Где можно найти созданные ключи

Копирование открытого ключа на сервер

В данном разделе мы рассмотрим общий вариант копирования открытого SSH-ключа на сервер.

Копирование при помощи SSH-Copy-ID

Данный метод подойдет тем, чья ОС поддерживает команду SSH-Copy-ID, и удаленный сервер имеет доступ по SSH без ключа. Если это не так, попробуйте использовать второй или третий способ.

Синтаксис команды выглядит следующим образом:

-# ssh-copy-id username@remote_host

Обратите внимание на последние строки вывода:

-# ssh-copy-id root@5.159.102.80
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/root/.ssh/id_rsa.pub"
The authenticity of host '5.159.102.80 (5.159.102.80)' can't be established.
ED25519 key fingerprint is SHA256:KSvVyjbijk+LQ7n3cEQd94qcyIcTDfaED+jRFzBBPGM.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Наш клиент запрашивает разрешение на продолжение подключения к удаленному узлу, так как встречает его впервые. Необходимо ввести yes. После успешного подключения ключи будут добавлены и мы увидим соответствующий вывод:

/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
root@5.159.102.80's password:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'root@5.159.102.80'"
and check to make sure that only the key(s) you wanted were added.

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

~# cat /root/.ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCoQ/EcDWqYKTKCLkd3gZcz98+wRSCTNVNmLUUF6HqWsl105sBX6vep4/xe6cc6zcYSCgFgcKGEK8h2QNIzw+DmdH2Ujxn6AaEkaNBS0b4AGMJSYREqCh6tRpTwBF1VVV5usLMQLz9/eh7HVhorCsHB6bdxk+M2sJOHxX1ikynnwc2cRs12uY/mWMfdLi6S1Q76NmgcfR/ICjyxXUcM3FlmUUsyzQJVyq7+pPr5ahodJw0LRKe3hRNPdQIiXOlNXn1tX7oIxcN9wZ5VR4ZwMORwNBZymZA3oS2Kr27cHvvIhwtEC92ouxd3ue1H8mBmexzbwW6S9Qom0pLiEclK4zRrKmmAWLgHV/2I7nzH6n3V+RFGttW3EOTKTI6n48tnKx7RKaM0qBpzqSAxanNaW3NRvrs++NSjb2LnZoLFoSf9YPLB6YrI6cO08vkWbesc/DWHic3BYPPEaj0rekj5dLJip+acdJw0AiG3dzwfw4ppmcv7zuQpanJYntpmLHoQV4E= root@trexclient

Как мы видим, публичный SSH-ключ клиента был успешно добавлен на сервер.


Примечание. Если на удаленном узле вы используете не стандартный порт в качестве порта для подключения по SSH, а любой другой, то необходимо при вводе команды ssh-copy-id указать дополнительные параметры:

ssh-copy-id ‘-p *port* username@remote_host’

После внесенных изменений необходимо перезапустить службы SSH. 

sudo service ssh restart (для Ubuntu / Debian / Mint Linux)
sudo service sshd restart (для CentOS / RHEL / Fedora Linux)

Копирование ключа при помощи SSH

Данный метод подойдет тем, чья клиентская машина не поддерживает команду SSH-Copy-ID, но сервер имеет доступ по SSH.

В таком случае вы можете воспользоваться командой:

cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

, где

  • cat ~/.ssh/id_rsa.pub — вывод содержимого файла id_rsa.pub,
  • ssh username@remote_host — подключение к удаленному серверу,
  • «mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys» — проверка наличия директории /.ssh и перенаправление вывода первой команды в файл authorized_keys.

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

~# cat /root/.ssh/authorized_keys

После внесенных изменений необходимо перезапустить службы SSH. 

sudo service ssh restart (для Ubuntu / Debian / Mint Linux)
sudo service sshd restart (для CentOS / RHEL / Fedora Linux)

Копирование пользователем вручную

Данный метод следует использовать тем, у кого нет SSH-доступа на удаленный сервер. Вам необходимо найти файл id_rsa.pub (при использовании Linux) или public (при использовании Windows) на клиентской машине, открыть его и скопировать все содержимое. Через консоль Linux это можно сделать, используя команду cat:

cat ~/.ssh/id_rsa.pub

Затем следует любым доступным вам способом подключиться к удаленному серверу, куда необходимо скопировать открытый SSH-ключ. В нашем случае это будет консольный доступ к облачному (виртуальному) серверу через панель my.selectel.ru.

Доступ к серверу через консоль

Найдя все тот же файл authorized_keys, необходимо просто вставить в него то, что мы скопировали из файла id_rsa.pub на клиентской машине ранее. В случае, если вы генерировали SSH-ключи в ОС Windows с помощью Putty, необходимо так же скопировать публичный ключ в файл authorized_keys. Либо вы можете открыть консоль и использовать команду для загрузки ключа:

echo *Text* >> ~/.ssh/authorized_keys

Где *Text*  — это скопированные вами данные из id_rsa.pub.

После внесенных изменений необходимо перезапустить службы SSH. 

sudo service ssh restart (для Ubuntu / Debian / Mint Linux)
sudo service sshd restart (для CentOS / RHEL / Fedora Linux)

Использование SSH-ключей

Настройка аутентификации на сервере с помощью SSH-ключей из ОС Linux

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

~# ssh username@remote_host

root@trexclient:~# ssh root@5.159.102.80
Welcome to Ubuntu 22.04.2 LTS (GNU/Linux 5.15.0-60-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management: 	https://landscape.canonical.com
 * Support:    	https://ubuntu.com/advantage

 * Introducing Expanded Security Maintenance for Applications.
   Receive updates to over 25,000 software packages with your
   Ubuntu Pro subscription. Free for personal use.

 	https://ubuntu.com/pro

Expanded Security Maintenance for Applications is not enabled.

0 updates can be applied immediately.

Enable ESM Apps to receive additional future security updates.
See https://ubuntu.com/esm or run: sudo pro status


Last login: Sun Mar  5 12:31:34 2023 from 152.89.133.14
root@selectelserv:~#

Если имя пользователя на локальной машине и удаленном узле совпадают, можно сократить вводимую команду до:

~# ssh remote_host

Настройка аутентификации на сервере с помощью SSH-ключей из ОС Windows

Ранее мы уже скопировали открытый SSH-ключ, сгенерированный с помощью Putty, на удаленный узел. Теперь необходимо произвести подключение.

Для этого откройте putty.exe и введите IP-адрес удаленного узла и порт для подключения, а также проверьте, что в качестве типа подключения выбран SSH.

Вводим IP-адрес в Putty.exe

Далее пройдите по пути, указанному на скриншоте (Connection → SSH → Auth → Credentials):

Настройка аутентификации в Putty

В поле Private key file for authentication вставьте ссылку на приватный ключ, который необходимо использовать в данном подключении, и нажмите Open.

Перед вами откроется окно, в котором нужно ввести логин пользователя удаленного узла. В нашем случае — учетная запись root.

Окно для введения логина

Подключение из ОС Windows с помощью OpenSSH аналогично подключению по SSH на сервере Linux: 

C:\Users\Administrator> ssh hostname@remote_host  

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

Enter passphrase for key 'C:\Users\Administrator/.ssh/id_ed25519':

Выполнение одной команды на удаленном узле

Если вам необходимо ввести лишь одну команду, можно не создавать целый сеанс, а ввести нужную команду после ssh hostname@remote_host.

ssh hostname@remote_host command

Технически сессия все-таки создается, и происходит аутентификация на основе введенных данных. Затем передается нужная команда command, и сеанс сразу же закрывается. Поэтому визуально кажется, что мы просто передали команду на удаленный узел. 

Отпечаток SSH-ключа

Каждая пара SSH-ключей использует один криптографический отпечаток. Его можно использовать для идентификации ключей.

~# ssh-keygen -l
Enter file in which the key is (/root/.ssh/id_rsa):

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

3072 SHA256:UxyIzKj93YXoldmfyP5K4/uKkHTu9UoG0nK9e93q57g root@trexclient (RSA)

Смена порта SSH

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

sudo ufw allow *port*

Теперь приступим к изменению порта. В первую очередь, находясь на удаленном узле, необходимо открыть файл sshd_config:

sudo nano /etc/ssh/sshd_confog

Внутри этого файла найдите строку Port и укажите там свое значение, например, 4312.

Port 4312

После этого необходимо перезагрузить демон SSH:

sudo service ssh restart (для Ubuntu / Debian / Mint Linux)
sudo service sshd restart (для CentOS / RHEL / Fedora Linux)

Теперь при подключении к этому удаленному узлу необходимо указывать новый порт для подключения по SSH с помощью ключа -p:

ssh -p 4312 hostname@remote_host

Если вы хотите, чтобы -p 4312 не нужно было вводить каждый раз, можно изменить файл конфигурации SSH на локальной машине следующим образом:

nano ~/.ssh/config
Host *alias_name*
HostName *remote_host*
Port *port*
User *username*

Теперь при подключении к удаленному узлу с помощью команды ssh *AliasName* порт будет выбран автоматически согласно соответствующей записи в /config.

Проброс авторизации

Проброс авторизации — это аутентификация на другом сервере через сервер, к которому вы подключены, используя ключ на вашем локальном компьютере. Иными словами, мы с узла A подключаемся к узлу B, а узел B, используя данные узла A, присоединяется с их помощью к узлу C.

На первом узле мы ввели команду подключения с ключом -A, тем самым подключились к узлу host_B.

ssh -A root@*host_B*

На узле host_B мы ввели следующую команду и присоединились к узлу host_C под учетными данными первого узла.

root@host_B:~# ssh root@*host_C*

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

Увеличение времени простоя

Время ожидания подключения может истечь — придется подключаться к системе заново. Чтобы этого избежать, можно настроить конфигурацию так, чтобы удаленный узел проверял активное SSH-соединение, отправляя клиенту echo-запросы каждые ServerAliveInterval секунд. Если клиент не ответит на запрос ServerAliveCountMax раз, то соединение будет разорвано.

Данные изменения нужно внести в конфигурацию файла /etc/ssh/sshd_config на сервере.

ServerAliveInterval *count*
ServerAliveCountMax *count*

Отключение проверки пароля

Ранее мы с вами настроили доступ по SSH с использованием SSH-ключей, но альтернативный вход по паролю по-прежнему включен. Чтобы обезопасить себя от возможного брутфорса (взлома пароля простым перебором), необходимо отключить возможность такого входа. Для этого на сервере нам необходимо открыть на редактирование файл конфигурации SSH под названием sshd_config:

sudo nano /etc/ssh/sshd_config

В нем найдем строку PasswordAuthentication, изменим ее значение с yes на no и сохраним изменения.

PasswordAuthentication no

Для того, чтобы изменения вступили в силу, следует перезагрузить службу SSH:

sudo service ssh restart (для Ubuntu / Debian / Mint Linux)
sudo service sshd restart (для CentOS / RHEL / Fedora Linux)

Теперь ваш сервер не будет рассматривать в качестве возможного варианта подключения по SSH использование пароля.

Устранение неполадок

Ключ игнорируется сервером

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

Permission denied (publickey).

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

Настройка удаленного узла

Полный доступ к папке .ssh только владельцу, остальным — полный запрет:

chmod rwx------ ~/.ssh

Права на запись и чтение для файла authorized_keys только владельцу, остальным — полный запрет: 

chmod rw------- ~/.ssh/authorized_keys

Отмена записи группой и остальными пользователями:

chmod go-w ~/

Настройка локальной машины

Полный доступ к папке .ssh только владельцу, остальным — полный запрет:

chmod rwx------ ~/.ssh

Права на запись и чтение для файла ключа только владельцу, остальным — полный запрет:

chmod rw------- ~/.ssh/*key*

После применения этих политик ошибка должна исчезнуть. 

Зашифрованный домашний каталог

Если у вас есть зашифрованный домашний каталог, то SSH не сможет получить доступ к файлу authorized_keys, пока вы не пройдете аутентификацию. Поэтому SSH по умолчанию будет использовать вход по паролю. Чтобы решить эту проблему, создайте папку вне домашнего каталога с именем /etc/ssh/*username*. Этот каталог должен иметь права доступа rwxr-xr-x и принадлежать пользователю. Переместите в него файл authorized_keys (authorized_keys должен иметь права доступа rw-r—r— и принадлежать пользователю).

Затем отредактируйте файл /etc/ssh/sshd_config и добавьте в него запись:

AuthorizedKeysFile /etc/ssh/%u/authorized_keys

Перезагрузите службу SSH.

sudo service ssh restart (для Ubuntu / Debian / Mint Linux)
sudo service sshd restart (для CentOS / RHEL / Fedora Linux)

При следующем подключении по SSH вам не нужно будет вводить пароль.

Анализ логов подключения

При возникновении ошибок во время подключения вы можете проанализировать файл  /var/log/auth.log, в котором будут указаны все попытки подключения к системе, а также механизмы, использованные для аутентификации.

Также детальную информацию о подключении можно получить с помощью опций -v, -vv или -vvv. Чем больше ключей -v (но не более 3), тем подробнее будет лог.

ssh -vvv hostname@remote_host

Вызов справки

Подробное описание команды (ее параметров, значений и дрю.) вы можете найти в документации, которая вызывается командой man, например:

man ssh
man sshd

Заключение

В тексте мы рассмотрели создание и авторизацию с помощью SSH-ключей на базе ОС Linux и Windows, а также разобрали некоторые ошибки, которые могут возникать при использовании такого способа авторизации. Использование SSH-ключей не только упрощает способ авторизации, но и увеличивает степень защиты вашего сервера.

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

Проверка службы SSH на сервере

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

Например, у меня VDS на Timeweb. Чтобы попасть в консоль, я авторизуюсь по логину и паролю, выданному хостером, выбираю свой сервер в списке VDS и перехожу на вкладку «Консоль». 

Вход в консоль

Чтобы пользоваться консолью, нужно авторизоваться. Логин и пароль для доступа к серверу хостер присылает в письме. Сначала нужно ввести логин и нажать на клавишу Enter. Появится строка Password. В ней необходимо ввести пароль и снова нажать на клавишу Enter.

Важно: в целях безопасности при вводе пароля на экране не отображаются никакие символы, даже привычные звездочки. 

После авторизации в консоли можно проверить, запущена ли служба SSH на сервере.

  1. Выполните команду systemctl status sshd.
  2. Обратите внимание на строчку Active. В ней должна быть выделенная зеленым запись active (running). Это состояние говорит о том, что служба запущена.

Служба SSH работает

Если служба не активна, добавьте ее самостоятельно. Выполните команду sudo apt install openssh-server и подтвердите установку пакетов.

Кроме того, для подключения вам может понадобиться настройка брандмауэра. Чтобы межсетевой экран не блокировал входящие соединения, можно на время отключить его командой sudo ufw disable.

Комьюнити теперь в Телеграм

Подпишитесь и будьте в курсе последних IT-новостей

Подписаться

Использование пароля

Начнем с инструкции о том, как подключиться к удаленному серверу через SSH по логину и паролю. Это самый простой способ. Хостер предоставляет вам IP-адрес, логин и пароль. Этого достаточно для того, чтобы установить соединение с удаленным сервером.

Подключение на Windows

Моя основная система — Windows. Раньше для подключения к серверу через SSH я пользовался сторонней утилитой PuTTY, потому что в операционной системе не было встроенного компонента. В «десятке» он появился, так что теперь можно подключаться к SSH через командную строку (cmd).

Чтобы включить встроенный в систему OpenSSH:

  1. Откройте «Параметры» (Win + I) и перейдите в раздел «Приложения».
  2. Выберите опцию «Управление дополнительными компонентами».
  3. Нажмите «Добавить компонент».
  4. Выберите в списке OpenSSH Client и нажмите «Установить».
  5. После завершения установки перезагрузите систему.

Клиент OpenSSH на Windows

Теперь разберемся, как подключиться к SSH через cmd. Запустите командную строку и выполните запрос вида ssh root@185.104.114.90.

Значение root — логин для подключения, вы получили его в письме при создании сервера. 185.104.114.90 — IP-адрес сервера. Его можно посмотреть в панели управления сервером или в том же письме, которое прислал хостер. У команды может быть также дополнительный параметр -p, после которого прописывается номер порта. По умолчанию используется порт 22. Если у вас настроен другой порт, нужно явно его указать, — например, полный адрес может выглядеть так: ssh root@185.104.114.90 -p 150.

После выполнения команды клиент SSH предложит добавить устройство в список известных. Введите в командной строке yes и нажмите на Enter. Затем укажите пароль для доступа к серверу. На этом подключение к серверу через SSH завершено — теперь все команды будут выполняться на удаленной машине, к которой вы подключились.

На версиях младше Windows 10 1809 нет встроенной поддержки протокола OpenSSH. В таком случае понадобится сторонняя утилита. Смотрим, как через PuTTY подключиться по SSH:

  1. Запустите PuTTY.
  2. На вкладке Session укажите Host Name (IP-адрес сервера), Port (по умолчанию 22, но если вы в конфигурации сервера указали другой порт, нужно задать его номер).
  3. Убедитесь, что тип соединения установлен SSH.
  4. Нажмите на кнопку Open, чтобы подключиться.

SSH в программе PuTTY

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

Подключение на Linux и macOS

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

  1. Запустите терминал. Обычно для этого используется сочетание клавиш Ctrl+Alt+T. Найти терминал также можно по пути «Главное меню» — «Приложения» — «Система».
  2. Выполните команду для подключения. Синтаксис такой же, как на Windows, — ssh root@185.104.114.90. Если порт не стандартный, то нужно явно его указать: например, ssh root@185.104.114.90 -p 150. Вместо root вы указываете свое имя пользователя, а вместо 185.104.114.90 — IP-адрес своего сервера.
  3. Если хост и порт указаны верно, на следующем шаге появится запрос на ввод пароля. При первом подключении также будет предложение добавить новое устройство в список известных. Для этого введите yes и нажмите на клавишу Enter.

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

Если IP-адрес или порт указаны неверно, то на экране появится сообщение об ошибке — Connection Refused. Это может также говорить о том, что доступ запрещен брандмауэром на удаленном сервере (если вы его не отключили). Чтобы разрешить подключение через SSH:

  • на сервере с Ubuntu/Debian выполните команду $ sudo ufw allow 22/tcp;
  • на сервере CentOS/Fedora выполните команду $ firewall-cmd —permanent —zone=public —add-port=22/tcp.

Цифра 22 в синтаксисе — номер порта. Если вы используете другой порт, то укажите его явно.

Если вы знаете как подключиться через SSH на Linux, то справитесь с этой задачей и на macOS. В операционной системе Apple тоже есть встроенный терминал. Синтаксис команды для подключения не меняется: ssh root@185.104.114.90, где root — ваш логин, а 185.104.114.90 — IP-адрес сервера, с которым вы устанавливаете соединение. 

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

Как подключиться к серверу по VNC

Как подключиться к виртуальному серверу VPS/VDS

Использование ключа

Ввод пароля для подключения через SSH — раздражающая процедура. У меня почти никогда не получалось ввести его правильно с первого раза. Поэтому я начал искать информацию о том, как подключиться к серверу через SSH без пароля. Простое и безопасное решение — использование ключа. Почему это безопаснее? Потому что пароль можно подобрать. Чтобы исключить такую вероятность, многие пользователи выбирают авторизацию с помощью ключа. 

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

Генерирование ключа и подключение на Windows

Для удобства используем программу PuTTy. Вместе с ней устанавливается утилита PuTTYgen — в ней можно сгенерировать публичный и приватный ключи.

  1. Запустите программу PuTTYgen.
  2. Нажмите на кнопку Gengerate.
  3. Водите курсором мышки по рабочему столу, чтобы сгенерировать случайные значения ключей.Создание ключей в PuTTY
  4. Нажмите на кнопку Save private key, чтобы сохранить на жестком диске приватный ключ. Место хранения может быть любым — его нужно указать в параметрах PuTTY. Сделаем это позже. 
  5. Скопируйте публичный ключ в буфер обмена (Ctrl + C) и закройте генератор ключей.

Ключи в PuTTY

Теперь нужно перенести публичный ключ на сервер. Запустите программу PuTTY и подключитесь к серверу с помощью пароля. Затем последовательно введите следующие команды:

mkdir ~/.ssh

chmod 0700 ~/.ssh

touch ~/.ssh/authorized_keys

chmod 0644 ~/.ssh/authorized_keys

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

Следующий шаг — вставка публичного ключа из буфера обмена в файл authorized_keys. Для этого используется команда cat > .ssh/authorized_keys. После ввода команды щелкните по окну терминала правой кнопкой, чтобы вставить скопированный ранее публичный ключ. Для завершения ввода нажмите на сочетание клавиш Ctrl+D.

Вернитесь в настройки PuTTY. Перейдите в раздел Connection — SSH — Auth. Нажмите на кнопку Browse и укажите путь к приватному ключу, который вы ранее сохранили на жестком диске.

Приватный ключ в PuTTY

Теперь для подключения к серверу через SSH пароль не нужен — достаточно указать логин и IP-адрес сервера.

Генерирование ключа и подключение на Linux и macOS

Теперь посмотрим, как подключиться через SSH ключи на Linux и macOS. 

  1. Запустите терминал на локальном компьютере.
  2. Выполните команду ssh-keygen, чтобы сгенерировать ключи.
  3. Нажмите на Enter, чтобы сохранить ключи.

Генератор предложит также задать кодовую фразу для ключа. Это дополнительная мера безопасности: если кто-то получит доступ к вашей локальной машине, то все равно не сможет подключиться к серверу через SSH. Минус один — вам тоже придется постоянно вводить ключевую фразу. Можно отказаться от этой меры защиты, просто нажав на клавишу Enter. 

На этом процедура создания ключей завершена. Файлы d_rsa (приватный ключ) и id_rsa.pub (публичный ключ) хранятся в папке ~/.ssh/.  Осталось скопировать открытую часть ключа на сервер.

  1. Вернитесь в терминал.
  2. Выполните команду ssh-copy-id root@185.104.114.90, где root — логин для подключения к серверу по SSH, а 185.104.114.90 — IP-адрес или хост сервера.

После выполнения этой команды публичный ключ будет скопирован на сервер. Теперь вы можете подключаться к удаленной машине с помощью логина и IP-адреса — например, ssh root@185.104.114.90. Ключи будут сопоставляться автоматически.

Отключение запроса пароля

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

  1. Подключитесь к удаленному серверу.
  2. Выполните команду sudo nano /etc/ssh/sshd_config. Файл sshd_config откроется во встроенном текстовом редакторе. 
  3. Найдите строку PasswordAuthentication yes и измените ее на PasswordAuthentication no.
  4. Сохраните изменения и перезапустите службу SSH командой sudo service ssh restart.

Авторизация по паролю отключена. Теперь подключиться к серверу можно только с помощью пары ключей.

В последних билдах Windows 10 появился встроенный SSH сервер и клиент на базе OpenSSH. Это значит, что теперь вы можете удаленно подключаться к компьютеру Windows 10/11 (Windows Server 2019/2022) с помощью любого SSH клиента, как к Linux. В этой статье мы покажем, как настроить OpenSSH в Windows 10 и подключится к нему с помощью putty или любого другого SSH клиента.

Убедитесь, что ваша версия Windows 10 1809 или выше. Проще всего это сделать, выполнив команду:

winver

Совет. Если у вас более старая версия Windows 10 вы можете обновить ее через Windows Update или с помощью ISO образа с более новой версией Windows 10 (можно создать его с помощью Media Creation Tool). Если вы не хотите обновлять Windows 10, вы можете вручную установить порт OpenSSH для Windows с GitHub — Win32-OpenSSH (https://github.com/PowerShell/Win32-OpenSSH).

Вы можете включить OpenSSH сервера в Windows 10 через панель Параметры:

  1. Перейдите в Settings -> Apps -> Optional features; установка дополнительных компонентов в windows 10
  2. Нажмите Add a feature, выберите OpenSSH Server и нажмите Install; установка openssh сервера в windows 10 и 11

Также вы можете установить sshd сервер в Windows с помощью PowerShell:

Add-WindowsCapability -Online -Name OpenSSH.Server*

установка OpenSSH.Server в Windows с помощью OpenSSH.Server

Или с помощью DISM:

dism /Online /Add-Capability /CapabilityName:OpenSSH.Server~~~~0.0.1.0

Если вы хотите убедитесь, что OpenSSH сервер установлен, выполните следующую команду:

Get-WindowsCapability -Online | ? Name -like 'OpenSSH.Server*'

Name : OpenSSH.Server~~~~0.0.1.0
State : Installed

проверить что OpenSSH установлен

Проверьте статус служб ssh-agent и sshd с помощью командлета Get-Service:

Get-Service -Name *ssh*

службы SSH в Windows 10

Как вы видите, обе службы находятся в состоянии Stopped и не добавлены в автозагрузку. Чтобы запустить службы и настроить для них автозапуск, выполните команды:

Start-Service sshd
Set-Service -Name sshd -StartupType 'Automatic'
Start-Service ‘ssh-agent’
Set-Service -Name ‘ssh-agent’ -StartupType 'Automatic'

настроить автозапуск для sshd сервиса в windows

Также нужно разрешить входящие подключения на порт TCP 22 в Windows Defender Firewall:

netsh advfirewall firewall add rule name="SSHD service" dir=in action=allow protocol=TCP localport=22

Теперь вы можете подключиться к Windows 10 с помощью любого SSH клиента. Для подключения из Linux используете команду:

ssh -p 22 admin@192.168.1.90

где, admin – имя локального пользователя Windows, под которым вы хотите подключиться

192.168.1.90 – ip адрес вашего компьютера с Windows 10

putty: подключение к windows 10 через ssh

После этого откроется окно командной строки Windows.

Совет. Чтобы вместо оболочки cmd.exe при подключении к Windows 10 через SSH запускалась консоль PoweShell, нужно выполнить команду:

New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -PropertyType String –Force

Так вы измените оболочку, которая стартует через OpenSSH. Теперь при подключении к Windows по SSH у вас будет сразу открываться консоль PowerShell вместо командной строки cmd.exe.

изменить ssh shell с cmd на powershell в Windows 10

Если вы хотите использовать key-based ssh authentification вместо парольной аутентификации, нужно на вашем клиенте сгенерировать ключ с помощью ssh-keygen.exe.

Затем содержимое файла id_rsa.pub нужно скопировать в файл c:\users\admin\.ssh\authorized_keys в Windows 10.

После этого вы сможете подключаться с вашего Linux клиента к Windows 10 без пароля. Используйте команду:

ssh -l admin@192.168.1.90

Вы можете настроить различные параметры OpenSSH сервера в Windows с помощью конфигурационного файла %programdata%\ssh\sshd_config

sshd_config  конфигурационный файл openssh в windows

Например, вы можете отключить аутентификацию по паролю и разрешить вход только по ключу:

PubkeyAuthentication yes
PasswordAuthentication no

  • Windows sound settings windows 10
  • Windows storage server 2008 r2 essentials
  • Windows ssh agent add key
  • Windows spb ремонт окон отзывы
  • Windows storage server 2008 r2 embedded