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

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

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

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

Варианти за инсталиране:

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

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

Искам да отбележа, че този проект все още е в бета версия, затова не се препоръчва да се използва в продукция.

И така, сваляме последната версия, в момента това е 7.9.0.0p1-beta. Има версии както за 32, така и за 64 битови системи.

Разпаковаме в C:Program FilesOpenSSH
Задължителен момент за коректна работа: правата за запис в тази директория трябва да са само за SYSTEM и за администраторската група.

Инсталираме услугите със скрипта install-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

При стартиране ще бъдат автоматично генерирани хост-ключове (ако не присъстват) в %programdata%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:ProgramDatassh. Например:

PasswordAuthentication no
PubkeyAuthentication yes

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

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

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

StrictModes no

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

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

ru-mbp-666:infrastructure$ ssh Administrator@192.168.1.10 -i ~\/ssh\/id_rsa
Windows PowerShell
Copyright (C) 2016 Microsoft Corporation. Всички права запазени.

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 docs.

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

Купете надежден хостинг за сайтове с защита от DDoS, VPS VDS сървъри 🔥 Купете надежден хостинг за сайтове с защита от DDoS, VPS VDS сървъри | ProHoster