- PVSM.RU - https://www.pvsm.ru -
В прошлой статье [1] я обещал рассмотреть механизм удаленного подключения с Windows на серверы под управлением *nix, и наоборот при помощи PowerShell. Обещанного обычно ждут три года, но я успел чуть раньше. Что ж, если хочется с верного макбука управлять гетерогенной инфраструктурой, или наоборот ― с Surface Pro рулить Linux-серверами без всяких putty, ― прошу под кат.
Еще в 2015 году Microsoft торжественно объявила о запуске программы «Microsoft Linux [2]». Сюда вошла как банальная поддержка гостевых *nix-like OS на Hyper-V, так и встроенная в Windows 10 Ubuntu и возможность запуска в Docker продуктов Microsoft, таких как SQL Server [3].
Компания также опубликовала исходный код PowerShell, что позволило запускать «Ракушку Мощи» не только на Windows. Из-под одноименного аккаунта на Github [4], помимо исходного кода, выложены и бинарники под большинство современных систем (лицензия 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. Для GNULinux привычен 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 и PSRP можно ознакомиться в отличном материале от Matt Wrock [5], я же просто установлю 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.
После того, как WMIOMI заработал, нужно установить и настроить PSRP. К сожалению и вопреки инструкции [6], бинарник отсутствует. Библиотеку пришлось компилировать, долго и нудно исправляя возникающие ошибки зависимостей:
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 [7] и OpenSSH [8].
После можно проверить синтаксис командлета New-PSSession. Если все произошло как надо, то командлет, помимо привычного параметра ComputerName, будет поддерживать и HostName.
PowerShell 6.0.0-beta.9 и обновленный синтаксис командлета.
Установка OpenSSH описана в отдельной инструкции [9].
Качаем последний релиз [10] или используем пакет из репозитория Chocolatey [11]. Все это разархивируем в Program FilesOpenSSH.
В консоли с правами администратора переходим в папку с разархивированным содержимым и запускаем установку командой:
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 FilesOpenSSH"
Остается только настроить и запустить службы:
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 [12]. На боевых серверах использовать WS-Man я бы не стал однозначно, а вот реализация OpenSSH в Windows как сервера, так и клиента мне понравилась. Для самопальной автоматизации вполне подойдет даже без PowerShell.
В любом случае, границы между Linux и Windows хоть и медленно, но начинают стираться, что безусловно радует.
Автор: Tri-Edge
Источник [13]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/ssh/269275
Ссылки в тексте:
[1] В прошлой статье: https://habrahabr.ru/company/pc-administrator/blog/342428/
[2] Microsoft Linux: https://blogs.technet.microsoft.com/windowsserver/2015/05/06/microsoft-loves-linux/
[3] SQL Server: https://hub.docker.com/r/microsoft/mssql-server-linux/
[4] одноименного аккаунта на Github: https://github.com/PowerShell/PowerShell
[5] в отличном материале от Matt Wrock: http://www.hnwatcher.com/r/3632577/A-look-under-the-hood-at-Powershell-Remoting-through-a-cross-plaform-lens
[6] вопреки инструкции: https://github.com/PowerShell/psl-omi-provider
[7] PowerShell: https://github.com/PowerShell/PowerShell/releases
[8] OpenSSH: https://github.com/PowerShell/Win32-OpenSSH
[9] описана в отдельной инструкции: https://github.com/PowerShell/Win32-OpenSSH/wiki/Install-Win32-OpenSSH
[10] Качаем последний релиз: https://github.com/PowerShell/Win32-OpenSSH/releases/latest/
[11] пакет из репозитория Chocolatey: https://chocolatey.org/packages/openssh
[12] JEA: https://habrahabr.ru/company/pc-administrator/blog/335568/
[13] Источник: https://habrahabr.ru/post/343264/
Нажмите здесь для печати.