Перекрестное опыление: управляем Linux из-под Windows, и наоборот

  • Tutorial


В прошлой статье я обещал рассмотреть механизм удаленного подключения с Windows на серверы под управлением *nix, и наоборот при помощи PowerShell. Обещанного обычно ждут три года, но я успел чуть раньше. Что ж, если хочется с верного макбука управлять гетерогенной инфраструктурой, или наоборот ― с Surface Pro рулить Linux-серверами без всяких putty, ― прошу под кат.


Microsoft Loves Linux


Еще в 2015 году Microsoft торжественно объявила о запуске программы «Microsoft Linux». Сюда вошла как банальная поддержка гостевых *nix-like OS на Hyper-V, так и встроенная в Windows 10 Ubuntu и возможность запуска в Docker продуктов Microsoft, таких как SQL Server.


Компания также опубликовала исходный код PowerShell, что позволило запускать «Ракушку Мощи» не только на Windows. Из-под одноименного аккаунта на Github, помимо исходного кода, выложены и бинарники под большинство современных систем (лицензия MIT).


Это позволяет настроить удаленное управление с помощью единого инструмента ― PowerShell. Помимо подключения к консоли компьютера, можно запускать отдельные команды, в том числе и на нескольких серверах одновременно. Довольно удобно для автоматизации задач администрирования, таких как массовое изменение настроек, инвентаризация, сбор логов.


Порой удобно совмещать традиционные консольные команды со вставками PowerShell:


cat /etc/passwd | ConvertFrom-Csv -Delimiter ':' -Header Name,Passwd,UID,GID,Description,Home,Shell | Sort-Object Name | Format-Table

Для подключения к Windows-машинам при помощи PowerShell используется протокол WS-Man. Для GNU\Linux привычен SSH. Так как сегодня становятся универсальными оба протокола, разберем их подробнее.


PowerShell 6.0 под Windows и *nix, пока еще находится в бете. Поэтому не рекомендую без хорошего тестирования применять на боевых серверах описанное ниже.


Магомед не идет к горе


Когда технология удаленного доступа при помощи PowerShell только набирала обороты, единственным универсальным способом подключения к разным системам был протокол WS-Man. Для тестового стенда я взял Windows Server 2016 и Centos 7, для которых и буду настраивать возможность удаленного подключения и выполнения команд при помощи этого протокола.


Для начала установим на Centos свежий PowerShell:


curl https://packages.microsoft.com/config/rhel/7/prod.repo > /etc/yum.repos.d/microsoft.repo

yum install -y powershell

pwsh

После установки появилась возможность запускать привычные Windows-администратору командлеты. Например, посмотрим версию PS и получим список запущенных процессов командлетами $PSVersionTable и Get-Process:



Работаем в консоли PowerShell на CentOS.


Чтобы подключаться к Linux-машине с консоли Windows, нам понадобится установить и настроить:


  • OMI (Open Management Infrastructure) ― адаптация WMI, которую также можно использовать для управления компьютерами с ОС, отличными от Windows;
  • PSRP (PowerShell Remoting Protocol) ― библиотека, необходимая для удаленного подключения PowerShell.

Подробно с работой и эволюцией OMI и PSRP можно ознакомиться в отличном материале от Matt Wrock, я же просто установлю OMI командой:


yum install omi

Далее нужно настроить порты и аутентификацию в конфигурационном файле /etc/opt/omi/conf/omiserver.conf, после чего перезапустить сервер командой:


/opt/omi/bin/service_control restart

Для упрощения эксперимента я не буду настраивать ни NTLM-аутентификацию, ни Kerberos. Еще и шифрование отключу ― разумеется, в боевой среде делать этого не стоит. Для включения текстовой аутентификации и шифрования на стороне Windows в работе winrm достаточно выполнить следующие команды:


winrm set winrm/config/client/auth @{Basic="true"}
winrm set winrm/config/client @{AllowUnencrypted="true"}
winrm set winrm/config/service/auth @{Basic="true"}
winrm set winrm/config/service @{AllowUnencrypted="true"}

После настройки можно проверить работу OMI из консоли Windows:


winrm enumerate http://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/OMI_Identify?__cimnamespace=root/omi -r:http://server:5985 -auth:Basic -u:root -p:"password" -skipcncheck -skipcacheck -encoding:utf-8 -unencrypted


Подключаемся к CentOS из cmd.


Теперь проверим работу обратным подключением ― из Linux к Windows:


/opt/omi/bin/omicli ei root/cimv2 Win32_Environment --auth Basic --hostname server -u username -p password --port 5985 


… а затем с CentOS подключаемся к Windows.


После того, как WMI\OMI заработал, нужно установить и настроить PSRP. К сожалению и вопреки инструкции, бинарник отсутствует. Библиотеку пришлось компилировать, долго и нудно исправляя возникающие ошибки зависимостей:


yum groupinstall 'Development Tools'
yum install openssl-devel pam-devel
git clone --recursive [https://github.com/PowerShell/psl-omi-provider.git](https://github.com/PowerShell/psl-omi-provider.git)

cd psl-omi-provider/
make release
rpm -ihv target/Linux_ULINUX_1.0_x64_64_Release/psrp-1.4.1-0.universal.x64.rpm

Теперь мы сможем подключаться с Windows на Linux и наоборот при помощи PowerShell. Начнем с Windows на Linux:


$cred = Get-Credential

#пропустим проверку сертификата для нашей тестовой лаборатории
$o = New-PSSessionOption -SkipCACheck -SkipRevocationCheck -SkipCNCheck

#выполнение команды:
Invoke-Command -ComputerName server -ScriptBlock { Get-Process } -Authentication Basic -SessionOption $o -Credential $cred -UseSSL | Select-Object -First 5

#подключение к консоли
Enter-PSSession -ComputerName 'server' -Credential $cred -Authentication basic -UseSSL -SessionOption $o


С Windows на Linux.


Аналогичным образом можно провести и обратное подключение.


Invoke-Command можно «натравить» на список компьютеров, и с рабочей станции Windows создать пользователя на всех серверах Linux командой вида:


 Invoke-Command -ComputerName server1,server2,server3  -ScriptBlock { adduser admin;echo admin:password | chpasswd
 }

Надо сказать, что способ не самый удобный и эффективный. Минусов добавляет компиляция библиотек, разнообразные баги ― например, на момент написания статьи PSRP не позволял нормально подключиться из Linux в Windows.


Да и сами разработчики рекомендуют не плясать вокруг WS-Man, а обратиться к проверенному способу ― SSH. Что ж, попробуем и его.


Гора идет к Магомету


На этот раз машина с Windows получит чуть больше специфической подготовки ― нужно установить свежий PowerShell и OpenSSH.


После можно проверить синтаксис командлета New-PSSession. Если все произошло как надо, то командлет, помимо привычного параметра ComputerName, будет поддерживать и HostName.



PowerShell 6.0.0-beta.9 и обновленный синтаксис командлета.


Установка OpenSSH описана в отдельной инструкции.


Но под спойлером вы найдете все основные моменты.

Качаем последний релиз или используем пакет из репозитория Chocolatey. Все это разархивируем в \Program Files\OpenSSH.


В консоли с правами администратора переходим в папку с разархивированным содержимым и запускаем установку командой:


powershell -ExecutionPolicy Bypass -File install-sshd.ps1

Теперь генерируем ключи:


.\ssh-keygen.exe -A
.\FixHostFilePermissions.ps1 -Confirm:$false

В тестовой среде мы будем использовать парольную аутентификацию, поэтому стоит убедиться что она включена в файле sshd_config:


```bash
PasswordAuthentication yes
```

Если вы также хотите автоматически запускать PowerShell при подключении по SSH, то в параметре subsystem нужно прописать путь к желаемой версии PS:


Subsystem   powershell C:/Program Files (x86)/PowerShell/6.0.0-beta.9/pwsh.exe -sshs -NoLogo -NoProfile

Для работы клиента SSH нужно добавить директорию в %PATH% любым удобным способом. Например, таким:


setx path "%path%;C:\Program Files\OpenSSH"

Остается только настроить и запустить службы:


Set-Service sshd -StartupType Automatic
Set-Service ssh-agent -StartupType Automatic
net start sshd

После установки уже можно наслаждаться подключением к серверу Windows по ssh.



C Windows через Putty на Linux, с Linux обратно на Windows по SSH.


На достигнутом останавливаться не будем и перейдем к настройке Linux. При настройке сервера SSH по умолчанию достаточно прописать PowerShell в Subsystem:


Subsystem powershell /usr/bin/pwsh -sshs -NoLogo -NoProfile

Теперь проверим подключение через командлет New-PSSession и Invoke-Command.


Сначала Windows:



Работаем из PowerShell с Linux-сервером.


Теперь подключимся из Linux к Windows:



Работаем из PowerShell с Windows-сервером.


В отличие от WS-Man, SSH настраивается намного проще и работает стабильнее. Да и беспарольное подключение по ключам настраивать привычнее.


В хозяйстве пригодится


С однозначным «советом потребителю» все опять сложно: SSH проще в настройке и стабильнее, но WS-Man использует API и позволяет применять инструменты вроде JEA. На боевых серверах использовать WS-Man я бы не стал однозначно, а вот реализация OpenSSH в Windows как сервера, так и клиента мне понравилась. Для самопальной автоматизации вполне подойдет даже без PowerShell.


В любом случае, границы между Linux и Windows хоть и медленно, но начинают стираться, что безусловно радует.

Сервер Молл 192,86
серверы HP, Dell и Lenovo: новые и восстановленные
Поделиться публикацией
Комментарии 16
    0
    Это просто праздник какой-то...)
      0
      Ага, особенно прикольно опробовать что-нибудь типа Invoke-Command для набора машин, некоторые из которых *nix. Если последние тоже в домене, то можно некоторые прикольные штуки опробовать )))
      –3
      Какой ужас. Цеплятся к виндовому powershell и наболюдать как винда выглядит текстом?
      Чем RDP не угодил? Или например www.freesshd.com
      А из винды выполнять команды можно через plink с ключами (который входит в состав putty)
      Еще в винде можно XServer запустить и цепануться к линуху с X11 forward через putty и пускать gui приложения прямо из винды (правда не шибко быстро это пашет).
        0

        RDP для автоматизации не очень удобно использовать. я бы сказал совсем неудобно.
        а на тему freesshd — в статье написано про OpenSSH виндовый, который в отличие от fresshd поддерживается.

          0
          Ха. для автоматизации есть нормальные системы а не windows
            +1

            вы подразумеваете, что windows не поддаётся автоматизации? или что windows не нормальная система?
            или в топку скрипты автоматизации\развертывания, только системы управления конфигурациями, от chef до MS SCCM?
            не холивара ради, если что.

              0
              Я подразумеваю что в винде на это нужно больше усилий.
        0
        SSHу — два десятка лет, Microsoft — один из лидеров IT рынка, но вот что-то у них как-то никак «не получается» ни SSH нормально прикрутит к виндам ни предложить какую-либо альтернативу способную стать интересной UNIX сообществу. А казалось-бы — чего там сложного прикрутить SSH/SCP к виндам? Видимо могут когда не хотят…
          0
          простите, что немного оффтопик, но для меня было новостью, что microsoft умеет таки пакеты выкладывать в репозитории.

          Тогда еще большей остается загадкой, почему свои Linux Integration Services, они раздают через задницу в виде ISO'шника, с адовыми скриптами, и вот это всё.
            +1
            Заглавная картинка просто эпик=)
              –1
              PowerShell классный конечно, но с легаси что делать? А ещё манал я столько печатать в консоли для PowerShell, все пальцы в кровь, код пиши, чтобы сортирнуть логи простынь пиши. В других шелах функционал ничуть не меньше, но писать такие монстроузные команды не надо.
                +1
                После баша объектный пайп — просто счастье. Ничего не надо парсить, экранировать, скрипты не привязаны к форматированию данных, не нужны костыли для обработки спецсимволов в данных (типа кавычек, newline, null). Баш выглядит сплошным куском легаси по сравнению с PS (как, впрочем, и с Python).
                0
                Про удалённое более менее ясно.
                А вот можно ли провернуть из линукса какие нибудь трюки в установленной рядом винде в дуалбуте? Типа редактирования реестра или какого либо редактирования конфигураций?
                  0

                  Доступ к фс винды есть? Значит можно всё что захочется (ну, почти всё).
                  Вспомните многочисленные реаниматоры-лайвсиди на линуксе для винды.
                  Например в качестве редактора реестра подойдёт утилита chntpw

                  0
                  MS старается, скоро SSH (Client\Server) будет в Feature.

                  _https://www.thomasmaurer.ch/2017/11/install-ssh-on-windows-10-as-optional-feature
                    0
                    Это тот же OpenSSH for Windows, хэши бинарников совпадают (хотя я смотрел только ssh.exe). При этом из фич он работает некорректно (например в nano по любому нажатию отключает перенос строк), а тут же установленный OpenSSH for Windows — всё ок.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое