以前の記事で、 PowerShellを使用して、Windowsから* nixを実行しているサーバーに、またはその逆にリモート接続するメカニズムを検討することを約束しました。 彼らは通常、約束された3年を待ちますが、私は少し早く管理しました。 まあ、もしあなたが忠実なMacBookから異種のインフラストラクチャを管理したい、あるいはその逆の場合-Linux Proを使えばパテなしでLinuxサーバーを操縦することができます-catをお願いします。
マイクロソフトはLinuxが大好き
2015年、マイクロソフトはMicrosoft Linuxプログラムの開始を厳soleに発表しました。 これには、Hyper-V上のゲスト* nixのようなOSの一般的なサポート、Ubuntuに組み込まれたWindows 10、DockerでSQL ServerなどのMicrosoft製品を実行する機能が含まれます 。
また、PowerShellのソースコードも公開しており、WindowsだけでなくPower Shellを実行できます。 ソースコードに加えて、同じ名前のGithubアカウントから、ほとんどの最新システム（MITライセンス）のバイナリも利用できます。
これにより、単一のツール（PowerShell）でリモートコントロールを構成できます。 コンピューターコンソールへの接続に加えて、同時に複数のサーバーを含む個々のコマンドを実行できます。 設定の大量変更、インベントリ、ログ収集などの管理タスクを自動化するのに非常に便利です。
従来のコンソールコマンドとPowerShellの挿入を組み合わせると便利な場合があります。
cat /etc/passwd | ConvertFrom-Csv -Delimiter ':' -Header Name,Passwd,UID,GID,Description,Home,Shell | Sort-Object Name | Format-Table
PowerShellは、WS-Manプロトコルを使用してWindowsマシンに接続します。 GNU \ LinuxはSSHに慣れています。 両方のプロトコルが今日一般的になっているので、我々はそれらをより詳細に分析します。
PowerShell 6.0 for 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コマンドレットを使用して、実行中のプロセスのリストを取得します。
CentOSのPowerShellコンソールで作業しています。
WindowsコンソールからLinuxマシンに接続するには、次をインストールして構成する必要があります。
- OMI（Open Management Infrastructure）-WMIの適応。Windows以外のOSを搭載したコンピューターの管理にも使用できます。
- 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も構成しません。 暗号化もオフにします-もちろん、戦闘環境ではこれは実行する価値がありません。 winrmのWindows側でテキスト認証と暗号化を有効にするには、次のコマンドを実行します。
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"}
構成後、WindowsコンソールからOMIの動作を確認できます。
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
cmdからCentOSに接続します。
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
PowerShellを使用して、WindowsからLinux、またはその逆に接続できるようになりました。 Linux上のWindowsから始めましょう。
$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 ```
SSH経由で接続するときにPowerShellも自動的に起動する場合は、サブシステムパラメーターで、目的のバージョンの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
インストール後、すでにsshを介してWindowsサーバーに接続できます。
C Linux上のPuttyを介したWindows、SSHを介したLinuxからWindowsへの戻り。
達成されたものにとどまらず、Linuxの構成に進みます。 デフォルトのSSHサーバーを設定する場合、サブシステムでPowerShellを作成するだけで十分です。
Subsystem powershell /usr/bin/pwsh -sshs -NoLogo -NoProfile
次に、New-PSSessionコマンドレットとInvoke-Commandを使用して接続をテストしましょう。
Windowsが最初：
LinuxサーバーでPowerShellを使用しています。
LinuxからWindowsに接続します。
PowerShellでWindowsサーバーを使用しています。
WS-Manとは異なり、SSHは設定がはるかに簡単で安定しています。 また、パスワードなしのキー接続を設定する方が一般的です。
農場は便利です
明確な「消費者へのアドバイス」により、すべてが再び複雑になります。SSHはセットアップが簡単で安定しますが、WS-ManはAPIを使用し、 JEAなどのツールを使用できます。 戦闘サーバーでは、WS-Manを明確に使用することはありませんが、サーバーとクライアントの両方にWindowsでOpenSSHを実装するのが好きでした。 自作の自動化には、PowerShellがなくても非常に適しています。
いずれにせよ、LinuxとWindowsの境界は、ゆっくりではありますが、あいまいになり始めています。