Доступ по ssh по ключу windows

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

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

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

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

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

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

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

ssh-keygen -t ed25519

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

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

Generating public/private ed25519 key pair. Enter file in which to save the key (C:\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 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-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 сервер с клиента с помощью 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

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

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

Notepad C:\ProgramData\ssh\sshd_config

PubkeyAuthentication yes

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

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

Restart-Service sshd

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

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

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

Например,

ssh [email protected]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#Match Group administrators
# AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys

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

PasswordAuthentication no

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

restart-service sshd

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

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

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

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

Что это такое и зачем это нужно?

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

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

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

Симметричное и асимметричное шифрование

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

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

Ключевая пара

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

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

Применение на практике

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

Также нам будет необходимо установить и сконфигурировать SSH сервер. В качестве примера мы возьмем популярный проект — OpenSSH Server, который доступен для установки на различных операционных системах в т.ч — Windows и Linux.

Настройка доступа по ключам

Разворачиваем виртуальную машину

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

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

Когда предварительные действия будут выполнены, перейдите в папку сценария Localhost_1.2 для развертывания CentOS, либо в папку Localhost_1.3 для развертывания Ubuntu, либо в папку Localhost_1.0 для развертывания Windows Server и выполните команду:

vagrant up

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

Спустя время, виртуальная машина будет готова и мы сможем подключиться к ней либо через менеджер виртуальных машин VirtualBox, либо при помощи ssh подключения по адресу 127.0.0.1:2222.

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

В случае, если была выбрана виртуальная машина на Windows, мы можем подключиться к ней при помощи RDP по адресу 127.0.0.1:33389.

В качестве учетной записи для подключения указываем — Administrator. Пароль — vagrant.

Конфигурация сервера. Установка OpenSSH на Linux

Для установки OpenSSH сервера на CentOS выполним следующую команду:

sudo yum install openssh-server -y

Итогом должна быть установка, обновление или сообщение об актуальности версии OpenSSH. В моем случае установлена актуальная версия инструмента.

Для установки OpenSSH сервера на Ubuntu выполним следующие команды:

sudo apt-get update
sudo apt-get install openssh-server -y

Результатом также будут установка, обновление или сообщение об актуальности версии OpenSSH.

Запустим службу sshd выполнив команду:

sudo systemctl start sshd
sudo systemctl enable sshd

Конфигурация сервера. Установка OpenSSH на Windows

Компонент OpenSSH Server доступен в Windows из коробки начиная с версии Windows 10 1809 и Windows Server 2019. Для быстрой установки откроем Powershell от имени администратора и введем команду:

Get-WindowsCapability -Online | ? Name -like 'OpenSSH*' | Add-WindowsCapability -Online

Будет запущен процесс установки компонента OpenSSH Server.

В дополнение к вышеуказанной команде выполним еще пару команд. Запустим службу sshd и выберем тип запуска — Автоматический.

Start-Service sshd; Set-Service -Name sshd -StartupType 'Automatic'

Создадим разрешающее правило в Firewall Windows.

New-NetFirewallRule -Name sshd -DisplayName 'OpenSSH Server (sshd)' -Enabled True `
-Direction Inbound -Protocol TCP -Action Allow -LocalPort 22

Конфигурация клиента. Формирование ключевой пары на Windows (PuTTYgen)

Сначала попробуем сгенерировать ключевую пару при помощи PuTTY. Для этого нам достаточно скачать инструменты PuTTY и PuTTYgen с официального сайта — https://www.putty.org/.

Инструмент PuTTY нам понадобится для ssh подключения чуть позже, а с помощью PuTTYgen мы сможем сформировать ключевую пару прямо сейчас.

Запустим PuTTYgen и выберем Generate. Все остальные настройки можно оставить по умолчанию.

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

Поздравляю, мы успешно сгенерировали ключевую пару при помощи PuTTYgen. Сохраним закрытую часть ключа в виде файла при помощи кнопки Save private key в надежное место. PuTTYgen спросит нас о том хотим ли мы пропустить создание ключевой фразы для закрытой части. В нашем случае мы соглашаемся и отвечаем — Да.

Не закрывая окно PuTTYgen переходим в раздел Public key for pasting into OpenSSH authorized_keys file и копируем из него все содержимое. Эта информация нам понадобится на этапе добавления открытого ключа на SSH сервер.

Конфигурация клиента. Формирование ключевой пары на Linux (ssh-keygen)

Теперь попробуем сгенерировать ключевую пару из под Linux при помощи инструмента ssh-keygen. Для теста воспользуемся Ubuntu.

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

В итоге в папке ~/.ssh должны появиться две части ключа. id_rsa — закрытая часть, id_rsa.pub — открытая часть.

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

chmod 600 ~/.ssh/id*

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

cat ~/.ssh/id_rsa.pub

Конфигурация сервера. Разрешение аутентификации по ключу и добавление ключей на Linux.

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

После успешного логина добавим скопированную нами открытую часть ключа из предыдущего этапа в файл ~/.ssh/authorized_keys.

vi ~/.ssh/authorized_keys

Вставляем открытую часть ключа и сохраняем файл.

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

Теперь включим возможность аутентификации по ключу и отключим возможность подключения по паролю. Для этого выполним команду:

sudo sed -i 's/PubkeyAuthentication no/PubkeyAuthentication yes/g' /etc/ssh/sshd_config
sudo sed -i 's/PasswordAuthentication yes/PasswordAuthentication no/g' /etc/ssh/sshd_config

Или откроем конфигурационный файл /etc/ssh/sshd_config любым удобным редактором.

sudo vi /etc/ssh/sshd_config

Находим строку PasswordAuthentication и устанавливаем значение no. Также находим строку PubkeyAuthentication и устанавливаем значение yes.

Для применения конфигурации перезапустим службу OpenSSH сервера выполнив команду:

sudo systemctl restart sshd

Конфигурация сервера. Разрешение аутентификации по ключу и добавление ключей на Windows.

Разрешим функцию аутентификации по открытому ключу, запретим вход по паролю. Заодно перезапустим службу sshd для применения конфигурации.

Для этого запустим PowerShell от имени администратора и выполним команду:

((Get-Content -path C:\ProgramData\ssh\sshd_config -Raw) `
-replace '#PubkeyAuthentication yes','PubkeyAuthentication yes' `
-replace '#PasswordAuthentication yes','PasswordAuthentication no')`
 | Set-Content -Path C:\ProgramData\ssh\sshd_config; Restart-Service sshd

Добавляем открытую часть ключа для аутентификации. Создаем папку .ssh в профиле пользователя а также, вместо ssh-rsa, записываем в файл authorized_keys открытую частью ключа.

New-item -Path $env:USERPROFILE -Name .ssh -ItemType Directory -Force
echo "ssh-rsa" | Out-File $env:USERPROFILE\.ssh\authorized_keys -Encoding ascii

Подключение к серверу SSH по открытой части ключа на Windows.

Запустим PuTTY и введем адрес подключения к SSH серверу.

В разделе Connection > SSH > Auth укажем сохраненный файл закрытой части ключа и пробуем подключиться к нашему серверу.

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

Результат ssh аутентификации по ключу на сервере CentOS или Ubuntu.

Результат ssh аутентификации по ключу на сервере Windows.

Подключение к серверу SSH по открытой части ключа на Linux.

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

ssh vagrant@127.0.0.1 -p 2222

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

Результат ssh аутентификации по ключу на сервере CentOS или Ubuntu.

Результат ssh аутентификации по ключу на сервере Windows.

Конвертация ключей

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

Представьте простую и вполне реальную ситуацию. Вы сгенерировали ключевую пару и хотели бы распространить ее на других своих устройствах. Проблемой может стать желание перенести ключевую пару на Linux, которая была сгенерирована при помощи PuTTYgen под Windows.

К сожалению, если скопировать такой ключ и попытаться произвести вход на SSH сервер, мы скорее всего получим ошибку: Load key «/root/.ssh/id_rsa»: invalid format, либо подобные.

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

Самый просто способ — запустить PuTTYgen, загрузить сохраненную закрытую часть ключа при помощи кнопки Load.

Перейти в раздел Conversions и выбрать меню Export OpenSSH key.

Инструмент позволит нам сохранить закрытую часть в формате (PEM), который генерирует ssh-keygen.

Точно таким же методом мы можем производить обратное преобразование из PEM в формат PuTTY. Таким образом, нет необходимости создавать разные сущности ключей, мы сможем использовать одну.

Итоги

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

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

Введение

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

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

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

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

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

ssh-keygen -t rsa

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

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

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

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

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

ssh-copy-id user_name@server_name_or_ip

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

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

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

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

Итак, из документации становится очевидно, что Windows хранит пользовательские ключи, используя тот же принцип, что и Linux: на сервере в файле authorized_keys в подкаталоге .ssh домашнего каталога пользователя (а это, как правило, c:\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-ключа для подключения к серверу позволяет сделать работу более безопасной (снизится вероятность взлома учетной записи) и более удобной (не будет необходимости при каждом соединении вводить пароль).

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

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

Linux, MacOS, Windows 10

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

Эта инструкция подойдет для ОС Linux, MacOS, а также для версий Windows 10 начиная с 1809 — в них доступен встроенный SSH-клиент. Если у вас более ранняя версия Windows, воспользуйтесь инструкцией из пункта Старые версии Windows (без OpenSSH).

Запустите терминал или Windows PowerShell на вашем компьютере и выполните команду:

ssh-keygen

Вы увидите примерно следующее сообщение:

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

Нажмите Enter — ключ будет сохранен в указанную директорию по умолчанию.

Далее вам будет предложено задать пароль (кодовую фразу) для ключа. Вы можете задать ее или оставить пустой, просто нажав Enter. Обратите внимание, что если вы зададите кодовую фразу, ее потребуется вводить при каждой авторизации по ключу.

Процедура создания ключей завершена, ключи сохранены в директории ~/.ssh/ в файлах id_rsa и id_rsa.pub. Теперь публичный ключ необходимо скопировать на сервер.

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

Выполните в терминале следующую команду, указав вместо user имя пользователя, созданного на сервере, а вместо server — IP-адрес вашего сервера:

ssh-copy-id user@server

# Например:
ssh-copy-id admin@2.59.43.145

В результате содержимое файла с публичным ключом id_rsa.pub будет скопировано в файл ~/.ssh/authorized_keys на сервере, и в дальнейшем вы сможете устанавливать соединение с сервером, используя команду:

ssh user@server

# Например:
ssh admin@2.59.43.145

Старые версии Windows (без OpenSSH)

Если вы используете версию Windows без OpenSSH, вам потребуется специальная программа — PuTTYgen. Вы можете скачать дистрибутив puttygen.exe с официального сайта PuTTY.

Создание SSH-ключей с помощью PuTTYgen

1. Запустите программу, в открывшемся окне выберите RSA в блоке «Type of key to generate» и нажмите «Generate».
   
2. Пока создается ключ, водите мышью в хаотичном порядке в пространстве под строкой загрузки для генерации случайных значений.
3. После того, как ключ будет создан, в окне программы вы сможете задать «Key passphrase» (кодовую фразу) для ключа. Это необязательно, вы можете оставить строку пустой. Если вы решите задать кодовую фразу, обратите внимание, что ее потребуется вводить при каждой авторизации по ключу.
4. Далее сохраните созданные ключи, нажав на кнопки «Save public key» и «Save private key», например, под именами id_rsa.pub и mykey.ppk.
5. Также скопируйте и сохраните в любом текстовом файле содержимое окна «Public key for pasting…» — оно потребуется при копировании созданного ключа на сервер.
   

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

Копирование ключа на сервер с помощью pageant

В процессе копирования ключей вам потребуется утилита pageant. Вы можете скачать дистрибутив pageant.exe с официального сайта PuTTY. 

1. Подключитесь к серверу по SSH и выполните команду для создания на сервере директории и файла для хранения ключей:

mkdir ~/.ssh
chmod 0700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 0644 ~/.ssh/authorized_keys

1. Откройте созданный файл с помощью текстового редактора:

nano ~/.ssh/authorized_keys

1. Вставьте в него текст public key, ранее скопированный из окна PuTTYgen, и сохраните файл.
2. Запустите pageant — его иконка появится в трее. Щелкните по ней правой кнопкой мыши и выберите «Add Key».
3. В открывшемся окне укажите путь к приватному ключу mykey.ppk, сохраненному ранее, и нажмите «Open». Если при создании ключа вы указывали кодовую фразу, pageant запросит ее на данном этапе.
4. Для проверки работы авторизации по ключу снова запустите утилиту PuTTY, подключитесь к вашему серверу и введите свой логин. Если все настроено корректно, вы увидите подобный вывод в окне консоли:

Authenticating with public key "rsa-key-20151220" from agent

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

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

1. Откройте файл командой:

sudo nano /etc/ssh/sshd_config

1. Найдите в нем строку PasswordAuthentication и замените ее значение на: PasswordAuthentication no.
2. Сохраните изменения, после чего перезапустите службу SSH: 

sudo service ssh restart

Если после выполненных действий у вас по-прежнему запрашивается пароль, проверьте, нет ли в директории /etc/ssh/sshd_config.d/ файла 50-cloud-init.conf с директивой PasswordAuthentication yes.

Если файл присутствует — удалите его, после чего перезапустите службу SSH.

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

Далее нажмите Генерировать и водите мышкой по экрану в свободной зоне до тех пор, пока генерация 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.

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

В поле 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-ключей не только упрощает способ авторизации, но и увеличивает степень защиты вашего сервера.