Конфигурация сервера OpenSSH для Windows 10 версии 1809 и Windows Server 2019 OpenSSH Server Configuration for Windows 10 1809 and Server 2019

В этой статье описывается настройка сервера OpenSSH (sshd) для ОС Windows. This topic covers the Windows-specific configuration for OpenSSH Server (sshd).

Для OpenSSH предоставляется подробная документация по параметрам конфигурации на веб-сайте OpenSSH.com, и мы не намерены дублировать ее в этом пакете документации. OpenSSH maintains detailed documentation for configuration options online at OpenSSH.com, which is not duplicated in this documentation set.

Настройка стандартной оболочки OpenSSH для Windows Configuring the default shell for OpenSSH in Windows

Стандартная оболочка командной строки предоставляет пользователю интерфейс, который он увидит при подключении к серверу по протоколу SSH. The default command shell provides the experience a user sees when connecting to the server using SSH. По умолчанию в среде Windows изначально используется командная оболочка Windows (cmd.exe). The initial default Windows is the Windows Command shell (cmd.exe). Кроме того, Windows включает PowerShell и Bash, и вы можете настроить в качестве оболочки по умолчанию для сервера любую из оболочек командной строки сторонних производителей, которые предоставляются для Windows. Windows also includes PowerShell and Bash, and third party command shells are also available for Windows and may be configured as the default shell for a server.

Чтобы задать командную оболочку по умолчанию, для начала убедитесь, что папка установки OpenSSH находится в системном пути. To set the default command shell, first confirm that the OpenSSH installation folder is on the system path. В среде Windows по умолчанию она устанавливается в папку SystemDrive:WindowsDirectory\System32\openssh. For Windows, the default installation folder is SystemDrive:WindowsDirectory\System32\openssh. Следующие команды позволяют узнать текущее значение пути (переменную среды path) и добавить к нему стандартную папку установки OpenSSH. The following commands shows the current path setting, and add the default OpenSSH installation folder to it.

Командная оболочка Command shell	Используемая команда Command to use
Команда Command	путь path
PowerShell PowerShell	$env:path $env:path

Настройка оболочки SSH по умолчанию выполняется в реестре Windows, где вам нужно добавить полный путь к исполняемому файлу оболочки в строковое значение DefaultShell в разделе Computer\HKEY_LOCAL_MACHINE\SOFTWARE\OpenSSH. Configuring the default ssh shell is done in the Windows registry by adding the full path to the shell executable to Computer\HKEY_LOCAL_MACHINE\SOFTWARE\OpenSSH in the string value DefaultShell.

Например, следующая команда PowerShell устанавливает PowerShell.exe в качестве оболочки по умолчанию: As an example, the following Powershell command sets the default shell to be PowerShell.exe:

Конфигурация Windows в файле sshd_config Windows Configurations in sshd_config

В среде Windows программа sshd по умолчанию считывает данные конфигурации из файла %programdata%\ssh\sshd_config, но вы можете указать другой файл конфигурации, запустив команду sshd.exe с параметром -f. In Windows, sshd reads configuration data from %programdata%\ssh\sshd_config by default, or a different configuration file may be specified by launching sshd.exe with the -f parameter. Если указанный файл отсутствует, sshd создаст новый файл с конфигурацией по умолчанию при запуске службы. If the file is absent, sshd generates one with the default configuration when the service is started.

Ниже перечислены элементы конфигурации специально для среды Windows, которые можно указать в sshd_config. The elements listed below provide Windows-specific configuration possible through entries in sshd_config. Существуют и другие параметры конфигурации, которые здесь не перечислены, так как они подробно описаны в документации по OpenSSH для Win32 в Интернете. There are other configuration settings possible in that are not listed here, as they are covered in detail in the online Win32 OpenSSH documentation.

AllowGroups, AllowUsers, DenyGroups, DenyUsers AllowGroups, AllowUsers, DenyGroups, DenyUsers

Управление тем, какие пользователи и группы могут подключаться к серверу, осуществляется с помощью директив AllowGroups, AllowUsers, DenyGroups и DenyUsers. Controlling which users and groups can connect to the server is done using the AllowGroups, AllowUsers, DenyGroups and DenyUsers directives. Директивы разрешения и запрета обрабатываются в следующем порядке: DenyUsers, AllowUsers, DenyGroups и наконец AllowGroups. The allow/deny directives are processed in the following order: DenyUsers, AllowUsers, DenyGroups, and finally AllowGroups. Все имена учетных записей должны быть указаны в нижнем регистре. All account names must be specified in lower case. Дополнительные сведения о шаблонах с подстановочными знаками вы найдете в разделе PATTERNS непосредственно в файле ssh_config. See PATTERNS in ssh_config for more information on patterns for wildcards.

При настройке правил для пользователей и (или) групп в домене используйте следующий формат: user?domain* . When configuring user/group based rules with a domain user or group, use the following format: user?domain* . Windows поддерживает несколько форматов для указания субъектов домена, но многие из них конфликтуют со стандартными шаблонами в Linux. Windows allows multiple of formats for specifying domain principals, but many conflict with standard Linux patterns. По этой причине добавлен символ *, чтобы поддерживать полные доменные имена. For that reason, * is added to cover FQDNs. Кроме того, этот подход использует «?» вместо «@», чтобы избежать конфликтов с форматом username@host. Also, this approach uses «?», instead of @, to avoid conflicts with the username@host format.

Пользователи и группы, входящие в рабочие группы, а также подключенные к Интернету учетные записи всегда разрешаются в имена локальных учетных записей (без сегмента домена, примерно как стандартные имена в UNIX). Work group users/groups and internet-connected accounts are always resolved to their local account name (no domain part, similar to standard Unix names). Пользователи и группы домена строго разрешаются в формат NameSamCompatible, то есть «короткое_имя_домена\имя_пользователя». Domain users and groups are strictly resolved to NameSamCompatible format — domain_short_name\user_name. Все правила конфигурации для пользователей и групп должны соответствовать этому формату. All user/group based configuration rules need to adhere to this format.

Примеры для пользователей и групп домена Examples for domain users and groups

Примеры для локальных пользователей и групп Examples for local users and groups

AuthenticationMethods AuthenticationMethods

Для OpenSSH в Windows поддерживаются только методы проверки подлинности «password» и «publickey». For Windows OpenSSH, the only available authentication methods are «password» and «publickey».

AuthorizedKeysFile AuthorizedKeysFile

По умолчанию используется значение .ssh/authorized_keys .ssh/authorized_keys2. The default is «.ssh/authorized_keys .ssh/authorized_keys2». Если путь не является абсолютным, он вычисляется относительно основного каталога пользователя (или пути к образу профиля). If the path is not absolute, it is taken relative to user’s home directory (or profile image path). Например: Ex. c:\users\user. c:\users\user. Обратите внимание, что если пользователь входит в группу администраторов, используется %programdata%/ssh/administrators_authorized_keys. Note that if the user belongs to the administrator group, %programdata%/ssh/administrators_authorized_keys is used instead.

ChrootDirectory (добавлена поддержка в версии 7.7.0.0) ChrootDirectory (Support added in v7.7.0.0)

Эта директива поддерживается только для сеансов SFTP. This directive is only supported with sftp sessions. Удаленный сеанс подключения к cmd.exe не учитывает ее. A remote session into cmd.exe wouldn’t honor this. Чтобы настроить сервер chroot только для SFTP, укажите параметр ForceCommand со значением internal-sftp. To setup a sftp-only chroot server, set ForceCommand to internal-sftp. Вы также можете настроить SCP с поддержкой chroot, реализовав пользовательскую оболочку, которая допускает только SCP и SFTP. You may also set up scp with chroot, by implementing a custom shell that would only allow scp and sftp.

HostKey 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. The defaults are %programdata%/ssh/ssh_host_ecdsa_key, %programdata%/ssh/ssh_host_ed25519_key, %programdata%/ssh/ssh_host_dsa_key, and %programdata%/ssh/ssh_host_rsa_key. Если эти файлы отсутствуют, sshd автоматически создает их при запуске службы. If the defaults are not present, sshd automatically generates these on a service start.

Сопоставление Match

Обратите внимание на правила шаблона в этом разделе. Note that pattern rules in this section. Имена пользователей и групп должны быть в нижнем регистре. User and group names should be in lower case.

PermitRootLogin PermitRootLogin

Неприменимо в ОС Windows. Not applicable in Windows. Чтобы предотвратить вход администратора, примените для группы Administrators директиву DenyGroups. To prevent administrator login, use Administrators with DenyGroups directive.

SyslogFacility SyslogFacility

Если вам требуется ведение журнала в файле, используйте LOCAL0. If you need file based logging, use LOCAL0. Журналы создаются в папке %programdata%\ssh\logs. Logs are generated under %programdata%\ssh\logs. Любое другое значение, включая используемое по умолчанию AUTH, направляет журналы в ETW. For any other value, including the default value, AUTH directs logging to ETW. Дополнительные сведения см. в статье о возможностях по ведению журнала в Windows. For more info, see Logging Facilities in Windows.

Не поддерживается Not supported

Следующие параметры конфигурации недоступны в версии OpenSSH, которая поставляется в составе Windows Server 2019 и Windows 10 версии 1809: The following configuration options are not available in the OpenSSH version that ships in Windows Server 2019 and Windows 10 1809:

• AcceptEnv AcceptEnv
• AllowStreamLocalForwarding AllowStreamLocalForwarding
• AuthorizedKeysCommand AuthorizedKeysCommand
• AuthorizedKeysCommandUser AuthorizedKeysCommandUser
• AuthorizedPrincipalsCommand AuthorizedPrincipalsCommand
• AuthorizedPrincipalsCommandUser AuthorizedPrincipalsCommandUser
• сжатие; Compression
• ExposeAuthInfo ExposeAuthInfo
• GSSAPIAuthentication GSSAPIAuthentication
• GSSAPICleanupCredentials GSSAPICleanupCredentials
• GSSAPIStrictAcceptorCheck GSSAPIStrictAcceptorCheck
• HostbasedAcceptedKeyTypes HostbasedAcceptedKeyTypes
• HostbasedAuthentication HostbasedAuthentication
• HostbasedUsesNameFromPacketOnly HostbasedUsesNameFromPacketOnly
• IgnoreRhosts IgnoreRhosts
• IgnoreUserKnownHosts IgnoreUserKnownHosts
• KbdInteractiveAuthentication KbdInteractiveAuthentication
• KerberosAuthentication KerberosAuthentication
• KerberosGetAFSToken KerberosGetAFSToken
• KerberosOrLocalPasswd KerberosOrLocalPasswd
• KerberosTicketCleanup KerberosTicketCleanup
• PermitTunnel PermitTunnel
• PermitUserEnvironment PermitUserEnvironment
• PermitUserRC PermitUserRC
• PidFile PidFile
• PrintLastLog PrintLastLog
• RDomain RDomain
• StreamLocalBindMask StreamLocalBindMask
• StreamLocalBindUnlink StreamLocalBindUnlink
• StrictModes StrictModes
• X11DisplayOffset X11DisplayOffset
• X11Forwarding X11Forwarding
• X11UseLocalhost X11UseLocalhost
• XAuthLocation XAuthLocation

—>

Настройка доступа по ssh в windows

Чтобы удобно пользоваться ssh и git на windows можно использовать pageant , с его помощью будут иметь доступ putty , git bash , winscp и phpstorm .

Для этого нужно проделать следующее

Скачать putty.zip тут и распаковать весь архив куда-нибудь в укромное местечко (например: d:\Dropbox\Программы\#Portable\Putty\ ).

Добавляем в переменную окружения PATH путь до папки Putty .

Если у вас ещё нет ключа, создаём его с помощью PUTTYGEN.EXE . И закидываем публичный ключ на нужные сервера в файл

/.ssh/authorized_keys и на github.

Закидываем ссылку на PAGEANT.EXE в автозагрузку.

Добавляем в pageant ключ[и].

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

Скачиваем и устанавливаем git bash отсюда.

Добавляем переменную окружения GIT_SSH с указанием пути до PLINK.EXE .

Открываем git bash , заходим в какой-нибудь репозиторий, где у вас работает ssh авторизация через ключ, и проверям, что git pull работает.

WinSCP настраивать не нужно, он подхватит pageant сам.

Что делать, если не работает

/.ssh на сервере должны быть права 700, а у файла

/.ssh/authorized_keys права 600, иначе может не пустить.

Убрать из папки пользователя windows c:\Users\Anton\.ssh\ всё кроме файла known_hosts , чтобы все ключи подгружались из одного места — pageant .

Выполнить в git bash команду plink -ssh -P 22 git@github.com (подставьте нужный логин@хост). Сделать это нужно для того, чтобы pageant запомнил, что это этого хоста должна использоваться авторизация с помощью ключа. Ещё, иногда это нужно, если при выполнении коннекта, например, командой git pull , git bash не принимает (игнорирует, как будто ничего не было введено) вводимый в консоли ответ y при запросе требующем подтверждения типа (yes/no).

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

CIFS over SSH штатными средствами Windows 10

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

Однажды потребовалось мне организовать доступ к серверу по протоколу SMB и в поиске решения я наткнулся на следующую статью: Mounting your Nikhef home directory using SSH for Windows 8. Это было простое и удобное решение, которое использовало Putty. Чуть позже мне пришлось настраивать это решение на другом компьютере и я понял, что Putty тут лишний с тех пор как в Windows 10 появился встроенный ssh-клиент на основе OpenSSH.

Под катом — идентичная схема, только с использованием OpenSSH под Windows 10.

У меня схема организована следующим образом:

1. На сервере запущена Samba, от имени пользователя www-data расшарена корневая папка с сайтами. Доступ к серверу только через ssh с авторизацией по ключу. Сервер за NATом, порт проброшен только для ssh.
2. В процессе входа в аккаунт на домашней машине на Windows 10 через встроенный в систему OpenSSH устанавливается соединение с сервером с авторизацией по ключу.
3. Туннелируется порт 445 удаленной машины на локальный порт 44445 сетевого loopback-адаптера доступного по адресу 10.255.255.1
4. На loopback-адаптере 10.255.255.1 порт 44445 проксируется на локальный 445. Таким образом при подключении к \\10.255.255.1\ открывается удаленная шара с файлами (которая, при необходимости монтируется как сетевой диск).

Всё это автоматом – лень торжествует. Безопасно, быстро и нативно выглядит. Любым редактором могу открывать и править файлы на удаленном сервере как у себя на локальном — без проблем с загрузкой правленых файлов и установкой им необходимых разрешений. При этом нет проблем с безопасностью Samba.

Итак – сперва по шагам:

На стороне WINDOWS

Должен быть установлены OpenSSH. В Windows 10 и Windows Server 2019 появился встроенный SSH клиент на основе OpenSSH. Им мы и воспользуемся. Сначала убедимся что он установлен – наберем в командной строке

Если видим исполнение команды — все «Ок», клиент присутствует в системе.

Шаг 1. Настройка сетевого адаптера

Устанавливаем loopback-адаптер в системе. Мы будем обращаться по адресу к локальному адаптеру.

Запустится «Мастер установки оборудования» (Здесь я пользуюсь русской Windows 10 Pro).

«Далее» -> «Установка оборудования, выбранного из списка вручную» -> «Сетевые адаптеры» -> «Microsoft –> Адаптер замыкания на себя Microsoft KM-Test» -> «Далее»

Уверен, что эти шаги можно сделать из командной строки, но не нашел способ установки драйвера без devcon.exe, потому и не стал заморачиваться с автоматизацией этого шага.

Далее уже в CMD (от имени Администратора).

Видим появился второй адаптер. У меня он называется Ethernet 2.

Теперь настроим адрес для этого адаптера

Или из командной строки:

В результате у нас появился адаптер локально доступный по адресу 10.255.255.1

Теперь проблема в том, что нам необходимо получить доступ к общей папке через TCP-порт 445, но при загрузке Windows этот порт захватывается системным драйвером lanmanserver для всех интерфейсов. Отложив запуск драйвера lanmanserver и установив правило portproxy, мы можем обойти это.

Далее в командной строке от имени администратора меняем режим запуска сетевых служб (пробел после «start=» обязателен. ):

и настраиваем для адаптера с адресом 10.255.255.1 проксирование порта 44445 на локальный порт 445

Теперь необходимо перезагрузиться, чтобы схема перехвата порта у службы lanmanserver сработала.

Проверяем что прослушивание порта осуществляется нашим loopback-адаптером, просмотрев открытые в системе порты

значит все в порядке и порт прослушивается на нужном адресе. Если же мы видим «0.0.0.0:445» — значит в нашей схеме что-то не сработало правильно. Проверить правила переадресации портов можно командой

Шаг 2. Ключ и рабочий скрипт

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

Генерируем ключ для ssh-авторизации (назовем его, например: cifsoversshkey)

В результате будет сгенерирована пара открытого и закрытого ключа. Для того, чтобы OpenSSH не выдавал сообщение UNPROTECTED PRIVATE KEY FILE! нужно изменить права на файл ключа. Задачу мы будем запускать для одного пользователя, от имени которого мы собираемся работать в Windows. Можно через GUI, но мне показалось что картинок уже достаточно. В Windows это сделаем следующей командой:

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

Должны быть права только для текущего пользователя, иначе файл ключа не будет принят программой OpenSSH и соединение не будет подниматься!

Создадим в текущей папке пакетный файл cifsoverssh.cmd следующего содержания:

Где:
user@111.111.111.111 – пользователь на стороне linux сервера @ адрес удаленного сервера

Шаг 3. Ярлык или задача в планировщике

Создаем ярлык для следующей команды: powershell -nologo -noninteractive -windowStyle hidden -command «%APPDATA%\CIFSoverSSH\cifsoversshkey.cmd»
Это позволит запускать наш пакетный файл через powershell без открытия окна. Если запускать его через CMD будет открываться черное окно терминала и будет висеть все время, пока соединение будет установлено, а это неудобно и некрасиво.

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

На стороне клиентского компьютера Windows все приготовления были закончены.

Настройка Linux сервера

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

Подключаемся по ssh из командной строки на windows-машине

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

/.ssh/authorized_keys (если файл отсутствует – создадим его).

Теперь необходимо в этот файл вставить содержимое нашего файла публичного ключа, созданного на нашей windows-машине (файл %APPDATA%\CIFSoverSSH\cifsoversshkey.pub). Откроем его в любом редакторе и вставим цепочку ключа с новой строки. Если есть другие ключи, просто вставим его с новой строки.

Устанавливаем Samba (на примере Debian)

Переименовываем старый файл настроек и создаем новый файл

Открываем пустой файл настроек и приводим его к следующему виду:

В последней секции мы настраиваем непосредственно шару. В названии секции указываем имя шары ShareName. Path = путь к файлам, которые мы хотим расшарить. В параметрах force user и force group указываем linux-пользователя, от имени которого будут сохраняться файлы при изменении и создании в шаре. Так как у меня там лежат файлы для веб-сервера – у меня пользователь www-data

Отключаемся и выходим в командную строку Windows

Всё готово. Теперь остается только запустить наш ярлык или выйти из профиля пользователя windows и снова войти (если вы создали задачу в планировщике).

После этого ваша удаленная шара будет доступна по адресу \\10.255.255.1\ShareName — Можно даже монтировать её как сетевой диск.