Die Verbindung zu Windows-Computern hat mich immer deprimiert. Nein, ich bin kein Gegner oder Unterstützer von Microsoft und seinen Produkten. Jedes Produkt existiert für seinen Zweck, aber darum geht es nicht.
Es war für mich immer schmerzhaft, eine Verbindung zu Windows-Servern herzustellen, da diese Verbindungen entweder über einen Ort konfiguriert sind (Hallo WinRM mit HTTPS) oder nicht sehr stabil funktionieren (Hallo RDP zu virtuellen Maschinen in Übersee).
Aus Versehen bin ich aus Versehen auf ein
Win32-OpenSSH- Projekt gestoßen und habe beschlossen, die Konfigurationserfahrung zu teilen. Vielleicht rettet jemand dieses Tool ein paar Nerven.
Installationsoptionen:
- Manuell
- Über Schokoladenpaket
- Über Ansible, z. B. Rolle jborean93.win_openssh
Als nächstes werde ich wie bei den anderen über den ersten Absatz sprechen, und so ist alles mehr oder weniger klar.
Ich stelle fest, dass sich dieses Projekt noch in der Beta befindet, daher wird es nicht für die Verwendung in der Produktion empfohlen.
Laden Sie also die neueste Version herunter, derzeit ist es
7.9.0.0p1-beta . Es gibt Versionen für 32- und 64-Bit-Systeme.
Entpacken Sie in
C: \ Programme \ OpenSSHObligatorischer Moment für korrektes Arbeiten: Nur
SYSTEM und die Administratorgruppe sollten über Schreibberechtigungen in diesem Verzeichnis verfügen.
Installieren Sie Dienste mit dem
Skript install-sshd.ps1 in diesem Verzeichnis
powershell.exe -ExecutionPolicy Bypass -File install-sshd.ps1
Eingehende Verbindungen zu Port 22 zulassen:
New-NetFirewallRule -Name sshd -DisplayName 'OpenSSH Server (sshd)' -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22
Erläuterung: Das Applet New-NetFirewallRule wird unter Windows Server 2012 und höher verwendet. In den ältesten Systemen (oder auf dem Desktop) können Sie den folgenden Befehl verwenden:
netsh advfirewall firewall add rule name=sshd dir=in action=allow protocol=TCP localport=22
Wir starten den Service:
net start sshd
Beim Start werden
Hostschlüssel (falls fehlen) automatisch in
% programdata% \ ssh generiert
Autostart des Dienstes beim Systemstart können wir mit folgendem Befehl aktivieren:
Set-Service sshd -StartupType Automatic
Sie können auch die Standard-Shell ändern (standardmäßig nach der Installation -
cmd ):
New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -PropertyType String -Force
Spezifikation: Es muss ein absoluter Pfad angegeben werden.
Was weiter?
Und dann konfigurieren Sie
sshd_config , das wir in
C: \ ProgramData \ ssh platzieren . Zum Beispiel:
PasswordAuthentication no PubkeyAuthentication yes
Und wir erstellen das Verzeichnis
.ssh im Benutzerordner und darin die Datei
authorized_keys . Wir schreiben dort öffentliche Schlüssel.
Eine wichtige Klarstellung: Nur der Benutzer, in dessen Verzeichnis sich die Datei befindet, muss über Schreibberechtigungen für diese Datei verfügen.
Wenn Sie jedoch Probleme damit haben, können Sie die Rechteprüfung in der Konfiguration jederzeit deaktivieren:
StrictModes no
Übrigens
gibt es in
C: \ Programme \ OpenSSH zwei Skripte (
FixHostFilePermissions.ps1 ,
FixUserFilePermissions.ps1 ), die zum
Korrigieren der Rechte
erforderlich sein sollten
, auch nicht mit
autorisierten Schlüsseln , aber aus irgendeinem Grund werden sie nicht repariert.
Denken Sie daran, den
sshd- Dienst danach 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. All rights reserved. PS C:\Users\Administrator> 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:\Users\Administrator>
Subjektive Vor- / Nachteile.
Vorteile:
- Ein Standardansatz für die Verbindung zu Servern.
Wenn es nur wenige Windows-Computer gibt, ist es sehr unpraktisch, wenn:
Also, hier gehen wir mit ssh und hier rdp,
und im Allgemeinen Best Practice mit Bastionen, zuerst einem SSH-Tunnel und durch ihn RDP. - Einfache Einrichtung
Ich denke das ist offensichtlich. - Geschwindigkeit der Verbindung und Arbeit mit einer entfernten Maschine
Es gibt keine grafische Shell, da sowohl Serverressourcen als auch die Menge der übertragenen Daten gespeichert werden.
Nachteile:
- Ersetzt RDP nicht vollständig.
Leider kann nicht alles von der Konsole aus erledigt werden. Ich meine Situationen, in denen eine GUI erforderlich ist.
Im Artikel verwendete Materialien:
Link zum Projekt selbstInstallationsoptionen werden schamlos aus
Ansible-Dokumenten kopiert.