Verbindung zu Windows über SSH wie Linux

Ich war schon immer frustriert, wenn ich eine Verbindung zu Windows-Rechnern herstellen musste. Nein, ich bin weder Gegner noch Befürworter von Microsoft und seinen Produkten. Jedes Produkt existiert für seinen eigenen Zweck, aber darum geht es hier nicht.
Es war für mich immer unerträglich schmerzhaft, eine Verbindung zu Windows-Servern herzustellen, da diese Verbindungen entweder über eine Stelle konfiguriert werden (Hallo WinRM mit HTTPS) oder nicht sehr stabil funktionieren (Hallo RDP zu virtuellen Maschinen im Ausland).

Daher bin ich zufällig auf das Projekt gestoßen Win32-OpenSSH, habe ich beschlossen, meine Setup-Erfahrung zu teilen. Vielleicht erspart dieses Tool jemandem viel Nerven.

Installationsmöglichkeiten:

1. manuell
2. Durch Paket Schoko
3. Über Ansible, zum Beispiel Rolle jborean93.win_openssh

Als nächstes werde ich auf den ersten Punkt eingehen, da im Übrigen alles mehr oder weniger klar ist.

Ich möchte darauf hinweisen, dass sich dieses Projekt noch im Beta-Stadium befindet und daher nicht empfohlen wird, es in der Produktion zu verwenden.

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

Auspacken C:ProgrammeOpenSSH
Ein zwingender Punkt für den korrekten Betrieb: Nur die SYSTEM und die Admin-Gruppe.

Dienste mithilfe eines Skripts installieren install-sshd.ps1 befindet sich in diesem Verzeichnis

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

Eingehende Verbindungen auf Port 22 zulassen:

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

Klarstellung: Applet Neue-NetFirewallRule Wird unter Windows Server 2012 und höher verwendet. In den ältesten Systemen (oder Desktops) können Sie den Befehl verwenden:

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

Starten wir den Dienst:

net start sshd

Beim Start werden Hostschlüssel automatisch generiert (falls fehlen). %programdata%ssh

Wir können den Autostart des Dienstes beim Systemstart mit dem folgenden Befehl aktivieren:

Set-Service sshd -StartupType Automatic

Sie können auch die Standard-Befehlsshell ändern (nach der Installation lautet die Standardeinstellung). cmd):

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

Klarstellung: Sie müssen einen absoluten Pfad angeben.

Was kommt als nächstes?

Und dann haben wir es eingerichtet sshd_config, die wir platzieren werden C:Programmdaten. Zum Beispiel:

PasswordAuthentication no
PubkeyAuthentication yes

Und erstellen Sie ein Verzeichnis im Benutzerordner .ssh, und darin die Datei autorisierte_Tasten. Dort notieren wir die öffentlichen Schlüssel.

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

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

StrictModes no

Übrigens drin C:ProgrammeOpenSSH Es gibt 2 Skripte (FixHostFilePermissions.ps1, FixUserFilePermissions.ps1), die zur Festsetzung von Rechten verpflichtet sein sollten, aber nicht verpflichtet sind, auch mit autorisierte_Tasten, aber aus irgendeinem Grund registrieren sie sich nicht.

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

ru-mbp-666:infrastructure$ ssh [email protected] -i ~/.ssh/id_rsa
Windows PowerShell
Copyright (C) 2016 Microsoft Corporation. All rights reserved.

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-/Nachteile.

Profis:

• Standardansatz für die Verbindung zu Servern.
  Wenn nur wenige Windows-Rechner vorhanden sind, ist es sehr unpraktisch, wenn:
  Also, hier gehen wir über ssh, und hier verwenden wir rdp,
  und im Allgemeinen ist die beste Vorgehensweise bei Bastionen zunächst ein SSH-Tunnel und RDP durch ihn hindurch.
• Einfach einzurichten
  Ich denke, das ist offensichtlich.
• Verbindungsgeschwindigkeit und Arbeit mit einem Remote-Computer
  Es gibt keine grafische Shell, wodurch sowohl Serverressourcen als auch die Menge der übertragenen Daten gespart werden.

Nachteile:

• Ersetzt RDP nicht vollständig.
  Leider kann nicht alles über die Konsole erledigt werden. Ich meine Situationen, in denen eine GUI erforderlich ist.

Im Artikel verwendete Materialien:
Link zum Projekt selbst
Installationsoptionen werden schamlos kopiert Ansible-Dokumente.

Source: habr.com