Une nouveauté qui contribuera à améliorer l'interopérabilité entre Windows et Linux, en permettant de se connecter à un serveur Linux depuis Windows et inversement, et qui pourrait simplifier l'usage de certains outils de gestion de configuration comme Ansible.

Mais pour le moment, cela reste toutefois une implémentation en bêta et Microsoft déconseille de l'utiliser sur un environnement de production critique.

Installation du client et/ou du serveur SSH

Ce support de SSH est fourni en tant que fonctionnalité facultative. Il faut donc passer par une rapide installation pour pouvoir en bénéficier.

Avant toute chose, vérifiez bien que vous possédez la dernière version de Windows 10 en date (1709 minimum), et que toutes les mises à jour disponibles sont installées.

Ensuite, rendez-vous dans les Paramètres Windows via le bouton « roue dentée » du menu Démarrer ou le raccourci clavier Win+I, puis cliquez sur Applications. A l'écran suivant, cliquez ensuite sur Gérer les fonctionnalités facultatives, puis sur le bouton Ajouter une fonctionnalité.

Dans la liste des fonctionnalités optionnelles disponibles, cliquez sur OpenSSH Client puis sur Installer. Si vous souhaitez également pouvoir vous connecter à distance par SSH à votre poste, vous pouvez installer le serveur SSH en sélectionnant OpenSSH Server.

Patientez quelques instants le temps de l'installation puis redémarrez le poste.

Utilisation du client SSH

La commande SSH est disponible immédiatement après redémarrage !

Après redémarrage, vous pouvez ouvrir une invite de commandes et utiliser tout simplement la commande SSH comme vous le feriez sur Linux !

Notez que les commandes suivantes sont également disponibles :

• scp
• sftp
• ssh-add
• ssh-agent
• ssh-keygen

Vous pouvez donc effectuer des transferts de fichiers avec scp ou sftp, ou générer des clés SSH avec ssh-keygen.

Tous ces outils sont installés dans le dossier C:\Windows\System32\OpenSSH, qui a automatiquement été ajouté à la variable d'environnement PATH pour pouvoir les utiliser sans avoir à indiquer le chemin complet. Vous n'avez donc rien de plus à faire pour la partie cliente !

Configuration du serveur

Même si le serveur OpenSSH fonctionne comme un service Windows standard, que vous pourrez retrouver dans la console des Services sous le nom sshd, sa mise en place est en revanche un peu plus délicate…

En effet, même après redémarrage, le service sshd ne sera pas en fonctionnement et si vous tenter de le démarrer juste après l'installation, vous obtiendrez sans doute ce message d'erreur :

Windows n'a pas pu démarrer le service sshd sur Ordinateur local.
Erreur 1067: Le processus s'est arrêté inopinément.

Le serveur SSH requiert quelques actions complémentaires pour pouvoir démarrer...

Pour comprendre ce qu'il se passe, vous pouvez alors consulter le contenu du fichier C:\Windows\System32\OpenSSH\Logs\sshd.log. Vous y trouverez très certainement une ligne indiquant que le serveur n'a pas réussi à trouver le fichier correspondant à la clé de l'hôte.

5272 11:06:28:910 error: Could not load host key: ./ssh_host_rsa_key
5272 11:06:28:910 error: Could not load host key: ./ssh_host_dsa_key
5272 11:06:28:910 error: Could not load host key: ./ssh_host_ed25519_key
5272 11:06:28:910 sshd: no hostkeys available -- exiting.

Avant de pouvoir démarrer le serveur, il faut en effet générer manuellement la clé de l'hôte qui servira à chiffrer la communication entre le serveur et le client. Pour cela, ouvrez une invite de commande en tant qu'Administrateur et tapez les commandes suivantes :

cd C:\Windows\System32\OpenSSH
ssh-keygen.exe -A

Cela va générer une paire de clés nommées ssh_host_ed25519_key (clé privé) et ssh_host_ed25519_key.pub (clé publique) dans le dossier C:\Windows\System32\OpenSSH.

Une fois ces commandes exécutées, vous pouvez fermer l'invite de commande. Toutefois ce n'est toujours pas suffisant pour que le serveur SSH démarre. Si vous essayer tout de même, vous retomberez sur le même message que précédemment.

Il reste en effet une dernière étape à réaliser : modifier les permissions sur les fichiers générés précédemment. En effet, le compte NT Service\sshd utilisé pour le fonctionnement du service SSH n'a pas accès à ces fichiers. Pour corriger cela, ouvrez les propriétés du fichier ssh_host_ed25519_key et, dans l'onglet Sécurité, effectuez les opérations suivantes :

• Changer le propriétaire du fichier pour NT Service\sshd.
• Donnez seulement la permission de lecture au compte NT Service\sshd.
• Retirer toutes les autres permissions y compris pour les éventuels autres utilisateurs.

Une fois cela fait, vous devriez obtenir les permissions suivantes pour le fichier ssh_host_ed25519_key:

Les permissions doivent correspondre exactement à cette image !

Si les permissions ne sont pas définies correctement, le service refusera de démarrer et un message WARNING: UNPROTECTED PRIVATE KEY FILE sera écrit dans le fichier journal.

Une fois que tout est correct, vous pouvez relancer le serveur SSH en démarrant le service sshd. Cette fois, tout devrait bien se passer.

Le serveur SSH est enfin en marche !

Il vous reste encore à définir un mot de passe pour votre compte utilisateur si toutefois vous n'en aviez pas, ainsi qu'à ouvrir le port 22 sur le pare-feu Windows du serveur. Vous pouvez pour cela utiliser la commande suivante :

netsh advfirewall firewall add rule name="Service SSH" dir=in action=allow protocol=TCP localport=22

A partir de là vous pouvez vous connecter en SSH à votre serveur depuis un poste distant. Vous obtiendrez une invite de commande complète depuis laquelle vous pourrez lancer toutes les commandes habituellement disponibles en local, y compris Powershell.

Connexion SSH à un serveur Windows depuis un client Xubuntu.

Vous pourrez également vous connecter à distance au système de fichiers via SFTP en utilisant un client comme WinSCP, ce qui vous permettra de parcourir l'arborescence du serveur et de transférer des fichiers d'une machine à une autre.

Connexion au système de fichiers d'un serveur Windows par SFTP.

A savoir, cette première implémentation souffre encore de quelques limitations. En particulier, elle ne supporte que les clés de type ED25519, ce qui peut causer des soucis de compatibilité avec certains clients et serveurs plus anciens qui ne gèrent pas encore ce type de clés. Aussi, je pense que l'installation de la partie serveur gagnerai à être mieux automatisée pour plus de simplicité. Mais cela reste une bêta et gageons que cela s'améliore rapidement lors de prochaines mises à jour...

Vous pensiez avoir mis votre navigation Web bien à l'abri des regards indiscrets grâce à votre proxy SOCKS réalisé par exemple via un tunnel SSH ? Détrompez-vous ! En réalité, par défaut, seule une partie de vos communications Web sont protégées par cette méthode. L'essentiel des informations nécessaires pour connaitre les sites Web que vous avez visités passent toujours en clair.

C'est le cas notamment des requêtes DNS, qui ne passent pas par le proxy avec la configuration par défaut de Firefox. Le genre de détail qui tue... En effet, à chaque fois que vous visitez un site, un message indiquant son nom est envoyé en clair ! Il suffit d'intercepter ces messages pour avoir un historique assez détaillé de votre navigation.

Heureusement, il est plutôt simple d'y remédier. Sur Firefox, ouvrez une nouvelle fenêtre ou un nouvel onglet et tapez about:config dans la barre d’adresse, comme ci-dessous, puis validez en tapant sur la touche Entrée.

Vous arrivez alors sur un message d’avertissement vous signalant qu’il peut être dangereux d’apporter des modifications.

Prenez note de cet avertissement, puis cliquez sur « Je ferai attention, promis ! ». Dans la nouvelle page qui s’affiche, recherchez la clé network.proxy.socks_remote_dns en utilisant le champ prévu à cet effet.

Par défaut cette clé a pour valeur false (désactivé). Pour masquer vos requêtes DNS, faites passer la valeur à true (activé) en double-cliquant sur la ligne ou en cliquant dessus avec le bouton droit de la souris puis sur Inverser. Si la clé n'existe pas, vous pouvez la créer en faisant un clic droit sur une zone blanche de la fenêtre, puis en cliquant sur Nouvelle / Valeur Booléenne.

Vous pouvez ensuite fermer la fenêtre ou l'onglet, les modifications sont immédiatement prises en compte.

Attention, si vous utilisez simultanément Google Chrome, le même problème existe également et il faut lancer le navigateur en précisant le paramètre --proxy-server pour le corriger. Idem pour Internet Explorer, où il n'existe en revanche pas de solution à ma connaissance.

Vos requêtes DNS sont maintenant protégées, mais sachez toutefois que d'autres contenus peuvent continuer à être transmis en clair, notamment les contenus Flash comme les vidéos ou les jeux, et vous ne pourrez pas être sûr à 100% que vous êtes totalement intraçable. Si vous souhaitez vraiment vous assurer autant que possible de masquer toutes les communications de votre PC, alors il est préférable de se tourner vers d'autres solutions, comme le VPN ou le réseau Tor.

En fait, le plus souvent, il ne s'agit pas d'un problème au niveau du serveur SSH, ni même du réseau de votre fournisseur d'accès Internet. Dans la plupart des cas, la connexion inactive est interrompue par les routeurs NAT (comme votre box Internet par exemple).

En effet, SSH utilise une connexion TCP, et les routeurs NAT conservent une table des connexions TCP actives, et suppriment de cette table les connexions inactives depuis trop longtemps pour faire un peu de ménage, ce qui provoque la déconnexion.

Pour contourner ce problème, il faut faire en sorte que des données (quelques octets suffisent) transitent de manière régulière sur la connexion, même lorsque vous ne tapez rien au clavier ou qu'il ne doit rien être affiché. Les routeurs NAT percevront ainsi la connexion comme étant active, et la conserveront dans leurs tables. La bonne nouvelle, c'est que cette solution est très simple à mettre en place, que ce soit sur Windows avec PuTTY ou sur Linux avec le client SSH de base.

Sur Windows (PuTTY)

Avec PuTTY, dans les propriétés de la session, rendez-vous dans la catégorie Connection, pour définir l'option Seconds between keepalives à une valeur différente de zéro, mais inférieure au délai en secondes au bout duquel vous avez constaté que la connexion inactive était coupée.

L'option bien discrète qui vous épargne une crise de nerf...

Cliquez ensuite sur Open pour ouvrir la connexion ou retournez à l'écran principal pour enregistrer ces paramètres dans votre session.

Sur Linux

Sur Linux, il y a plusieurs possibilités selon ce que vous souhaitez faire précisément. Si vous êtes administrateur de la machine cliente (root) et que vous souhaitez corriger ce problème pour tous les utilisateurs, il faut éditer le fichier /etc/ssh/ssh_config. Si vous préférez appliquer les réglages que pour vous, éditez le fichier ~/.ssh/config (créez-le s'il n'existe pas). Dans les deux cas, voici ce qu'il faut mettre :

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 2

L'option ServerAliveInterval 60 signifie que des données seront envoyées toutes les 60 secondes pour demander au serveur de confirmer que la connexion est toujours ouverte, et permet au passage de garder une connexion active au niveau des routeurs NAT.

L'option ServerAliveCountMax 2 indique au client SSH de considérer la connexion comme fermée si l'on ne reçoit pas de réponse après deux demandes de confirmation. Mais ici, ce n'est pas ce qui nous intéresse le plus.

Par ailleurs, si vous êtes administrateur du serveur SSH, vous pouvez également mettre la configuration suivante dans le fichier /etc/ssh/sshd_config pour corriger le problème pour tous les clients qui se connectent à ce serveur :

ClientAliveInterval 300
ClientAliveCountMax 2

Le principe reste le même que pour la configuration côté client, seul les noms des paramètres changent. Toutefois n'oubliez pas de redémarrer le service SSH pour que ces changements de configuration soient pris en compte (/etc/init.d/ssh restart par exemple).

Enfin, si vous ne souhaitez pas modifier votre configuration de manière persistante, vous pouvez utiliser une option de la ligne de commande du client SSH :

ssh -o "ServerAliveInterval 60" user@domain