Настройка openssh windows 10 по сертификатам
Обновлено: 07.07.2024
Изучаем и настраиваем 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 и выполните команду:
Тестовый стенд будет развернут автоматически, пока что можно выпить чашечку чая или кофе. Конечно, вам никто не мешает развернуть это любым другим удобным способом.
Спустя время, виртуальная машина будет готова и мы сможем подключиться к ней либо через менеджер виртуальных машин VirtualBox, либо при помощи ssh подключения по адресу 127.0.0.1:2222.
В качестве учетной записи для подключения указываем — vagrant. Пароль — vagrant.
В случае, если была выбрана виртуальная машина на Windows, мы можем подключиться к ней при помощи RDP по адресу 127.0.0.1:33389.
В качестве учетной записи для подключения указываем — Administrator. Пароль — vagrant.
Конфигурация сервера. Установка OpenSSH на Linux
Для установки OpenSSH сервера на CentOS выполним следующую команду:
Для установки OpenSSH сервера на Ubuntu выполним следующие команды:
Запустим службу sshd выполнив команду:
Конфигурация сервера. Установка OpenSSH на Windows
Компонент OpenSSH Server доступен в Windows из коробки начиная с версии Windows 10 1809 и Windows Server 2019. Для быстрой установки откроем Powershell от имени администратора и введем команду:
Будет запущен процесс установки компонента OpenSSH Server.
В дополнение к вышеуказанной команде выполним еще пару команд. Запустим службу sshd и выберем тип запуска — Автоматический.
Создадим разрешающее правило в Firewall Windows.
Конфигурация клиента. Формирование ключевой пары на Windows (PuTTYgen)
Инструмент 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 — открытая часть.
Нам необходимо позаботиться о том, чтобы никто не имел прав доступа кроме нас самих к этим ключам. Для этого выполним команду:
Скопируем открытую часть ключа себе в буфер обмена, т.к нам понадобится добавить эту информацию на сервер в следующем этапе. Для этого выполним команду:
Конфигурация сервера. Разрешение аутентификации по ключу и добавление ключей на Linux.
Возвращаемся на наш сервер. На этом этапе нам необходимо добавить открытую часть ключа для аутентификации пользователя и разрешить аутентификацию по ключу.
После успешного логина добавим скопированную нами открытую часть ключа из предыдущего этапа в файл
Вставляем открытую часть ключа и сохраняем файл.
Фактически, мы только что связали с пользователем открытую часть ключа. У пользователя может быть несколько ключей для аутентификации. Все они должны быть перечислены в этом файле.
Теперь включим возможность аутентификации по ключу и отключим возможность подключения по паролю. Для этого выполним команду:
Или откроем конфигурационный файл /etc/ssh/sshd_config любым удобным редактором.
Находим строку PasswordAuthentication и устанавливаем значение no. Также находим строку PubkeyAuthentication и устанавливаем значение yes.
Для применения конфигурации перезапустим службу OpenSSH сервера выполнив команду:
Конфигурация сервера. Разрешение аутентификации по ключу и добавление ключей на Windows.
Разрешим функцию аутентификации по открытому ключу, запретим вход по паролю. Заодно перезапустим службу sshd для применения конфигурации.
Для этого запустим PowerShell от имени администратора и выполним команду:
Добавляем открытую часть ключа для аутентификации. Создаем папку .ssh в профиле пользователя а также, вместо ssh-rsa, записываем в файл authorized_keys открытую частью ключа.
Подключение к серверу SSH по открытой части ключа на Windows.
Запустим PuTTY и введем адрес подключения к SSH серверу.
В разделе Connection > SSH > Auth укажем сохраненный файл закрытой части ключа и пробуем подключиться к нашему серверу.
По итогу мы пройдем процедуру аутентификации без указания пароля для учетной записи пользователя.
Результат ssh аутентификации по ключу на сервере CentOS или Ubuntu.
Результат ssh аутентификации по ключу на сервере Windows.
Подключение к серверу SSH по открытой части ключа на Linux.
Выполним подключение к серверу SSH. Для этого запустим на исполнение команду:
По итогу мы пройдем процедуру аутентификации без указания пароля для учетной записи пользователя.
Результат 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 по RSA-ключам для безопасного доступа к удаленным системам. Мы покажем, как сгенерировать RSA-ключи (сертификаты) в Windows и настроить сервер OpenSSH в Windows 10/Windows Server 2019 для авторизации по ключам (без паролей).
Аутентификация по в SSH ключам широко используется в мире Linux, а в Windows этот функционал появился относительно недавно. Идея заключается в том, что на SSH сервере добавляется открытый ключ клиента и при подключении сервер проверяет наличие соответствующего закрытого ключа у клиента.
Генерация RSA ключей на клиенте Windows
На клиентском, компьютере, с которого вы будет подключаетесь к удалённому серверу Windows с OpenSSH, вам нужно сгенерировать пару RSA-ключей (открытый и закрытый). Закрытый ключ хранится на клиенте (не отдавайте его никому!), а открытый ключ помещается на SSH сервер в файл authorized_keys. Чтобы на клиенте Windows сгенерировать RSA ключи, вы должны установить клиент OpenSSH.
В Windows 10 1809 и Windows Server 2019 клиент OpenSSH устанавливается как отдельный встроенный компонент:
Add-WindowsCapability -Online -Name OpenSSH.Client
В предыдущих версиях Windows можно установить порт Win32-OpenSSH с GitHub (см. пример в статье о настройке SFTP сервера в Windows).Запустите обычную (непривилегированную сессию PowerShell) и сгенерируйте пару RSA 2048 ключей с помощью команды:
Утилита попросит вас указать пароль для защиты закрытого ключа. Если вы укажете пароль, то каждый раз при использовании этого ключа для SSH авторизации, вы должны будете вводить этот пароль. Я не стал указывать пароль для ключа (не рекомендуется).
Утилита ssh-keygen создаст каталог .ssh в профиле текущего пользователя Windows (C:\Users\your_username) и поместит в него 2 файла:
-
id_rsa – закрытый ключ
После того, как ключи созданы, вы можете добавить закрытый ключ в службу SSH Agent, которая позволяет удобно управлять закрытыми ключами и использовать их для аутентификации.
SSH Agent может хранить закрытые ключи и предоставлять их в контексте безопасности текущего пользователя. Запустите службу ssh-agent и настройте автоматический запуск с помощью PowerShell команд управления службами:
set-service ssh-agent StartupType ‘Automatic’
Start-Service ssh-agent
Добавьте ваш закрытый ключ в базу ssh-agent:
Настройка OpenSSH в Windows для авторизации по ключам
Теперь открытый ключ, который вы сгенерировали на клиенте, нужно скопировать на ваш SSH сервер (в этом примере это удаленный компьютер с Windows 10 1903 и настроенной службой OpenSSH).
Скопируйте файл id_rsa.pub в каталог .ssh профиля пользователя, под которым вы будете подключаться к SSH серверу. Например, у меня в Windows 10 создан пользователь admin, значит я должен скопировать ключ в файл C:\Users\admin\.ssh\authorized_keys.
Можно скопировать ключ на SSH сервер с клиента с помощью SCP:
scp C:\Users\youruser\.ssh\id_rsa.pub admin@192.168.1.90:c:\users\admin\.ssh\authorized_keys
Теперь вы можете подключиться к SSH серверу без ввода пароля пользователя. А если вы не задали пароль (passphrase) для закрытого ключа, вы сразу автоматически подключитесь к вашему удаленному серверу Windows.
Для подключения через SSH к удаленному хосту используется следующая команда:
ssh (username)@(имя или IP адрес SSH сервера)
Это означает, что вы хотите подключиться к удаленному SSH серверу с адресом 192.168.1.90 под учетной записью admin. Служба SSH Agent автоматически попытается использовать для авторизации сохраненный ранее закрытый ключ.
Если вы не хотите использовать ssh-agent для управления ключами, вы можете указать путь к закрытому ключу, который нужно использовать для SSH аутентификации:ssh admin@192.168.1.90 -i "C:\Users\youruser\.ssh\id_rsa"
Если вы не смогли подключиться к вашему SSH серверу по RSA ключу, и у вас все равно запрашивается пароль, скорее всего пользователь, под которым вы подключаетесь, входит в группу локальных администраторов сервера (SID группы S-1-5-32-544). Об этом далее.
В OpenSSH используются особые настройки доступа по ключам для пользователей с правами локального администратора Windows.
В первую очередь, вместо ключа authorized_keys в профиле пользователя нужно использовать файл с ключами C:\ProgramData\ssh\administrators_authorized_keys. Вам нужно добавить ваш ключ в этот текстовый файл (в целях безопасности права на этот файл должны быть только у группы Administrators и SYSTEM).
Дополнительно в файле sshd_config вы можете разрешить вход по RSA ключам:
И запретить доступ по паролю:
После сохранения изменений в файле sshd_config не забудьте перезапустить службу sshd.
Еще один небольшой нюанс. В старых версиях OpenSSH нужно было предоставить права службе NT Service\sshd на чтение ключа authorized_keys.
Для этого нужно выполнить одно из следующих действий:
Итак, вы настроили SSH аутентификацию в Windows по открытому RSA-ключу (сертификату). Теперь вы можете использовать такой способ аутентификации для безопасного доступа к удаленным северам, автоматического поднятия проброса портов в SSH туннеле, запуска скриптов и других задачах автоматизации.
Предыдущая статья Следующая статья
debug1: Found key in C:\\Users\\\320\237\320\276\320\273\321\214\320\267\320\276\320\262\320\260\321\202\320\265\320\273\321\214/.ssh/known_hosts:9
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug2: key: C:\\Users\\\320\237\320\276\320\273\321\214\320\267\320\276\320\262\320\260\321\202\320\265\320\273\321\214/.ssh/id_rsa (000002372A7B17D0), agent
debug2: key: C:\\Users\\\320\237\320\276\320\273\321\214\320\267\320\276\320\262\320\260\321\202\320\265\320\273\321\214/.ssh/id_dsa (0000000000000000)
debug2: key: C:\\Users\\\320\237\320\276\320\273\321\214\320\267\320\276\320\262\320\260\321\202\320\265\320\273\321\214/.ssh/id_ecdsa (0000000000000000)
debug2: key: C:\\Users\\\320\237\320\276\320\273\321\214\320\267\320\276\320\262\320\260\321\202\320\265\320\273\321\214/.ssh/id_ed25519 (0000000000000000)
debug2: key: C:\\Users\\\320\237\320\276\320\273\321\214\320\267\320\276\320\262\320\260\321\202\320\265\320\273\321\214/.ssh/id_xmss (0000000000000000)
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:5U76PQzmZJ7xce9TDvyt1P/sqNCX/GHOZSLk3TR3x1o C:\\Users\\\320\237\320\276\320\273\321\214\320\267\320\276\320\262\320\260\321\202\320\265\320\273\321\214/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: C:\\Users\\\320\237\320\276\320\273\321\214\320\267\320\276\320\262\320\260\321\202\320\265\320\273\321\214/.ssh/id_dsa
Можете подсказать что не так?
Какую команду используете для SSH подключения? Ключ добавлен в ssh-agent?
Попробуйте указать путь к вашему файлу с закрытым ключом вручную:
ssh root@192.168.1.90 -i "C:\Users\user1\.ssh\id_rsa"
Скорее всего вы запускали cmd\powershell.exe в режиме administrator, поэтому путь по-умолчанию был c:\windows\system32
А как это работает, если сервер на Linux, а клиент на Windows?
Да, все аналогично. Только в linux другое место хранения ключей (в зависимости от дистрибутива)
В файле authorized_keys можно указывать несколько ключей. Просто скопируйте значение второго ключа с новой строки и сохраните файл.
В этой статье описывается настройка сервера OpenSSH (sshd) для ОС Windows.
Настройка стандартной оболочки OpenSSH для Windows
Стандартная оболочка командной строки предоставляет пользователю интерфейс, который он увидит при подключении к серверу по протоколу SSH. По умолчанию в среде Windows изначально используется командная оболочка Windows (cmd.exe). Кроме того, Windows включает PowerShell и Bash, и вы можете настроить в качестве оболочки по умолчанию для сервера любую из оболочек командной строки сторонних производителей, которые предоставляются для Windows.
Чтобы задать командную оболочку по умолчанию, для начала убедитесь, что папка установки OpenSSH находится в системном пути. В среде Windows по умолчанию она устанавливается в папку SystemDrive:WindowsDirectory\System32\openssh. Следующие команды позволяют узнать текущее значение пути (переменную среды path) и добавить к нему стандартную папку установки OpenSSH.
| Командная оболочка | Используемая команда |
|---|---|
| Команда | путь |
| PowerShell | $env:path |
Настройка оболочки SSH по умолчанию выполняется в реестре Windows, где вам нужно добавить полный путь к исполняемому файлу оболочки в строковое значение DefaultShell в разделе Computer\HKEY_LOCAL_MACHINE\SOFTWARE\OpenSSH.
Например, следующая команда PowerShell устанавливает PowerShell.exe в качестве оболочки по умолчанию:
Конфигурация Windows в файле sshd_config
В среде Windows программа sshd по умолчанию считывает данные конфигурации из файла %programdata%\ssh\sshd_config, но вы можете указать другой файл конфигурации, запустив команду sshd.exe с параметром -f. Если указанный файл отсутствует, sshd создаст новый файл с конфигурацией по умолчанию при запуске службы.
Ниже перечислены элементы конфигурации специально для среды Windows, которые можно указать в sshd_config. Существуют и другие параметры конфигурации, которые здесь не перечислены, так как они подробно описаны в документации по OpenSSH для Win32 в Интернете.
AllowGroups, AllowUsers, DenyGroups, DenyUsers
Управление тем, какие пользователи и группы могут подключаться к серверу, осуществляется с помощью директив AllowGroups, AllowUsers, DenyGroups и DenyUsers. Директивы разрешения и запрета обрабатываются в следующем порядке: DenyUsers, AllowUsers, DenyGroups и наконец AllowGroups. Все имена учетных записей должны быть указаны в нижнем регистре. Дополнительные сведения о шаблонах с подстановочными знаками вы найдете в разделе PATTERNS непосредственно в файле ssh_config.
При настройке правил для пользователей и (или) групп в домене используйте следующий формат: user?domain* . Windows поддерживает несколько форматов для указания субъектов домена, но многие из них конфликтуют со стандартными шаблонами в Linux. По этой причине добавлен символ *, чтобы поддерживать полные доменные имена. Кроме того, этот подход использует "?" вместо "@", чтобы избежать конфликтов с форматом username@host.
Пользователи и группы, входящие в рабочие группы, а также подключенные к Интернету учетные записи всегда разрешаются в имена локальных учетных записей (без сегмента домена, примерно как стандартные имена в UNIX). Пользователи и группы домена строго разрешаются в формат NameSamCompatible, то есть "короткое_имя_домена\имя_пользователя". Все правила конфигурации для пользователей и групп должны соответствовать этому формату.
Примеры для пользователей и групп домена
Примеры для локальных пользователей и групп
AuthenticationMethods
Для OpenSSH в Windows поддерживаются только методы проверки подлинности "password" и "publickey".
AuthorizedKeysFile
По умолчанию используется значение .ssh/authorized_keys .ssh/authorized_keys2. Если путь не является абсолютным, он вычисляется относительно основного каталога пользователя (или пути к образу профиля). Например: c:\users\user. Обратите внимание, что если пользователь входит в группу администраторов, используется %programdata%/ssh/administrators_authorized_keys.
ChrootDirectory (добавлена поддержка в версии 7.7.0.0)
Эта директива поддерживается только для сеансов SFTP. Удаленный сеанс подключения к cmd.exe не учитывает ее. Чтобы настроить сервер chroot только для SFTP, укажите параметр ForceCommand со значением internal-sftp. Вы также можете настроить SCP с поддержкой chroot, реализовав пользовательскую оболочку, которая допускает только SCP и SFTP.
HostKey
По умолчанию используются значения %programdata%/ssh/ssh_host_ecdsa_key, %programdata%/ssh/ssh_host_ed25519_key, %programdata%/ssh/ssh_host_dsa_key и %programdata%/ssh/ssh_host_rsa_key. Если эти файлы отсутствуют, sshd автоматически создает их при запуске службы.
Сопоставление
Обратите внимание на правила шаблона в этом разделе. Имена пользователей и групп должны быть в нижнем регистре.
PermitRootLogin
Неприменимо в ОС Windows. Чтобы предотвратить вход администратора, примените для группы Administrators директиву DenyGroups.
SyslogFacility
Если вам требуется ведение журнала в файле, используйте LOCAL0. Журналы создаются в папке %programdata%\ssh\logs. Любое другое значение, включая используемое по умолчанию AUTH, направляет журналы в ETW. Дополнительные сведения см. в статье о возможностях по ведению журнала в Windows.
Не поддерживается
Следующие параметры конфигурации недоступны в версии OpenSSH, которая поставляется в составе Windows Server 2019 и Windows 10 версии 1809:
Описываются особенности настройки встроенного в Windows 10 SSH сервера для обеспечения доступа к нему по ключам без ввода пароля, в том числе, приёмы для передачи публичных ключей и установки прав доступа к файлам с ними.
Евгений Боздаганян
Read more posts by this author.
Евгений Боздаганян
Введение
Начиная с верcии 1803 , в Windows 10 доступны SSH клиент и SSH сервер, причём, SSH клиент установлен и готов к использованию, как говорится, прямо из коробки, а SSH сервер надо устанавливать, но делается это буквально в пару-тройку кликов мышкой [1] . Что это означает? С точки зрения клиента можно говорить о том, что сторонние программы, такие как PuTTY , вроде как больше не нужны. С точки зрения сервера - не надо устанавливать никакие сторонние серверы, если есть решение интегрированное.
В работе что клиент, что сервер, практически не отличаются от того ПО, к которому я привык в Debian . Но, как ни крути, есть некоторые отличия, и вот об одном из них попробую сейчас рассказать. Речь пойдет о подключении к SSH серверу, работающему на Windows , с клиента, в моем случае, работающего на Debian Jessie , причем, без использования пароля, то есть, задействуя ключи.
На самом деле, начало процесса не отличается от стандартного: если у вас нет набора ключей, вам его надо сгенерировать, если есть - используйте существующий. Речь сейчас идёт о той машине, которая будет клиентом. И я уже как-то писал об этом, но на некоторых моментах всё-таки остановлюсь ещё раз: повторенье - мать ученья 😉.
Про генерацию ключей
Итак, если ключей нет и вы работаете на системе под управлением Linux , то вот эта команда поможет вам их сгенерировать:
Если же вы работаете под Windows , то у вас есть несколько возможностей сгенерировать ключи:
- Если вы работаете под Windows 10 и включили возможность использовать встроенный SSH клиент, то смело используйте команду ssh-keygen - должно сработать. 🙄😉
- Если вы работаете под Windows 10 и включили возможность использовать WSL, то можете воспользоваться возможностями этой подсистемы, то есть, использовать в ней. всё ту же команду ssh-keygen .
- Если вы работаете под Windows 10 и у вас не установлен встроенный SSH клиент и не включена возможность использования WSL , или же у вас более ранняя версия Windows , то придется использовать стороннее ПО, тот же PuTTY с его генератором PuTTYgen - для этого случая есть достаточно подробная документация.
Если пара ключей успешно сгенерирована, или уже была у вас, то необходимо "доставить" публичный ключ на сервер и там сделать его доступным для использования SSH сервером. И вот тут то и начинаются отличия от обычного - для мира Linux - процесса.
Доставка публичного ключа на сервер Linux
Что я делал, когда мне надо было "доставить" ключ на SSH сервер, работающий на Linux ? Всё очень просто - запуск следующей команды на клиентской машине решал все вопросы:
где user_name - имя пользователя, ключ которого передаётся на сервер, а server_name_or_ip - имя или адрес хоста с сервером SSH , к которому есть желание подключаться без ввода пароля (от имени пользователя с ключом). Иногда команда не работала и приходилось явно указывать файл (при помощи параметра командной строки -i ), в котором хранился публичный ключ, но это, в большей степени, зависело от устройства, на котором выполнялась эта команда, вернее, от версии ОС, ну и от реализации и версии криптографического ПО, конечно.
Доставка публичного ключа на сервер Windows
Но, в случае, когда в качестве сервера выступает машина с Windows , этот приём не прокатывает - ключ не передаётся на нужный хост и всё. Не знаю, эксперименты эти я проводил довольно давно, может, в новых версиях Windows эту "особенность" исправили, а может и нет. В любом случае, тогда мне пришлось искать обходной путь.
Собственно, сам этот путь очевиден - раз не получается сделать передачу ключа автоматом, надо всё выполнить вручную. А для этого необходимо знать, где и как Windows хранит публичные ключи, используемые SSH сервером для аутентификации клиентов. К счастью, в документации Microsoft есть необходимая информация и её надо просто использовать. Давайте её детально разберём, при том держа в уме, что документация предполагает работу с клиентской машины под управлением Windows с заранее настроенным доступом по SSH к необходимому серверу.
Создание каталога для хранения ключей
Итак, из документации становится очевидно, что Windows хранит пользовательские ключи, используя тот же принцип, что и Linux : на сервере в файле authorized_keys в подкаталоге .ssh домашнего каталога пользователя (а это, как правило, c:\Users\user_name , где user_name - имя пользователя), от имени которого вы хотите работать в установившемся SSH сеансе. Если этого каталога нет, его надо создать, для чего предлагается использовать команду:
где user_name - имя пользователя, domain_name - имя домена, в который входит пользователь (его можно опустить для локальных пользователей на удалённом сервере), host_name - имя или адрес хоста, к которому подключаемся. Приведённая мною команда несколько отличается от той, которая дана в документации, но следует помнить, что я работаю с клиентской машины под управлением Linux .
Копирование публичного ключа
Далее, предлагается скопировать во вновь созданный каталог файл с публичным ключом пользователя, от имени которого вы работаете на клиентской машине при подключении к серверу по SSH (команда слегка отличается от той, которая приведена в документации, так как я работаю с машины под управлением Debian ):
где public_key_file_name.pub - имя файла публичного ключа, например, id_ed25519.pub или id_rsa.pub (далее в примерах я буду использовать для простоты id_rsa.pub ).
На этом моменте хотелось бы остановиться подробнее. Обычно вы работаете на своём компьютере (или виртуалке) под своим собственным пользователем. Когда вы подключаетесь к удалённой машине по SSH , вы можете подключаться под именем своего текущего пользователя локальной машины, или использовать имя какого-либо пользователя удалённого компьютера, или же - доменное имя. Конечно, в любом случае на удалённом хосте должен существовать соответствующий пользователь (или разрешено использовать доменное имя), даже если его имя будет совпадать с именем пользователя, под которым вы работаете на своём локальном хосте. Так вот, совсем не обязательно, что вы единственный подключаетесь к удалённому хосту под определенным пользователем, вполне возможно, что с других хостов другие люди (или вы сами?) также подключаются по SSH , используя ту же самую учётную запись.
Возможно то, что я написал выше, это "ужас-ужас" с точки зрения безопасности, но такая ситуация весьма вероятна в домашних и небольших офисных сетях (да и не только 🙁), в которых не сильно заморачиваются с администрированием. И вот в таких случаях, копировать файл со своим публичным ключом - плохая идея: вы просто затрёте существующий файл authorized_keys с публичными ключами других пользователей (или ваших собственных ключей на других компьютерах - вряд ли вы переносите свою единственную пару ключей с хоста на хост 😉). Поэтому следует рассмотреть возможность добавлять свой ключ к соответствующему файлу на удалённом хосте.
Добавление публичного ключа
Обратите внимание на использование символов '/' в команде scp и '\' в командах ssh - так как мы работаем на Debian , то в команду scp можно передать путь на хосте с Windows с использованием нестандартного для Windows разделителя '/', а вот в команды, выполняемые при помощи ssh на том же удалённом компьютере, следует передавать символы '\',то есть, стандартный для Windows разделитель '\' с предшествующим символом '\', так называемый "escaped backslash", иначе Windows не найдёт нужные файлы.
Назначение прав доступа к файлу с публичными ключами
Вот мы и подошли к последнему шагу - предоставлению прав доступа к файлу authorized_keys . Именно этим занимается команда:
Основную смысловую нагрузку в этой составной команде несёт функция Repair-AuthorizedKeyPermission из модуля OpenSSHUtils для PowerShell (да, именно PowerShell используется в качестве командной оболочки в этот раз). Этот модуль надо устанавливать отдельно, например, так (выполнять эту команду надо, естественно, из PowerShell ):
Естествено, я начал разбираться в сложившейся ситуации, после чего, если честно, желание использовать этот модуль у меня стало исчезающе малым.
"Не используйте этот модуль, он дополнительно предоставит права пользователю sshd , после чего у вас перестанут соблюдаться требования к безопасности публичных ключей."
Вот честно, не знаю, так это, или нет, но проверять расхотелось, тем более, что совсем не трудно задать нужные права самостоятельно. После некоторого изучения вопроса - я не большой специалист в PowerShell - получился вот такой вот набор команд [2] (я приведу их полностью, потом разберу для чего нужна каждая из них):
Теперь, как и обещал, небольшие пояснения по командам. Итак, для начала, при помощи cmdlet -а Get-Acl получаем дескриптор безопасности, содержащий ACL (Access Control List) нужного нам объекта файловой системы (параметр командной строки Path можно опустить) и сохраняем результат в переменной $acl . Далее, используя метод SetAccessRuleProtection полученного объекта, запрещаем наследование прав ( true в первом параметре) и отказываемся от сохранения унаследованных ранее прав ( false во втором параметре). Затем создаём два объекта, описывающих правила доступа к объектам файловой системы: один (сохраняется в переменной $adminsRule ) - для Администраторов, второй (сохраняется в переменной $sysRule ) - для специального пользователя SYSTEM . Теперь, при помощи метода SetAccessRule, добавляем только что соданные ACL к дескриптору безопасности нашего файла, хранящегося в переменной $acl . После чего, всё, что нам остаётся сделать - применить полученный дескриптор, для чего используем cmdlet Set-Acl.
Ну вот, теперь, когда мы выполнили все шаги, всё должно заработать. Но, в моём случае, не заработало. Очередная неудача заставила меня вновь полезть в документацию, что обогатило меня новыми знаниями. Рассказываю.
Публичные ключи для работы от имени пользователей администраторов
Причиной того, что при соединении с SSH сервером мне, несмотря на все предыдущие мытарства, продолжало выводиться требование ввести пароль, было то, что я пытался подключиться под пользователем, который входил в группу локальных Администраторов. У Windows 10 в этом случае есть требование - публичные ключи должны храниться в файле %programdata%/ssh/administrators_authorized_keys , то есть, обычно, в C:\ProgramData\ssh\administrators_authorized_keys .
Что ж, для того, чтобы решить проблему, можно воспользоваться двумя путями. Первый путь - воспользоваться процедурой добавления публичного ключа, рассмотренной нами выше. Да-да, все эти шаги: копирование, добавление, предоставление прав, только применяем их не к authorized_keys , а к administrators_authorized_keys . Я напишу, на всякий случай, полную последовательность команд, чтобы удобно было воспользоваться, но не забудьте подставить свои значения для пользователя, домена и хоста.
Второй путь чуть более радикальный - изменить настройки SSH сервиса. Настройки эти хранятся в файле %programdata%/ssh/sshd_config . Как оказалось, именно там определяется, где должны храниться публичные ключи тех пользователей, которые подключаются к SSH серверу от имени пользователей, входящих в группу администраторов. Вот, собственно, эти строки:
Так вот, эти строки надо закомментировать или удалить, после чего SSH сервер надо перезапустить.
Какой путь использовать - решать вам. Я же, пожалуй, закончу - пост получился и так слишком длинным.
На самом деле, в виде beta версий эти компоненты были доступны и раньше, но и установка и стабильность работы, были, что называется, не на высоте. ↩︎
Честно признаюсь, очень многое я подсмотрел в документации, например, как отключить наследование прав, или предоставить Администраторам полный контроль над файлом, и лишь немного адаптировал эти примеры к собственным нуждам. ↩︎
В настоящей статье описан алгоритм настройки SSH-клиента Putty для ОС Windows для работы с JaCarta PKI.
JaCarta PKI – токены производства компании «Аладдин Р.Д.» для строгой двухфакторной аутентификации пользователей при доступе к защищённым информационным ресурсам предприятия, безопасного хранения ключей и ключевых контейнеров программных СКЗИ.
Общие сведения
SSH — сетевой протокол прикладного уровня, позволяющий производить удалённое управление операционной системой и туннелирование TCP-соединений. Шифрует весь трафик, включая и передаваемые пароли. SSH допускает выбор различных алгоритмов шифрования. SSH-клиенты и SSH-серверы доступны для большинства сетевых операционных систем.
SSH поддерживает возможность аутентификации по RSA-ключу, что обеспечивает максимальный уровень безопасности для канала передачи данных, а также двухфакторную аутентификацию удалённых пользователей.
Аутентификация по сертификату
Для настройки работы SSH по RSA-сертификатам необходимо настроить SSH-сервер, а также SSH-клиента на клиентской машине. В данном документе описан алгоритм настройки работы SSH с использованием смарт-карты, либо токена JaCarta PKI для целей аутентификации и шифрования установленного канала.
Настройка смарт-карт для SSH-клиента
Порядок настройки серверной части на примере Ubuntu
Генерация ключевой пары утилитой ssh-keygen
- Перейти в директорию /home/user/.ssh
- ssh-keygen -t rsa
- Задать имя ключа, например, key
- Задать пароль ключа (для шифрования закрытого ключа), например, 12345678
- На выходе получаем два файла, например, key и key.pub
Генерация запроса на сертификат с ключами из п. 1
Выпуск сертификата в CA openssl
- Настройка openssl CA
- cd /etc/ssl
- sudo -i
- echo “01” > serial
- cp /dev/null index.txt
- Редактируем /etc/ssl/openssl.cnf nano openssl.cnf
- dir = ./
- certs = $dir/certs
- crl_dir = $dir/crl
- database = $dir/index.txt
- new_certs_dir = $dir/certs
- certificate = $dir/ca.crt
- serial = $dir/serial
- crl = $dir/crl.pem
- private_key = $dir/ca.key
- sudo -i
- cd /home/user/.ssh
- openssl ca -out user.crt -infiles user.req
Импорт открытого ключа в Autorized_keys
- В директории /home/user/.ssh должен находиться файл открытого ключа, содержащий ssh-rsa . В примере мы создали файл с именем key.pub
- Импортируем данный ключ в файл authorized_keys
- echo key.pub > authorized_keys
Донастройка серверной части
- chmod 700 authorized_keys
- Настройки openssh. В /etc/ssh/sshd.conf редактируем конфигурацию аутентификации
- RSAAuthentication yes
- PubkeyAuthentication yes
- PasswordAuthentication no — отказ от аутентификации по паролю (опционально)
Запись сертификата на смарт-карту
Необходимо перенести сертификат на смарт-карту. Для переноса необходимо собрать все необходимые объекты в зашифрованный контейнер и записать его на смарт-карту.
- openssl pkcs12 -export -in user.crt -inkey key -certfile ca.crt -name «user» -out user.pfx
- Перенос файла user.pfx на Windows систему с установленным ПО «Единый Клиент JaCarta», либо JC Client
- Ввод PIN-кода пользователя
Проверка работоспособности сертификата
ssh -I /usr/lib/x86-athena/libASEP11.so 127.0.0.1
Настройка SSH-клиента Putty на ОС Windows
Запуск утилит из дистрибутива putty-cac\executables
Выбор сертификата в pageant
В общем случае сертификат появляется в хранилище сертификатов автоматически, но в некоторых случаях может потребоваться его добавление вручную.
Читайте также: