In zwei Wochen wird in Pathologic 2 die Schwierigkeit angepasst werden können.

Ich habe mich immer über die Verbindung zu Windows-Maschinen geärgert. Ich bin weder ein Gegner noch ein Befürworter von Microsoft und ihren Produkten. Jedes Produkt hat seinen Zweck, aber darum geht es hier nicht.
Es war für mich immer extrem frustrierend, mich mit Servern unter Windows zu verbinden, weil diese Verbindungen entweder auf eine umständliche Weise eingerichtet werden (Hallo WinRM mit HTTPS) oder nicht sehr stabil laufen (Hallo RDP zu virtuellen Maschinen über den Ozean).

Deshalb bin ich zufällig auf das Projekt Win32-OpenSSH, gestoßen und möchte meine Erfahrungen bei der Einrichtung teilen. Vielleicht kann jemand mit diesem Tool eine Menge Nerven sparen.

Installationsoptionen:

1. Manuell
2. Über 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 momentan in der Betaphase befindet und daher nicht weiter für den Einsatz in Produktionsumgebungen empfohlen wird.

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

Entpacken Sie es nach C:Program FilesOpenSSH
Ein wichtiger Punkt für die korrekte Funktion: Schreibrechte in diesem Verzeichnis sollten nur für SYSTEM und die Administratorgruppe vorhanden sein.

Installieren Sie die Dienste mit dem Skript install-sshd.ps1 im aktuellen Verzeichnis

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

Erlauben eingehende Verbindungen auf Port 22:

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

Hinweis: Applet New-NetFirewallRule wird auf Windows Server 2012 und neuer verwendet. In älteren Systemen (oder Desktop-Versionen) 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 Host-Schlüssel generiert (sofern nicht vorhanden) in %programdata%ssh

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

Set-Service sshd -StartupType Automatic

Außerdem kann die Standard-Shell nach der Installation geändert werden (standardmäßig — cmd):

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

Hinweis: Der absolute Pfad muss angegeben werden.

Wie geht es weiter?

Jetzt konfigurieren wir sshd_config, das sich befindet in C:ProgramDatasshverwendet. Zum Beispiel:

PasswordAuthentication no
PubkeyAuthentication yes

und erstellen im Benutzerverzeichnis das Verzeichnis .ssh, in dem sich die Datei authorized_keys. Dort schreiben wir die öffentlichen Schlüssel hinein.

Wichtiger Hinweis: Nur der Benutzer, dessen Verzeichnis die Datei enthält, sollte Schreibrechte für diese Datei haben.

Wenn Sie damit Probleme haben, können Sie die Berechtigungsprüfung in der Konfiguration jederzeit deaktivieren:

StrictModes no

Übrigens liegen im C:Program FilesOpenSSH zwei Skripte (FixHostFilePermissions.ps1, FixUserFilePermissions.ps1), die möglicherweise, aber nicht müssen, die Berechtigungen reparieren, auch mit authorized_keys, aber aus irgendeinem Grund reparieren sie 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   : en-US
CurrentUICulture : en-US
PrivateData      : Microsoft.PowerShell.ConsoleHost+ConsoleColorProxy
DebuggerEnabled  : True
IsRunspacePushed : False
Runspace         : System.Management.Automation.Runspaces.LocalRunspace

PS C:UsersAdministrator>

Subjektive Vor- und Nachteile.

Vorteile:

• Der Standardansatz zur Verbindung mit Servern.
  Wenn es einige Windows-Maschinen gibt, ist es sehr unpraktisch, wenn:
  Hier verbinden wir uns über SSH, und hier ist RDP,
  und generell ist das Best-Practice mit Bastionen: zuerst ein SSH-Tunnel und dann darüber RDP.
• Die einfache Konfiguration
  Ich halte das für offensichtlich.
• Die Geschwindigkeit der Verbindung und der Arbeit mit der entfernten Maschine
  Es gibt keine grafische Benutzeroberfläche, was sowohl die Serverressourcen als auch die übertragenen Datenmenge spart.

Nachteile:

• Ersatz für RDP ist nicht vollständig.
  Nicht alles kann leider über die Konsole erledigt werden. Ich spreche von Situationen, in denen eine GUI benötigt wird.

Verwendete Materialien im Artikel:
Link zum Projekt
Installationsoptionen sind dreist kopiert von Ansible-Dokumentation.

Quelle: habr.com