Connexion à Windows par SSH comme sous Linux

J'ai toujours été frustré par la connexion aux machines Windows. Non, je ne suis ni un opposant ni un partisan de Microsoft et de leurs produits. Chaque produit existe pour un but précis, mais ce n'est pas le sujet.
Pour moi, il a toujours été douloureux de se connecter aux serveurs Windows, car ces connexions sont soit configurées de manière compliquée (bonjour WinRM avec HTTPS), soit ne fonctionnent pas très bien (salut RDP pour les VM à l'étranger).

Ainsi, en tombant par hasard sur le projet Win32-OpenSSH, j'ai décidé de partager mon expérience de configuration. Peut-être que cet outil fera gagner beaucoup de temps à quelqu'un.

Options d'installation :

1. Manuellement
2. Via via le gestionnaire de packages standard de leur distribution. Sur Arch Linux, Chocolatey
3. Via Ansible, par exemple, le rôle jborean93.win_openssh

Ensuite, je vais parler du premier point, car les autres sont à peu près clairs.

Je note que ce projet est encore en phase beta, donc il n'est pas recommandé de l'utiliser en production.

Alors, téléchargez la dernière version, à ce jour c'est 7.9.0.0p1-beta. Il existe des versions pour les systèmes 32 et 64 bits.

Décompressez dans C:Program FilesOpenSSH
Un point essentiel pour un bon fonctionnement : les droits d'écriture dans ce répertoire doivent être réservés uniquement à SYSTEM et au groupe administrateur.

Installez les services avec le script install-sshd.ps1 qui se trouve dans ce répertoire

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

Autorisez 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

Précision : l'applet New-NetFirewallRule est utilisée sur Windows Server 2012 et plus récent. Sur les systèmes plus anciens (ou de bureau), vous pouvez utiliser la commande :

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

sudo systemctl start lxd

net start sshd

Au démarrage, des clés d'hôte seront automatiquement générées (si elles sont absentes) dans %programdata%ssh

Nous pouvons activer le démarrage automatique du service au démarrage du système avec la commande :

Set-Service sshd -StartupType Automatic

De plus, il est possible de changer le shell par défaut (après l'installation, le shell par défaut est — cmd):

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

Précision : il est nécessaire d'indiquer le chemin absolu.

Et après ?

Et ensuite, nous configurons sshd_config, qui se trouve dans C:ProgramDatassh. Par exemple :

PasswordAuthentication no
PubkeyAuthentication yes

Et nous créons dans le dossier utilisateur le répertoire .ssh, et à l'intérieur, le fichier authorized_keys. Là, nous écrivons les clés publiques.

Précision importante : les droits d'écriture dans ce fichier doivent être réservés uniquement à l'utilisateur dont le dossier contient le fichier.

Mais si vous avez des problèmes avec cela, vous pouvez toujours désactiver la vérification des droits dans la configuration :

StrictModes non

À propos, dans C:Program FilesOpenSSH il y a 2 scripts (FixHostFilePermissions.ps1, FixUserFilePermissions.ps1), qui devraient mais ne sont pas obligés de corriger les droits, y compris ceux de authorized_keys, mais qui, pour une raison inconnue, ne corrigent pas.

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. Tous droits réservés.

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>

Avantages et inconvénients subjectifs.

Avantages :

• Approche standard pour se connecter aux serveurs.
  Quand il y a quelques machines Windows, c'est très inconfortable quand :
  Alors, ici nous utilisons ssh, et là RDP,
  et en général, meilleure pratique avec des bastions, d'abord un tunnel ssh, puis RDP à travers.
• Facilité de configuration
  Je pense que c'est évident.
• Vitesse de connexion et d'utilisation avec une machine distante
  Pas d'interface graphique, économisant ainsi les ressources du serveur et le volume de données transférées.

Inconvénients :

• Ne remplace pas complètement RDP.
  Tout ne peut pas être fait depuis la console, hélas. Je veux dire des situations où une interface graphique est requise.

Matériaux utilisés dans cet article :
Lien vers le projet lui-même
Les options d'installation ont été honteusement copiées depuis la documentation Ansible.

Source : habr.com