Verbindung zu Windows über SSH wie in Linux

Ich war immer enttäuscht über die Verbindung zu Windows-Maschinen. Nein, ich bin kein Gegner oder Befürworter von Microsoft und ihren Produkten. Jedes Produkt hat seinen Zweck, aber darum geht es hier nicht.
Für mich war es immer schmerzhaft, mich mit Windows-Servern zu verbinden, weil diese Verbindungen entweder auf eine chaotische Weise eingerichtet werden (Hallo WinRM mit HTTPS) oder nicht sehr stabil funktionieren (Hallo RDP zu virtuellen Maschinen über den Ozean).

Deshalb bin ich zufällig auf das Projekt Win32-OpenSSHgestoßen, und habe beschlossen, meine Erfahrung mit der Einrichtung zu teilen. Vielleicht erspart diese Tool jemandem viele Nerven.

Installationsoptionen:

1. Manuell
2. Über das Paket Chocolatey
3. Über Ansible, zum Beispiel die Rolle jborean93.win_openssh

Im Folgenden werde ich über den ersten Punkt sprechen, da die anderen ohnehin mehr oder weniger klar sind.

Ich möchte darauf hinweisen, dass sich dieses Projekt derzeit in der Beta-Phase befindet und daher nicht für die Produktion empfohlen wird.

Also, laden wir die neueste Version herunter, derzeit ist das 7.9.0.0p1-beta. Es gibt Versionen für sowohl 32- als auch 64-Bit-Systeme.

Entpacken in C:Program FilesOpenSSH
Ein wichtiger Punkt für die korrekte Funktion: Die Schreibrechte in diesem Verzeichnis müssen nur für SYSTEM und für die Administratorgruppe vorhanden sein.

Installieren Sie die Dienste mit dem Skript install-sshd.ps1 das sich in diesem Verzeichnis befindet

powershell.exe -ExecutionPolicy Bypass -File install-sshd.ps1

Erlauben Sie eingehende Verbindungen zu Port 22:

New-NetFirewallRule -Name sshd -DisplayName 'OpenSSH Server (sshd)' -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22

Hinweis: Das Applet New-NetFirewallRule wird auf Windows Server 2012 und neuer verwendet. In älteren Systemen (oder Desktops) kann der Befehl verwendet werden:

netsh advfirewall firewall add rule name=sshd dir=in action=allow protocol=TCP localport=22

Starten Sie den Dienst:

net start sshd

Beim Start werden automatisch die Host-Schlüssel (falls nicht vorhanden) in %programdata%ssh

Die automatische Start des Dienstes beim Systemstart können wir mit folgendem Befehl aktivieren:

Set-Service sshd -StartupType Automatic

Außerdem können Sie die Standard-Shell (nach der Installation, standardmäßig — cmd):

New-ItemProperty -Path "HKLM:SOFTWAREOpenSSH" -Name DefaultShell -Value "C:WindowsSystem32WindowsPowerShellv1.0powershell.exe" -PropertyType String -Force

Hinweis: Es ist notwendig, den absoluten Pfad anzugeben.

Was folgt jetzt?

Und dann konfigurieren wir sshd_config, die sich in C:ProgramDatassh. Zum Beispiel:

PasswordAuthentication no
PubkeyAuthentication yes

Und erstellen ein Verzeichnis in dem Benutzerordner .ssh, und darin eine Datei authorized_keys. Dort schreiben wir die öffentlichen Schlüssel.

Wichtige Klarstellung: Nur der Benutzer, in dessen Verzeichnis die Datei liegt, sollte das Recht haben, in diese Datei zu schreiben.

Wenn Sie jedoch damit Probleme haben, können Sie die Berechtigungsprüfung im Konfigurationsfile ausschalten:

StrictModes no

Übrigens liegen C:Program FilesOpenSSH 2 Skripte (FixHostFilePermissions.ps1, FixUserFilePermissions.ps1), die möglicherweise, aber nicht müssen, die Berechtigungen fixieren, unter anderem mit authorized_keys, aber aus irgendeinem Grund tun sie es nicht.

Vergessen Sie nicht, den Dienst sshd nachher neu zu starten, um die Änderungen zu übernehmen.

ru-mbp-666:infrastructure$ ssh Administrator@192.168.1.10 -i ~\/ .ssh\/id_rsa
Windows PowerShell
Copyright (C) 2016 Microsoft Corporation. Alle Rechte vorbehalten.

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   : de-DE
CurrentUICulture : de-DE
PrivateData      : Microsoft.PowerShell.ConsoleHost+ConsoleColorProxy
DebuggerEnabled  : True
IsRunspacePushed : False
Runspace         : System.Management.Automation.Runspaces.LocalRunspace

PS C:UsersAdministrator>

Subjektive Vor- und Nachteile.

Vorteile:

• Standardansatz zur Verbindung mit Servern.
  Wenn es einige Windows-Maschinen gibt, ist es sehr unangenehm, wenn:
  Hier gehen wir über ssh, und hier über RDP,
  und allgemein ist das Best-Practice mit Bastionen: zuerst ein SSH-Tunnel und darüber RDP.
• Einfache Konfiguration
  Ich denke, das ist offensichtlich.
• Geschwindigkeit der Verbindung und Arbeit mit der entfernten Maschine
  Keine grafische Oberfläche, was sowohl die Serverressourcen als auch die übertragene Datenmenge spart.

Nachteile:

• Ersetzt RDP nicht vollständig.
  Nicht alles lässt sich aus der Konsole erledigen, leider. Ich meine Situationen, in denen eine GUI erforderlich ist.

Verwendete Materialien in dem Artikel:
Link zum Projekt selbst
Installationsvarianten wurden dreist kopiert von Ansible-Dokumentation.

Quelle: habr.com