Connectez-vous à Windows via SSH comme sous Linux

La chose la plus déprimante pour moi est de se connecter aux hôtes Windows. Je ne suis pas un adversaire ou un fan de Microsoft et de ses produits. Chaque produit a son propre but. Mais c'est vraiment pénible pour moi de me connecter aux serveurs Windows, à cause de 2 points: c'est difficile à configurer (Hi WinRM avec HTTPS), et c'est vraiment instable (Bonjour RDP aux VMs à travers l'océan).

Heureusement, j'ai trouvé le projet Win32-OpenSSH . J'ai réalisé que je voulais partager mon expérience avec elle. Je crois que cela aidera quelqu'un et sauvera beaucoup de nerfs.



Manières d'installation:

1. Manuellement
2. Via paquet Chocolatey
3. Via Ansible, disons le rôle jborean93.win_openssh

Je vais expliquer la manière manuelle car d'autres sont évidentes.

Je dois noter que ce projet est en phase bêta et il n'est pas recommandé de l'utiliser en production.

Eh bien, téléchargeons la dernière version. Actuellement, c'est 7.9.0.0p1-beta . Il a également des versions 32 et 64 bits.

Décompressez-le ensuite dans C: \ Program Files \ OpenSSH .

Important: Il est nécessaire d'accorder un accès en écriture au groupe SYSTEM et Administre uniquement.

Plus loin, installez les services via le script shell install-sshd.ps1 qui se trouve dans le répertoire OpenSSH

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

Autorisons les connexions entrantes sur le port 22:

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

Remarque: l'applet New-NetFirewallRule est pour Windows Server 2012 et supérieur uniquement. Pour les systèmes d'exploitation plus anciens ou de bureau, vous pouvez utiliser la commande suivante:

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

Démarrez le service:

 net start sshd 

Cela générera automatiquement des clés d'hôte sous % programdata% \ ssh si elles n'existent pas déjà.

Vous pouvez configurer le démarrage automatique du service par la commande:

 Set-Service sshd -StartupType Automatic 

De plus, vous pouvez changer le shell par défaut (c'est cmd par défaut après l'installation):

 New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -PropertyType String -Force 

Remarque: vous devez définir un chemin absolu.

Et ensuite?

Nous pouvons configurer sshd_config , qui se trouve dans C: \ ProgramData \ ssh .
Par exemple:

 PasswordAuthentication no PubkeyAuthentication yes 

Ensuite, nous créons le répertoire .ssh à l'intérieur du répertoire utilisateur ( C: \ Users \ <user_directory> ) et le fichier authorized_keys à l'intérieur. Nous pouvons coller des clés publiques dans ce fichier.
Important: le seul utilisateur dans lequel il se trouve doit avoir des autorisations d'écriture pour ce fichier.
Par ailleurs, si vous ne pouvez pas le réparer, vous pouvez désactiver la vérification des autorisations via la configuration:

 StrictModes no 

De plus, le répertoire C: \ Program Files \ OpenSSH contient 2 scripts ( FixHostFilePermissions.ps1 , FixUserFilePermissions.ps1 ), qui ne devraient pas obligatoirement corriger les autorisations, y compris les autorisations de touches autorisées , mais ce n'est pas le cas.

N'oubliez pas de redémarrer le service sshd pour appliquer les modifications.

 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> 

Avantages / inconvénients personnels.

Avantages:

• Manière standard de se connecter à n'importe quel serveur (Windows / Linux)
  Lorsque vous avez quelques hôtes Windows, ce n'est pas pratique:
  Donc, ici nous allons via ssh, mais ici via RDP,
  et d'une manière générale, c'est la meilleure pratique avec les bastions, d'abord ssh-tunnel, puis RDP via le tunnel. Oh, tue-moi bébé encore une fois.
• Facile à configurer
  Je pense que c'est évident.
• Vitesse de connexion à l'hôte distant
  Sans interface graphique, nous économisons les ressources de l'hôte et la taille des données transmises

Inconvénients:

• Il ne peut pas remplacer RDP dans certains cas.
  Pas tout ce que vous pouvez faire via PowerShell. Je veux dire les cas où l'interface graphique est requise.

Liens:

Projet sur github
Documents ansible