Свързване към Windows чрез SSH като Linux

Винаги съм бил разочарован от свързването към машини с Windows. Не, не съм нито противник, нито привърженик на Microsoft и техните продукти. Всеки продукт съществува със собствена цел, но не става въпрос за това.
За мен винаги е било изключително болезнено да се свързвам със сървъри на Windows, защото тези връзки са или конфигурирани от едно място (здравей WinRM с HTTPS) или не работят много стабилно (здравей RDP към виртуални машини в чужбина).

Следователно, случайно попаднали на проекта Win32-OpenSSH, реших да споделя опита си с настройката. Може би този инструмент ще спести на някого много нерви.

Опции за инсталиране:

1. ръчно
2. През пакет шоколадово
3. Чрез Ansible, например роля jborean93.win_openssh

След това ще говоря за първата точка, тъй като с останалото всичко е повече или по-малко ясно.

Бих искал да отбележа, че този проект все още е в бета етап, така че не се препоръчва да го използвате в производството.

Така че, изтеглете най-новата версия, в момента е такава 7.9.0.0p1-бета. Има версии както за 32, така и за 64 битови системи.

Разопаковайте C: Програмни файлове OpenSSH
Задължителна точка за правилна работа: само СИСТЕМА и групата администратори.

Инсталиране на услуги с помощта на скрипт инсталирайте-sshd.ps1 намиращи се в тази директория

powershell.exe -ExecutionPolicy Bypass -File install-sshd.ps1

Разрешаване на входящи връзки на порт 22:

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

Уточнение: аплет New-NetFirewallRule използвани на Windows Server 2012 и по-нови. В най-старите системи (или десктоп) можете да използвате командата:

netsh advfirewall firewall add rule name=sshd dir=in action=allow protocol=TCP localport=22

Да започнем услугата:

net start sshd

При стартиране ключовете на хоста ще бъдат автоматично генерирани (ако липсват) в %програмни данни%ssh

Можем да активираме автоматично стартиране на услугата, когато системата стартира с командата:

Set-Service sshd -StartupType Automatic

Можете също така да промените командната обвивка по подразбиране (след инсталирането, по подразбиране е Cmd):

New-ItemProperty -Path "HKLM:SOFTWAREOpenSSH" -Name DefaultShell -Value "C:WindowsSystem32WindowsPowerShellv1.0powershell.exe" -PropertyType String -Force

Пояснение: Трябва да посочите абсолютен път.

Каква е следващата?

И тогава го настроихме sshd_config, който ще поставим в C: Програмни данни, Например:

PasswordAuthentication no
PubkeyAuthentication yes

И създайте директория в потребителската папка .ssh, а в него файла авторизирани_ключове. Там записваме публични ключове.

Важно уточнение: само потребителят, в чиято директория се намира файлът, трябва да има право да пише в този файл.

Но ако имате проблеми с това, винаги можете да изключите проверката на правата в конфигурацията:

StrictModes no

Между другото, в C: Програмни файлове OpenSSH има 2 скрипта (FixHostFilePermissions.ps1, FixUserFilePermissions.ps1), които трябва, но не са длъжни да определят права, включително с авторизирани_ключове, но по някаква причина не се регистрират.

Не забравяйте да рестартирате услугата SSHD след като приложите промените.

ru-mbp-666:infrastructure$ ssh [email protected] -i ~/.ssh/id_rsa
Windows PowerShell
Copyright (C) 2016 Microsoft Corporation. All rights reserved.

PS C:UsersAdministrator> Get-Host


Name             : ConsoleHost
Version          : 5.1.14393.2791
InstanceId       : 653210bd-6f58-445e-80a0-66f66666f6f6
UI               : System.Management.Automation.Internal.Host.InternalHostUserInterface
CurrentCulture   : en-US
CurrentUICulture : en-US
PrivateData      : Microsoft.PowerShell.ConsoleHost+ConsoleColorProxy
DebuggerEnabled  : True
IsRunspacePushed : False
Runspace         : System.Management.Automation.Runspaces.LocalRunspace

PS C:UsersAdministrator>

Субективни плюсове/минуси.

плюсове:

• Стандартен подход за свързване към сървъри.
  Когато има малко Windows машини, е много неудобно, когато:
  И така, тук преминаваме през ssh, а тук използваме rdp,
  и като цяло най-добрата практика с бастиони е първо ssh тунел и RDP през него.
• Лесен за настройка
  Мисля, че това е очевидно.
• Скорост на връзка и работа с отдалечена машина
  Няма графична обвивка, спестявайки както сървърните ресурси, така и количеството предадени данни.

против:

• Не замества изцяло RDP.
  Не всичко може да се направи от конзолата, уви. Имам предвид ситуации, при които се изисква GUI.

Използвани материали в статията:
Линк към самия проект
Опциите за инсталиране са безсрамно копирани от Ansible документи.

Източник: www.habr.com