openssh authentication agent windows 10 что это
Использование встроенного SSH клиента в Windows 10
В Windows 10 и Windows Server 2019 появился встроенный SSH клиент, который вы можете использовать для подключения к *Nix серверам, ESXi хостам и другим устройствам по защищенному протоколу, вместо Putty, MTPuTTY или других сторонних SSH клиентов. Встроенный SSH клиент Windows основан на порте OpenSSH и предустановлен в ОС, начиная с Windows 10 1809.
Установка клиента OpenSSH в Windows 10
Клиент OpenSSH входит в состав Features on Demand Windows 10 (как и RSAT). Клиент SSH установлен по умолчанию в Windows Server 2019 и Windows 10 1809 и более новых билдах.
Проверьте, что SSH клиент установлен:
В нашем примере клиент OpenSSH установлен (статус: State: Installed).
Если SSH клиент отсутствует (State: Not Present), его можно установить:
]Бинарные файлы OpenSSH находятся в каталоге c:\windows\system32\OpenSSH\.
Как использовать SSH клиенте в Windows 10?
ssh
usage: ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
[-D [bind_address:]port] [-E log_file] [-e escape_char]
[-F configfile] [-I pkcs11] [-i identity_file]
[-J [user@]host[:port]] [-L address] [-l login_name] [-m mac_spec]
[-O ctl_cmd] [-o option] [-p port] [-Q query_option] [-R address]
[-S ctl_path] [-W host:port] [-w local_tun[:remote_tun]]
destination [command]
Для подключения к удаленному серверу по SSH используется команда:
Если SSH сервер запущен на нестандартном порту, отличном от TCP/22, можно указать номер порта:
Например, чтобы подключиться к Linux хосту с IP адресом 192.168.1.202 под root, выполните:
Затем появится запрос пароля указанной учетной записи, укажите пароль root, после чего должна открытся консоль удаленного Linux сервера (в моем примере на удаленном сервере установлен CentOS 8).
Если вы используете SSH аутентификацию по RSA ключам (см. пример с настройкой SSH аутентификации по ключам в Windows), вы можете указать путь к файлу с закрытым ключом в клиенте SSH так:
Также вы можете добавить ваш закрытый ключ в SSH-Agent. Сначала нужно включить службу ssh-agent и настроить ее автозапуск:
set-service ssh-agent StartupType ‘Automatic’
Start-Service ssh-agent
Добавим ваш закрытый ключ в базу ssh-agent:
Теперь вы можете подключиться к серверу по SSH без указания пути к RSA ключу, он будет использоваться автоматически. Пароль для подключения не запрашивается (если только вы не защитили ваш RSA ключ отдельным паролем):
Еще несколько полезных аргументов SSH:
SCP: копирование файлов из/в Windows через SSH
С помощью утилиты scp.exe, которая входит в состав пакета клиента SSH, вы можете скопировать файл с вашего компьютера на SSH сервер:
scp.exe «E:\ISO\CentOS-8.1.1911-x86_64.iso» root@192.168.1.202:/home
Можно рекурсивно скопировать все содержимое каталога:
И наоборот, вы можете скопировать файл с удаленного сервера на ваш компьютер:
scp.exe root@192.168.1.202:/home/CentOS-8.1.1911-x86_64.iso e:\tmp
Итак, теперь вы можете прямо из Windows 10 подключаться к SSH серверам, копировать файлы с помощью scp без установки сторонних приложений и утилит.
Настройка SSH аутентификации по ключам в Windows 10 / 2019
В этой статье мы настроим 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 устанавливается как отдельный встроенный компонент:
Запустите обычную (непривилегированную сессию PowerShell) и сгенерируйте пару RSA 2048 ключей с помощью команды:
Утилита попросит вас указать пароль для защиты закрытого ключа. Если вы укажете пароль, то каждый раз при использовании этого ключа для SSH авторизации, вы должны будете вводить этот пароль. Я не стал указывать пароль для ключа (не рекомендуется).
Утилита ssh-keygen создаст каталог .ssh в профиле текущего пользователя Windows (C:\Users\your_username) и поместит в него 2 файла:
После того, как ключи созданы, вы можете добавить закрытый ключ в службу 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).
Можно скопировать ключ на 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 серверу по RSA ключу, и у вас все равно запрашивается пароль, скорее всего пользователь, под которым вы подключаетесь, входит в группу локальных администраторов сервера (SID группы S-1-5-32-544). Об этом далее.
Вход по SSH ключу для локальных администраторов Windows
В OpenSSH используются особые настройки доступа по ключам для пользователей с правами локального администратора Windows.
В первую очередь, вместо ключа authorized_keys в профиле пользователя нужно использовать файл с ключами C:\ProgramData\ssh\administrators_authorized_keys. Вам нужно добавить ваш ключ в этот текстовый файл (в целях безопасности права на этот файл должны быть только у группы Administrators и SYSTEM).
Чтобы использовать ключ authorized_keys из профиля пользователя, и не переносить данные открытого ключа в файл administrators_authorized_keys, вы можете закомментировать строку в файле конфигурации OpenSSH («C:\ProgramData\ssh\sshd_config«).
Дополнительно в файле 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
Можете подсказать что не так?
При генерации ключа не нашел файлы в профиле пользователя. Они были в «C:\Windows\System32»
Скорее всего вы запускали cmd\powershell.exe в режиме administrator, поэтому путь по-умолчанию был c:\windows\system32
А как это работает, если сервер на Linux, а клиент на Windows?
Да, все аналогично. Только в linux другое место хранения ключей (в зависимости от дистрибутива)
Ну наконец то получилось по ssh ключу подключиться. Мне нужно было настроить SFTP на Windows 10. Имеются 3 компа, на первом Windows 10 с openssh server и запущенным процессом sftp-server.exe, на втором компе клиенте тоже Windows 10 установил openssh client, сгенерировал публичный и приватный ключ, публичный скопировал на первый комп с Windows 10 где установлен openssh server, переименовал его из id_rsa.pub в authorized_keys. Затем на втором компе клиенте нужно установить PuTTY Key Generator и сконвертировать приватный ключ id_rsa в id_rsa.ppk это нужно чтобы подключиться по SFTP через WinSCP или FileZilla client к серверу openssh. Проблема была в том что всё равно просил пароль от учётной записи администратора от первого компа на сервере. После того как прописал «PubkeyAuthentication yes» и «PasswordAuthentication no» затем «StrictModes no» и закомментировал «# AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys» стало заходить без пароля. Есть ещё вопрос. Третий комп это ноутбук с Kubuntu, установил FileZilla client, уже имеется каталог по адресу /home/sergei/.ssh/ в этот каталог скопировал файл id_rsa.ppk со второго компа, то есть с Windows 10. При подключении FileZilla client выбираю протокол SFTP всё как положено, указываю файл с приватным ключом /home/sergei/.ssh/id_rsa.ppk и подключаюсь без ввода пароля, всё работает. Но я так понимаю что это неправильно? На Kubuntu тоже надо генерировать ключи приватный и публичный? И где тогда размещать новый публичный ключ на сервере, если на нём уже есть C:\Users\Sergei\.ssh\authorized_keys
В файле authorized_keys можно указывать несколько ключей. Просто скопируйте значение второго ключа с новой строки и сохраните файл.
Установка OpenSSH
Область применения Windows Server 2019, Windows 10: Windows Server 2022,
OpenSSH — это средство подключения для удаленного входа, использующее протокол SSH. Оно шифрует весь трафик между клиентом и сервером для предотвращения перехвата информации, перехвата подключения и других атак.
OpenSSH можно использовать для подключения устройств с Windows 10 (версия 1809 и более поздние) или Windows Server 2019 с установленным клиентом OpenSSH к таким устройствам с установленным сервером OpenSSH.
Если вы скачали OpenSSH из репозитория GitHub по адресу PowerShell/openssh-portable, следуйте приведенным в репозитории инструкциям, а не инструкциям в этой статье.
Установка OpenSSH с помощью приложения «Параметры» в Windows
Оба компонента OpenSSH можно установить с помощью «Параметров» Windows на устройствах Windows Server 2019 и Windows 10.
Чтобы установить компоненты OpenSSH, сделайте следующее:
Откройте приложение Параметры, выберите элементы Приложения > Приложения и возможности, щелкните Дополнительные возможности.
Просмотрите этот список и определите, установлено ли средство OpenSSH. Если нет, выберите пункт Добавить компонент в верхней части страницы и сделайте следующее:
После завершения установки вернитесь в раздел Приложения > Приложения и возможности и Дополнительные возможности, где теперь должно появиться средство OpenSSH.
Установка OpenSSH с помощью PowerShell
Чтобы установить OpenSSH с помощью PowerShell, запустите PowerShell от имени администратора. Для проверки доступности OpenSSH выполните следующий командлет:
Если ни один из них не установлен, должно отобразиться следующее:
Затем установите нужный серверный или клиентский компонент:
Оба командлета должны вернуть такие выходные данные:
Запуск и настройка OpenSSH Server
Чтобы запустить и настроить OpenSSH Server для первого использования, откройте PowerShell от имени администратора и выполните следующие команды для запуска sshd service :
Подключение к OpenSSH Server
После установки вы можете подключиться к серверу OpenSSH с устройства Windows 10 или Windows Server 2019, на котором установлен клиент OpenSSH, с помощью PowerShell, как показано ниже. Обязательно запустите PowerShell от имени администратора:
Когда подключение будет установлено, отобразится примерно следующее сообщение:
Если выбрать Да, этот сервер будет добавлен в список известных узлов SSH в клиенте Windows.
На этом этапе нужно ввести пароль. В целях безопасности пароль не будет отображаться по мере ввода.
После подключения вы увидите командную оболочку Windows:
Удаление OpenSSH с помощью приложения «Параметры» в Windows
Чтобы удалить OpenSSH с помощью приложения «Параметры» в Windows, сделайте следующее:
Удаление OpenSSH с помощью PowerShell
Чтобы удалить компоненты OpenSSH с помощью PowerShell, выполните следующие команды:
Если служба использовалась во время удаления, может потребоваться перезагрузка Windows.
Про SSH Agent
Введение
SSH-agent является частью OpenSSH. В этом посте я объясню, что такое агент, как его использовать и как он работает, чтобы сохранить ваши ключи в безопасности. Я также опишу переадресацию агента и то, как она работает. Я помогу вам снизить риск при использовании переадресации агента и поделюсь альтернативой переадресации агента, которую вы можете использовать при доступе к своим внутренним хостам через bastion’ы.
Что такое SSH-agent
Агент SSH хранит секретные ключи в безопасности из-за того, что он не делает:
Но если агент может только подписывать сообщения, как SSH шифрует и расшифровывает трафик?
При первом изучении открытых и закрытых ключей SSH естественно предположить, что SSH использует эти пары ключей для шифрования и дешифрования трафика. Именно так я и думал. Но это не тот случай. Пара ключей SSH используется только для аутентификации во время первоначального соединения.
Например, вот как проверяется ключ пользователя во время SSH-соединения, с точки зрения сервера:
Протокол агента
Протокол агента настолько прост, что можно было бы написать базовый SSH-agent за день или два. Он имеет только несколько основных операций:
Команда ssh-add — это ваш шлюз к агенту SSH. Он выполняет все эти операции, кроме подписи. Когда вы запускаете ssh-add без каких-либо параметров, он будет сканировать ваш домашний каталог на наличие некоторых стандартных ключей и добавлять их в ваш агент. По умолчанию он ищет:
Что такое переадресация агента
Функция переадресации агента позволяет вашему локальному агенту SSH связаться через существующее SSH-соединение и прозрачно аутентифицироваться на более удаленном сервере. Например, предположим, что вы входите по SSH в инстанс EC2 и хотите клонировать оттуда приватный репозиторий GitHub. Без переадресации агента вам придется хранить копию вашего приватного ключа GitHub на хосте EC2. При переадресации агента SSH-клиент на EC2 может использовать ключи на вашем локальном компьютере для аутентификации на GitHub.
Как работает переадресация агента
Переадресация агента связана с определенным риском
Когда вы переадресовываете доменный сокет ssh-agent Unix на удаленный хост, это создает угрозу безопасности: любой человек с root доступом на удаленном хосте может незаметно получить доступ к вашему локальному SSH-agent’y через сокет. Они могут использовать ваши ключи, чтобы выдавать себя за вас на других машинах в сети.
Вот пример того, как это может выглядеть:
Как снизить свой риск при переадресации агента
Вот несколько способов сделать переадресацию агента более безопасной:
Или используйте альтернативный агент SSH, который запрашивает вас, когда он используется. Sekey использует Touch ID на macOS для хранения ключей в анклаве безопасности MacBook Pro.
Или вообще не используйте переадресацию агента. Если вы пытаетесь получить доступ к внутренним хостам через bastion, ProxyJump — гораздо более безопасная альтернатива для этого варианта использования. (смотреть ниже)
Используйте ProxyJump : более безопасная альтернатива
Вместо того чтобы перенаправлять agent’a по отдельному каналу, ProxyJump перенаправляет стандартный вход и выход вашего локального SSH-клиента через bastion и далее на удаленный хост. Вот как это работает:
Затем я просто запускаю ssh cloud.computer.internal для подключения к внутреннему назначению через bastion — без переадресации агента.
Если ProxyJump не работает…
Узнайте подробности, как получить востребованную профессию с нуля или Level Up по навыкам и зарплате, пройдя онлайн-курсы SkillFactory:
Openssh authentication agent что это за служба windows 10
Использование встроенного SSH клиента в Windows 10
В Windows 10 и Windows Server 2019 появился встроенный SSH клиент, который вы можете использовать для подключения к *Nix серверам, ESXi хостам и другим устройствам по защищенному протоколу, вместо Putty, MTPuTTY или других сторонних SSH клиентов. Встроенный SSH клиент Windows основан на порте OpenSSH и предустановлен в ОС, начиная с Windows 10 1809.
Установка клиента OpenSSH в Windows 10
Клиент OpenSSH входит в состав Features on Demand Windows 10 (как и RSAT). Клиент SSH установлен по умолчанию в Windows Server 2019 и Windows 10 1809 и более новых билдах.
Проверьте, что SSH клиент установлен:
В нашем примере клиент OpenSSH установлен (статус: State: Installed).
Если SSH клиент отсутствует (State: Not Present), его можно установить:
]Бинарные файлы OpenSSH находятся в каталоге c:\windows\system32\OpenSSH\.
Как использовать SSH клиенте в Windows 10?
ssh
usage: ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
[-D [bind_address:]port] [-E log_file] [-e escape_char]
[-F configfile] [-I pkcs11] [-i identity_file]
[-J [[email protected]]host[:port]] [-L address] [-l login_name] [-m mac_spec]
[-O ctl_cmd] [-o option] [-p port] [-Q query_option] [-R address]
[-S ctl_path] [-W host:port] [-w local_tun[:remote_tun]]
destination [command]
Для подключения к удаленному серверу по SSH используется команда:
Если SSH сервер запущен на нестандартном порту, отличном от TCP/22, можно указать номер порта:
Например, чтобы подключиться к Linux хосту с IP адресом 192.168.1.202 под root, выполните:
Затем появится запрос пароля указанной учетной записи, укажите пароль root, после чего должна открытся консоль удаленного Linux сервера (в моем примере на удаленном сервере установлен CentOS 8).
Если вы используете SSH аутентификацию по RSA ключам (см. пример с настройкой SSH аутентификации по ключам в Windows), вы можете указать путь к файлу с закрытым ключом в клиенте SSH так:
Также вы можете добавить ваш закрытый ключ в SSH-Agent. Сначала нужно включить службу ssh-agent и настроить ее автозапуск:
set-service ssh-agent StartupType ‘Automatic’
Start-Service ssh-agent
Добавим ваш закрытый ключ в базу ssh-agent:
Теперь вы можете подключиться к серверу по SSH без указания пути к RSA ключу, он будет использоваться автоматически. Пароль для подключения не запрашивается (если только вы не защитили ваш RSA ключ отдельным паролем):
Еще несколько полезных аргументов SSH:
SCP: копирование файлов из/в Windows через SSH
С помощью утилиты scp.exe, которая входит в состав пакета клиента SSH, вы можете скопировать файл с вашего компьютера на SSH сервер:
scp.exe «E:\ISO\CentOS-8.1.1911-x86_64.iso» [email protected]:/home
Можно рекурсивно скопировать все содержимое каталога:
И наоборот, вы можете скопировать файл с удаленного сервера на ваш компьютер:
scp.exe [email protected]:/home/CentOS-8.1.1911-x86_64.iso e:\tmp
Итак, теперь вы можете прямо из Windows 10 подключаться к SSH серверам, копировать файлы с помощью scp без установки сторонних приложений и утилит.
Что такое OpenSSH? Как включить и использовать OpenSSH в Windows 10
Что такое OpenSSH
SSH или Secure Shell – это не что иное, как общий протокол, подобный FTP или HTTP, который используется для отправки данных из источника в пункт назначения. Но здесь отправленные данные строго зашифрованы. OpenSSH очень популярен среди разработчиков, работающих на машинах Linux, поскольку он позволяет им получать доступ к удаленному серверу в сети и управлять им.
Прежде чем мы начнем, я хотел бы отметить, что эта функция доступна как бета-версия и может иногда показывать некоторые глюки.
Действия по включению OpenSSH в Windows 10
С функциями Windows:
Перейдите в «Настройки»> «Приложения»> «Приложения и функции» или перейдите по этому адресу:
Теперь нажмите Управление дополнительными функциями.
Выберите Добавить функцию. Это приведет вас к новой странице.
Прокрутите вниз до Клиент OpenSSH (бета) и Сервер OpenSSH (бета) .
Установите их оба и перезагрузите компьютер
Это загрузит и установит все компоненты по этому пути:
Теперь вы можете использовать Powershell или командную строку (CMD), чтобы перейти к указанному пути, а затем начать работать с SSH, как в Linux.
С подсистемой Windows для Linux (WSL)
Установите флажок Подсистема Windows для Linux и нажмите ОК.
Перейдите в магазин Microsoft Store и найдите Ubuntu .
Установите это приложение.
Теперь выполните поиск Ubuntu в меню «Пуск» или в Cortana, чтобы запустить командную строку Linux Bash и использовать возможности SSH.
Наконец, похоже, что Microsoft усиливает использование технологий с открытым исходным кодом, интегрируя их непосредственно в Windows 10 и улучшая их для разработчиков. Это делает утверждение Терри Майерсона (исполнительного вице-президента группы разработчиков Windows в Microsoft) верным, что
«Windows 10 – лучшая чертова девбокс на планете».
И мы не можем дождаться добавления более полезных функций, подобных этой, во встроенную Windows 10!
Настройка SSH аутентификации по ключам в Windows 10 / 2019
В этой статье мы настроим 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 устанавливается как отдельный встроенный компонент:
Запустите обычную (непривилегированную сессию PowerShell) и сгенерируйте пару RSA 2048 ключей с помощью команды:
Утилита попросит вас указать пароль для защиты закрытого ключа. Если вы укажете пароль, то каждый раз при использовании этого ключа для SSH авторизации, вы должны будете вводить этот пароль. Я не стал указывать пароль для ключа (не рекомендуется).
Утилита ssh-keygen создаст каталог .ssh в профиле текущего пользователя Windows (C:\Users\your_username) и поместит в него 2 файла:
После того, как ключи созданы, вы можете добавить закрытый ключ в службу 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).
Можно скопировать ключ на SSH сервер с клиента с помощью SCP:
scp C:\Users\youruser\.ssh\id_rsa.pub [email protected]:c:\users\admin\.ssh\authorized_keys
Теперь вы можете подключиться к SSH серверу без ввода пароля пользователя. А если вы не задали пароль (passphrase) для закрытого ключа, вы сразу автоматически подключитесь к вашему удаленному серверу Windows.
Для подключения через SSH к удаленному хосту используется следующая команда:
ssh (username)@(имя или IP адрес SSH сервера)
Это означает, что вы хотите подключиться к удаленному SSH серверу с адресом 192.168.1.90 под учетной записью admin. Служба SSH Agent автоматически попытается использовать для авторизации сохраненный ранее закрытый ключ.
Если вы не смогли подключиться к вашему SSH серверу по RSA ключу, и у вас все равно запрашивается пароль, скорее всего пользователь, под которым вы подключаетесь, входит в группу локальных администраторов сервера (SID группы S-1-5-32-544). Об этом далее.
Вход по SSH ключу для локальных администраторов Windows
В OpenSSH используются особые настройки доступа по ключам для пользователей с правами локального администратора Windows.
В первую очередь, вместо ключа authorized_keys в профиле пользователя нужно использовать файл с ключами C:\ProgramData\ssh\administrators_authorized_keys. Вам нужно добавить ваш ключ в этот текстовый файл (в целях безопасности права на этот файл должны быть только у группы Administrators и SYSTEM).
Чтобы использовать ключ authorized_keys из профиля пользователя, и не переносить данные открытого ключа в файл administrators_authorized_keys, вы можете закомментировать строку в файле конфигурации OpenSSH («C:\ProgramData\ssh\sshd_config«).
Дополнительно в файле 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
Можете подсказать что не так?
При генерации ключа не нашел файлы в профиле пользователя. Они были в «C:\Windows\System32»
Скорее всего вы запускали cmd\powershell.exe в режиме administrator, поэтому путь по-умолчанию был c:\windows\system32
А как это работает, если сервер на Linux, а клиент на Windows?
Да, все аналогично. Только в linux другое место хранения ключей (в зависимости от дистрибутива)
Ну наконец то получилось по ssh ключу подключиться. Мне нужно было настроить SFTP на Windows 10. Имеются 3 компа, на первом Windows 10 с openssh server и запущенным процессом sftp-server.exe, на втором компе клиенте тоже Windows 10 установил openssh client, сгенерировал публичный и приватный ключ, публичный скопировал на первый комп с Windows 10 где установлен openssh server, переименовал его из id_rsa.pub в authorized_keys. Затем на втором компе клиенте нужно установить PuTTY Key Generator и сконвертировать приватный ключ id_rsa в id_rsa.ppk это нужно чтобы подключиться по SFTP через WinSCP или FileZilla client к серверу openssh. Проблема была в том что всё равно просил пароль от учётной записи администратора от первого компа на сервере. После того как прописал «PubkeyAuthentication yes» и «PasswordAuthentication no» затем «StrictModes no» и закомментировал «# AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys» стало заходить без пароля. Есть ещё вопрос. Третий комп это ноутбук с Kubuntu, установил FileZilla client, уже имеется каталог по адресу /home/sergei/.ssh/ в этот каталог скопировал файл id_rsa.ppk со второго компа, то есть с Windows 10. При подключении FileZilla client выбираю протокол SFTP всё как положено, указываю файл с приватным ключом /home/sergei/.ssh/id_rsa.ppk и подключаюсь без ввода пароля, всё работает. Но я так понимаю что это неправильно? На Kubuntu тоже надо генерировать ключи приватный и публичный? И где тогда размещать новый публичный ключ на сервере, если на нём уже есть C:\Users\Sergei\.ssh\authorized_keys
В файле authorized_keys можно указывать несколько ключей. Просто скопируйте значение второго ключа с новой строки и сохраните файл.
В данной статье я хотел бы рассмотреть продвинутые функции OpenSSH. Мы рассмотрим как теоретическую часть, так и практическую. Зачем.
На одном из моих серверов, в логах я заметил не очень позитивную активность, а именно китайцев, которые перебирали пароли, пытаясь авторизоваться под «админом», «рутом» и прочими логинами. Ок, я бы понял, если бы у меня был бы стандартный порт, но порт у меня был не стандартный, сервер вообще был в качестве тестовой среды и, короче, было странно, я заблокировал пол Китая и забил.
Авторизация по SSH ключу
Собственно в OpenSSH есть такая интересная возможность, как авторизация по ключам. Для корректной работы этого метода используется два ключа, открытый (который publik_key) и закрытый (privat_key соответственно). Открытый ключ должен находится в домашней каталоге пользователя, на сервере, на который мы будем заходить, а закрытый ключ должен обитать в домашнем каталоге пользователя, на ноутбуке (или ПК, смартфоне, телефоне, холодильнике, космическом шатле и т.д.) с которого мы будем ломиться на сервер. Далее, при авторизации, грубо говоря, эти ключи сравниваются, клиент авторизуется на сервер, сервер авторизуется у клиента, и клиент попадает на сервер. Само преимущество этого метода заключается в том, что его нельзя украсть, так как при авторизации ключ не передается на сервер, а только доказывает серверу, что у него есть этот ключ.
Ну если, username, мы смогли тебя убедить в том, что это необходимо, то начнем с генерации ключа. Заходим на наш сервер и генерируем ключ из под обычного пользователя (не root):
Далее в ответ «генератор» задаст нам несколько вопросов:
На этом вопросы заканчиваются, а ключи генерируются. Кстати, непонимающие «гуглочитатели» могут задать вопрос, почему я ввел ключ rsa, а не dsa? Все просто, dsa используется только для цифровой подписи, и не используется для шифрования. Так что смело вводите rsa.
В папке, в которой вы находитесь (или той,которую могли указать) вы найдете два файла, по названиям которых вы поймёте сто там публичное, а что там приватное.
Теперь, установим ключ на сервере:
и настроим openssh сервер, чтобы тот не просил логин и пароль, но мог авторизоваться по ключу. Для этого, уже под root пользователем или при помощи sudo, откроем файл конфигурации openssh любимым редактором:
приведем некоторые параметры к подобному виду:
и перезапустим службу openssh:
Но с сервера пока не выходите, особенно если он далеко от вас..
Теперь займемся настройками ноутбука, с которого вы будите ломиться на сервер.
Для этого скопируем файл закрытого ключа с сервера при помощи такой прекрасной утилиты, как scp:
и добавим ключ для своего ssh клиента:
Все, на это по идее можно закончить настройку авторизации, и авторизовываться на сервере можно таким образом:
Но мне это не особо удобно. Что я имею в виду? Например мы можем авторизовываться на сервер набрав в терминале
Для этого достаточно в файл
/.ssh/config добавить эти строки:
Это называется Алиасом. Подробно ознакомиться с ключами вы можете на OpenNet.ru или набрав команду man ssh_config.
И еще, если вы собираетесь заходить на серверы с операционной системы Windows при помощи Putty, то вам понадобится утилита PuttyGen.
Шифрованное копирование файлов
Да, что то я ранее упоминал про такую штуку, как scp. Это не то, что вы, возможно, прочли на лурке, а это протокол RCP копирования файлов, использующий в качестве транспорта не RSH, а SSH.
При помощи этого протокола вы сможете копировать файл site1.zip на сервер со своего компьютера, в папку
/my_sites вот такой командой:
Можно скопировать файл sites22.zip с сервера на свой ноутбук в папку sites вот такой командой:
А если, вдруг, ваш ssh работает на другом порту, то делаем копирование вот такой командой:
Ну а в нашем случае, при настроенном алиасе в файле
/.ssh/config, скопировать файл мы сможем такой командой:
Удобненько, не правда ли?
На этом, пожалуй, обзор команд я закончу. Этого много есть в интернете, но и пусть будет в моем блоге.
В написании этого шедевра мне помогли следующие ресурсы:
Про SSH Agent
Введение
SSH-agent является частью OpenSSH. В этом посте я объясню, что такое агент, как его использовать и как он работает, чтобы сохранить ваши ключи в безопасности. Я также опишу переадресацию агента и то, как она работает. Я помогу вам снизить риск при использовании переадресации агента и поделюсь альтернативой переадресации агента, которую вы можете использовать при доступе к своим внутренним хостам через bastion’ы.
Что такое SSH-agent
Агент SSH хранит секретные ключи в безопасности из-за того, что он не делает:
Но если агент может только подписывать сообщения, как SSH шифрует и расшифровывает трафик?
При первом изучении открытых и закрытых ключей SSH естественно предположить, что SSH использует эти пары ключей для шифрования и дешифрования трафика. Именно так я и думал. Но это не тот случай. Пара ключей SSH используется только для аутентификации во время первоначального соединения.
Например, вот как проверяется ключ пользователя во время SSH-соединения, с точки зрения сервера:
Протокол агента
Протокол агента настолько прост, что можно было бы написать базовый SSH-agent за день или два. Он имеет только несколько основных операций:
Команда ssh-add — это ваш шлюз к агенту SSH. Он выполняет все эти операции, кроме подписи. Когда вы запускаете ssh-add без каких-либо параметров, он будет сканировать ваш домашний каталог на наличие некоторых стандартных ключей и добавлять их в ваш агент. По умолчанию он ищет:
Что такое переадресация агента
Функция переадресации агента позволяет вашему локальному агенту SSH связаться через существующее SSH-соединение и прозрачно аутентифицироваться на более удаленном сервере. Например, предположим, что вы входите по SSH в инстанс EC2 и хотите клонировать оттуда приватный репозиторий GitHub. Без переадресации агента вам придется хранить копию вашего приватного ключа GitHub на хосте EC2. При переадресации агента SSH-клиент на EC2 может использовать ключи на вашем локальном компьютере для аутентификации на GitHub.
Как работает переадресация агента
Переадресация агента связана с определенным риском
Когда вы переадресовываете доменный сокет ssh-agent Unix на удаленный хост, это создает угрозу безопасности: любой человек с root доступом на удаленном хосте может незаметно получить доступ к вашему локальному SSH-agent’y через сокет. Они могут использовать ваши ключи, чтобы выдавать себя за вас на других машинах в сети.
Вот пример того, как это может выглядеть:
Как снизить свой риск при переадресации агента
Вот несколько способов сделать переадресацию агента более безопасной:
Или используйте альтернативный агент SSH, который запрашивает вас, когда он используется. Sekey использует Touch ID на macOS для хранения ключей в анклаве безопасности MacBook Pro.
Или вообще не используйте переадресацию агента. Если вы пытаетесь получить доступ к внутренним хостам через bastion, ProxyJump — гораздо более безопасная альтернатива для этого варианта использования. (смотреть ниже)
Используйте ProxyJump : более безопасная альтернатива
Вместо того чтобы перенаправлять agent’a по отдельному каналу, ProxyJump перенаправляет стандартный вход и выход вашего локального SSH-клиента через bastion и далее на удаленный хост. Вот как это работает:
Затем я просто запускаю ssh cloud.computer.internal для подключения к внутреннему назначению через bastion — без переадресации агента.
Если ProxyJump не работает…
Узнайте подробности, как получить востребованную профессию с нуля или Level Up по навыкам и зарплате, пройдя онлайн-курсы SkillFactory: