===== SSH-сервер на Windows =====

На //Windows//, начиная с серверной редакции //Windows Server 2019// и десктопной версии //Windows 10 1803// - доступен //SSH//-сервер в качестве отдельного //on-demand// компонента.

Установить его можно следующим образом:

   Get-WindowsCapability -Online | Where-Object Name -like ‘OpenSSH.Server*’ | Add-WindowsCapability –Online
Или с использованием //dism//:

   dism /Online /Add-Capability /CapabilityName:OpenSSH.Server~~~~0.0.1.0
Или загрузив вручную отсюда:

https://github.com/PowerShell/Win32-OpenSSH/releases/

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

   Get-WindowsCapability -Online | ? Name -like 'OpenSSH.Ser*'
Если установщик по каким-либо причинам не сделал автозапуск службы, делаем и запускаем сервис. 

   Set-Service -Name sshd -StartupType 'Automatic'
   Start-Service sshd
Для работы SSH-сервера через FW можно создать соответствующее правило командой (установщик, вероятно, уже его создал):

<WRAP prewrap>
<code>
New-NetFirewallRule -Name sshd -DisplayName 'OpenSSH Server (sshd)' -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22
</code>
</WRAP>
:!: ВНИМАНИЕ. По умолчанию SSH-сервер позволит подключиться любому авторизованному пользователю. Чтобы этого избежать потребуется поправить настройки в файле:

   C:\Programdata\ssh\sshd_config
Если задать разрешение для какой-либо группы, то доступ будет сохранен только для неё, дополонительных deny делать не требуется. Следующей директивой можно разрешить доступ только доменным администраторам:

   AllowGroups "ARASAKA\Domain Admins"
:!: ВАЖНО. Добавлять директиву в самом конце файла конфигурации - плохая идея, т.к. она будет интерпретирована как часть секции //match//. Пример работающей секции:
;#;
{{:ms:windows_ssh_server_allow_group.jpg?600|}}
;#;

Разрешения можно установить и на конкретного пользователя, а не только на группу. В этом случае директива будет выглядеть так:

   AllowUsers "ARASAKA\jp"
:!: ВАЖНО. Здесь используется короткое имя домена (//pre-windows 2000//). Его можно посмотреть в свойствах домена в //AD DS//.
=== Замена оболочки CMD ===

По умолчанию при подключении будет работать стандартный командный интерпретатор CMD. Если мы хотим использовать PowerShell, следует заменить оболочку следующей командой:
<WRAP prewrap>
<code>
New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -PropertyType String –Force
</code>
</WRAP>
=== Подключение с ипользованием SecureCRT ===
Если мы постоянно подключаемся к Exchange через, скажем, //SecureCRT// - очень удобно автоматизировать запуск команды при подключении, чтобы не вводить её вручную каждый раз. Пример:

;#;
{{:soft:logon_ssh_windows_ems.jpg?600|}}
;#;

Здесь для запуска командлетов //Exchange// - прописана такая команда:

   Add-PSsnapin Microsoft.Exchange.Management.PowerShell.E2010

:!: ВПРОЧЕМ, такой способ не является полноценным подключением к //EMS//. В этом случае, скорее всего не будут корректно работать командлеты, запуск которых предполагается вне локального сервера. К примеру, если у нас несколько //Exchange// с распределенными базами и почтовый ящик пользователя находится не на том сервере, к которому мы подключились по //SSH// - командлет завершится с ошибкой.

Стандартный //EMS// shell, запускаемый в Windows умеет это разруливать. Корректным полноценным способом подключения к //EMS// по //SSH// из //SecureCRT// - будет запуск скрипта //RemoteExchange.ps// и последующее использование командлета //Connect-ExchangeServer// сразу же после соединения по //SSH//. Таким образом, нам необходимо добавить два send-действия в SecureCRT, которые выглядят так:

   1. . 'C:\\Program Files\\Microsoft\\Exchange Server\\V15\\bin\\RemoteExchange.ps1' 
   2. Connect-ExchangeServer -auto -ClientApplication:ManagementShell
Пример:
;#;
{{:soft:connect_exchange_securecrt_remoteps.jpg|}}
;#;
 
{{tag>Microsoft Windows Firewall SSH PowerShell ActiveDirectory SecureCRT}}