ProHoster > Blog > administration > Connexion à Windows via SSH comme Linux

Connexion à Windows via SSH comme 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 ses produits. Chaque produit existe pour son propre objectif, mais ce n’est pas de cela qu’il s’agit.
Il a toujours été extrêmement pénible pour moi de me connecter aux serveurs Windows, car ces connexions sont soit configurées via un seul endroit (bonjour WinRM avec HTTPS), soit ne fonctionnent pas de manière très stable (bonjour RDP pour les machines virtuelles à l'étranger).

Par conséquent, étant tombé par hasard sur le projet Win32-OpenSSH, j'ai décidé de partager mon expérience d'installation. Peut-être que cet outil épargnera beaucoup de nerfs à quelqu'un.

Connexion à Windows via SSH comme Linux

Possibilités d'installation :

  1. manuellement
  2. À travers paquet Chocolat
  3. Via Ansible, par exemple le rôle jborean93.win_openssh

Ensuite, je parlerai du premier point, puisque tout est plus ou moins clair avec le reste.

Je tiens à souligner que ce projet est encore au stade bêta, il n'est donc pas recommandé de l'utiliser en production.

Alors, téléchargez la dernière version, pour le moment elle est 7.9.0.0p1-bêta. Il existe des versions pour les systèmes 32 et 64 bits.

Déballer C:Fichiers de programmeOpenSSH
Un point obligatoire pour un bon fonctionnement : seul le SYSTÈME et le groupe d'administration.

Installer des services à l'aide d'un script install-sshd.ps1 situé dans ce répertoire

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

Autoriser 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 : applet Nouvelle règle NetFirewall utilisé sur Windows Server 2012 et versions ultérieures. Dans les systèmes (ou ordinateurs de bureau) les plus anciens, vous pouvez utiliser la commande :

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

Commençons le service :

net start sshd

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

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

Set-Service sshd -StartupType Automatic

Vous pouvez également modifier le shell de commande par défaut (après l'installation, la valeur par défaut est cmd):

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

Clarification : Vous devez spécifier un chemin absolu.

Quelle est la prochaine?

Et puis nous l'avons mis en place sshd_config, que nous placerons dans C:Données du programme. Par exemple:

PasswordAuthentication no
PubkeyAuthentication yes

Et créez un répertoire dans le dossier utilisateur .ssh, et dedans le fichier authorised_keys. Nous y notons les clés publiques.

Précision importante : seul l'utilisateur dans le répertoire duquel se trouve le fichier doit avoir le droit d'écrire dans ce fichier.

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

StrictModes no

D'ailleurs, dans C:Fichiers de programmeOpenSSH il y a 2 scripts (FixHostFilePermissions.ps1, FixUserFilePermissions.ps1), qui devraient mais ne sont pas obligés de fixer les droits, y compris avec authorised_keys, mais pour une raison quelconque, ils ne s'inscrivent pas.

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

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>

Avantages/inconvénients subjectifs.

Avantages:

  • Approche standard pour la connexion aux serveurs.
    Lorsqu'il y a peu de machines Windows, c'est très gênant lorsque :
    Donc, ici, nous passons via ssh, et ici nous utilisons rdp,
    et en général, la meilleure pratique avec les bastions est d'abord un tunnel ssh et RDP à travers celui-ci.
  • Facile à mettre en place
    Je pense que c'est évident.
  • Vitesse de connexion et travail avec une machine distante
    Il n'y a pas de shell graphique, économisant à la fois les ressources du serveur et la quantité de données transmises.

Inconvénients:

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

Matériaux utilisés dans l'article :
Lien vers le projet lui-même
Les options d'installation sont copiées sans vergogne depuis Documents ansibles.

Source: habr.com

Ajouter un commentaire