Connexion à Windows via SSH comme sous Linux

J'étais toujours déprimé par la connexion aux machines Windows. Non, je ne suis pas un adversaire ou un partisan de Microsoft et de ses produits. Chaque produit existe pour son but, mais ce n'est pas tout.
Il a toujours été douloureusement douloureux pour moi de me connecter aux serveurs Windows, car ces connexions sont configurées via un seul endroit (bonjour WinRM avec HTTPS) ou ne fonctionnent pas de manière très stable (bonjour RDP aux machines virtuelles à l'étranger).

Par conséquent, tombé accidentellement sur un projet Win32-OpenSSH , j'ai décidé de partager l'expérience de configuration. Peut-être que quelqu'un cet outil sauve un tas de nerfs.



Options d'installation:

1. Manuellement
2. Par l'intermédiaire Chocolatey Package
3. Via Ansible, par exemple le rôle jborean93.win_openssh

Ensuite, je vais parler du premier point, comme pour le reste, et donc tout est plus ou moins clair.

Je note que ce projet est toujours en version bêta, il n'est donc pas recommandé pour une utilisation en production.

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

Décompressez dans C: \ Program Files \ OpenSSH
Moment obligatoire pour un travail correct: seuls SYSTEM et le groupe admin doivent avoir des permissions d'écriture dans ce répertoire.

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

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

Autoriser les connexions entrantes au 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 versions ultérieures. Dans les systèmes les plus anciens (ou bureau), vous pouvez utiliser la commande:

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

Nous commençons le service:

 net start sshd 

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

Démarrage automatique du service au démarrage du système, nous pouvons activer avec la commande:

 Set-Service sshd -StartupType Automatic 

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

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

Spécification: un chemin absolu doit être spécifié.

Et ensuite?

Et puis configurez sshd_config , que nous placerons dans C: \ ProgramData \ ssh . Par exemple:

 PasswordAuthentication no PubkeyAuthentication yes 

Et créez le répertoire .ssh dans le dossier utilisateur et dans celui-ci le fichier authorized_keys . Nous y écrivons des clés publiques.

Une précision importante: seul l'utilisateur dans le répertoire dans lequel se trouve le fichier doit avoir des droits d'écriture sur ce fichier.

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

 StrictModes no 

Soit dit en passant, dans C: \ Program Files \ OpenSSH, il y a 2 scripts ( FixHostFilePermissions.ps1 , FixUserFilePermissions.ps1 ), qui devraient mais ne sont pas requis pour fixer les droits, y compris avec les clés autorisées , mais pour une raison quelconque, ils ne seront pas corrigés.

N'oubliez pas de redémarrer le service sshd après avoir appliqué 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 subjectifs.

Avantages:

• Une approche standard pour se connecter aux serveurs.
  Lorsqu'il y a peu de machines Windows, il est très gênant lorsque:
  Alors, on y va par ssh, et ici rdp,
  et généralement les meilleures pratiques avec les bastions, d'abord un tunnel ssh, et à travers lui RDP.
• Configuration facile
  Je pense que c'est évident.
• Vitesse de connexion et de travail avec une machine distante
  Il n'y a pas de shell graphique; les ressources du serveur et la quantité de données transmises sont enregistrées.

Inconvénients:

• Ne remplace pas complètement RDP.
  Hélas, tout ne se fait pas depuis la console. Je veux dire des situations où une interface graphique est requise.

Matériaux utilisés dans l'article:
Lien vers le projet lui-même
Options d'installation copiées sans vergogne à partir de documents Ansible .