In the last article, I promised to consider the remote connection mechanism with Windows to servers running * nix, and vice versa using PowerShell . Promised usually wait three years, but I managed a little earlier. Well, if you want to manage a heterogeneous infrastructure from the right MacBook, or vice versa - to steer Linux-Surface servers without any putty with Surface Pro, I ask for cat.

Microsoft Loves Linux

Back in 2015, Microsoft solemnly announced the launch of the Microsoft Linux program. This includes both the banal guest support * nix-like OS on Hyper-V, and the built-in Windows 10 Ubuntu and the ability to run Microsoft products in Docker, such as SQL Server .

The company also published the source code for PowerShell, which made it possible to launch "Power Shell" not only on Windows. From the account of the same name on Github , in addition to the source code, there are also binaries for most modern systems (MIT license).

This allows you to set up remote control using a single tool - PowerShell. In addition to connecting to the console of the computer, you can run separate commands, including on several servers simultaneously. It is quite convenient for automating administrative tasks, such as a massive change of settings, inventory, collection of logs.

It is sometimes convenient to combine traditional console commands with PowerShell inserts:

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

To connect to Windows machines using PowerShell, the WS-Man protocol is used. For GNU \ Linux, SSH is familiar. Since today both protocols are becoming universal, we will analyze them in more detail.

PowerShell 6.0 for Windows and * nix is ​​still in beta. Therefore, I do not recommend using the described below on combat servers without good testing.

Magomed does not go to the mountain

When the remote access technology using PowerShell only gained momentum, the only universal way to connect to different systems was the WS-Man protocol. For the test bench, I took Windows Server 2016 and Centos 7, for which I will configure the ability to remotely connect and execute commands using this protocol.

First, install fresh PowerShell on Centos:

 curl https://packages.microsoft.com/config/rhel/7/prod.repo > /etc/yum.repos.d/microsoft.repo yum install -y powershell pwsh 

After installation, it became possible to run familiar Windows-based cmdlets. For example, let's look at the PS version and get a list of running processes with the $ PSVersionTable and Get-Process cmdlets:

We work in the PowerShell console on CentOS.

To connect to a Linux machine from the Windows console, we need to install and configure:

• OMI (Open Management Infrastructure) - an adaptation of WMI, which can also be used to manage computers with operating systems other than Windows;
• PSRP (PowerShell Remoting Protocol) is a library required for a remote PowerShell connection.

In detail with the work and the evolution of OMI and PSRP can be found in the excellent material from Matt Wrock , I just install the OMI team:

 yum install omi 

Next, you need to configure ports and authentication in the /etc/opt/omi/conf/omiserver.conf configuration file, and then restart the server with the command:

 /opt/omi/bin/service_control restart 

To simplify the experiment, I will not configure either NTLM authentication or Kerberos. I will also disable encryption - of course, this is not worth doing in a combat environment. To enable text-based authentication and encryption on the Windows side in winrm operation, it is enough to execute the following commands:

 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"} 

After setup, you can test OMI from the Windows console:

 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 

Connect to CentOS from cmd.

Now let's check the work by reverse connection - from Linux to Windows:

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

... and then with CentOS connect to Windows.

After WMI \ OMI is up, you need to install and configure PSRP. Unfortunately and contrary to the instructions , the binary is missing. The library had to be compiled, long and tediously correcting the dependencies that arose:

 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 

Now we can connect from Windows to Linux and vice versa using PowerShell. Let's start with Windows on 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 

From Windows to Linux.

Similarly, a reverse connection can be made.

Invoke-Command can be set on a list of computers, and from a Windows workstation create a user on all Linux servers with a command like this:

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

I must say that the method is not the most convenient and efficient. The minuses are added by the compilation of libraries, various bugs - for example, at the time of writing this article, PSRP did not allow a normal connection from Linux to Windows.

And the developers themselves recommend not to dance around WS-Man, but to turn to the proven method - SSH. Well, let's try it.

The mountain goes to Mahomet

This time, the Windows machine will get a little more specific training - you need to install fresh PowerShell and OpenSSH .

Then you can check the syntax of the New-PSSession cmdlet . If everything happened as it should, then the cmdlet, in addition to the usual ComputerName parameter, will also support HostName.

PowerShell 6.0.0-beta.9 and updated cmdlet syntax.

Installation of OpenSSH is described in a separate instruction .

 powershell -ExecutionPolicy Bypass -File install-sshd.ps1 

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

 ```bash PasswordAuthentication yes ``` 

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

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

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

After installation, you can already enjoy connecting to a Windows server via ssh.

From Windows via Putty to Linux, from Linux back to Windows via SSH.

We will not stop at what has been achieved and move on to setting up Linux. When configuring an SSH server by default, it is enough to register PowerShell in the Subsystem:

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

Now check the connection through the New-PSSession cmdlet and Invoke-Command.

Windows first:

We work from PowerShell with a Linux server.

Now connect from Linux to Windows:

We work from PowerShell with the Windows server.

Unlike WS-Man, SSH is much easier to configure and more stable. Yes, and the password-free connection by keys is more familiar to configure.

The farm is useful

With an unambiguous “consumer advice” everything is again complicated: SSH is easier to configure and more stable, but WS-Man uses the API and allows you to use tools like JEA . I wouldn't definitely use WS-Man on combat servers, but I liked the implementation of OpenSSH on Windows for both the server and the client. For self-made automation, it is quite suitable even without PowerShell.

In any case, the boundaries between Linux and Windows, though slowly, are beginning to fade, which certainly pleases.