ProHoster > Blog > administracja > Łączenie się z Windowsem poprzez SSH jak Linux

Łączenie się z Windowsem poprzez SSH jak Linux

Zawsze frustrowało mnie łączenie się z komputerami z systemem Windows. Nie, nie jestem przeciwnikiem ani zwolennikiem Microsoftu i jego produktów. Każdy produkt istnieje w swoim celu, ale nie o to tutaj chodzi.
Łączenie się z serwerami Windows zawsze było dla mnie niezwykle bolesne, ponieważ te połączenia są albo konfigurowane w jednym miejscu (witaj WinRM z HTTPS), albo nie działają bardzo stabilnie (witaj RDP dla maszyn wirtualnych za granicą).

Dlatego przypadkowo natknąłem się na projekt Win32-OpenSSH, postanowiłem podzielić się wrażeniami z konfiguracji. Być może to narzędzie zaoszczędzi komuś wiele nerwów.

Łączenie się z Windowsem poprzez SSH jak Linux

Opcje instalacji:

  1. ręcznie
  2. Przez pakiet Czekoladowy
  3. Przez Ansible, na przykład role jborean93.win_openssh

Następnie opowiem o pierwszym punkcie, ponieważ z resztą wszystko jest mniej więcej jasne.

Pragnę zauważyć, że projekt ten jest wciąż w fazie beta, dlatego nie zaleca się wykorzystywania go w produkcji.

Więc pobierz najnowszą wersję, w tej chwili jest 7.9.0.0p1-beta. Istnieją wersje dla systemów 32- i 64-bitowych.

Rozpakuj w C: Pliki programówOpenSSH
Obowiązkowy punkt prawidłowego działania: tylko SYSTEM i grupa administratorów.

Instalowanie usług za pomocą skryptu zainstaluj-sshd.ps1 znajdujący się w tym katalogu

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

Zezwalaj na połączenia przychodzące na porcie 22:

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

Wyjaśnienie: aplet Nowa reguła NetFirewall używany w systemie Windows Server 2012 i nowszych wersjach. W najstarszych systemach (lub desktopach) możesz użyć polecenia:

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

Uruchommy usługę:

net start sshd

Podczas uruchamiania klucze hosta zostaną automatycznie wygenerowane (jeśli ich brakuje). %programdata%ssh

Możemy włączyć autostart usługi przy starcie systemu komendą:

Set-Service sshd -StartupType Automatic

Możesz także zmienić domyślną powłokę poleceń (po instalacji domyślną jest cmd):

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

Wyjaśnienie: Musisz określić ścieżkę bezwzględną.

Co dalej?

A potem to ustaliliśmy sshd_config, w którym będziemy umieszczać C: Dane programu. Na przykład:

PasswordAuthentication no
PubkeyAuthentication yes

I utwórz katalog w folderze użytkownika .ssh, a w nim plik autoryzowane_klucze. Zapisujemy tam klucze publiczne.

Ważne wyjaśnienie: tylko użytkownik, w którym katalogu znajduje się plik, powinien mieć prawo zapisu do tego pliku.

Ale jeśli masz z tym problemy, zawsze możesz wyłączyć sprawdzanie uprawnień w konfiguracji:

StrictModes no

Swoją drogą, w C: Pliki programówOpenSSH są 2 skrypty (Napraw HostFilePermissions.ps1, Napraw plikUserFilePermissions.ps1), które powinny, ale nie są zobowiązane do ustalania praw, w tym m.in autoryzowane_klucze, ale z jakiegoś powodu się nie rejestrują.

Nie zapomnij ponownie uruchomić usługi sshd po zastosowaniu zmian.

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>

Subiektywne zalety/wady.

Plusy:

  • Standardowe podejście do łączenia się z serwerami.
    Gdy jest niewiele komputerów z systemem Windows, bardzo niewygodne jest, gdy:
    Więc tutaj używamy ssh, a tutaj używamy rdp,
    i ogólnie najlepszą praktyką w przypadku bastionów jest najpierw tunel SSH, a przez niego RDP.
  • Łatwy w konfiguracji
    Myślę, że to oczywiste.
  • Szybkość połączenia i praca ze zdalną maszyną
    Nie ma powłoki graficznej oszczędzającej zarówno zasoby serwera, jak i ilość przesyłanych danych.

Wady:

  • Nie zastępuje całkowicie protokołu RDP.
    Niestety nie wszystko można zrobić z konsoli. Mam na myśli sytuacje, w których wymagane jest GUI.

Materiały użyte w artykule:
Link do samego projektu
Opcje instalacji są bezwstydnie kopiowane Dokumentacja Ansible.

Źródło: www.habr.com

Dodaj komentarz