Installation de PowerShell V7 et OpenSSH sous Windows Server 2016

Si Microsoft s’ouvre de plus en plus vers le monde GNU/Linux, cet effort se retrouve principalement sur Windows Server 2019. Cependant, il est tout à fait possible d’installer OpenSSH sur Windows Server 2016 et ainsi d’administrer son serveur à distance en utilisant la dernière version de Powershell, ou encore de pouvoir faire du transfert de fichier via SSH comme sur un hôte GNU/Linux.

Bien que Microsoft indique que les binaires OpenSSH ne soient pas suffisamment stables pour un usage en production, je n’ai rencontré aucun dysfonctionnement pénalisant avec dans mon environnement de test et j’ai intégré OpenSSH à ma dernière révision du master. Chaque environnement étant différent, il reste important de tester avant une intégration en production.

Les sources de Powershell V7 se trouvent sur le GitHub de Powershell accessible à ce lien. Les sources d’installation d’OpenSSH pour Windows se trouvent sur ce GitHub.

L’installation de Powershell V7 se fait simplement en exécutant le setup ; cependant, l’implémentation d’OpenSSH sous Windows semble rencontrer des dysfonctionnements lorsqu’elle doit gérer des répertoires avec des espaces. Je vous conseille donc d’installer PS dans un autre répertoire que celui proposé par défaut ; dans cet exemple je l’ai installé directement à la racine du C:\.

L’installation d’OpenSSH se fait également en dézippant l’archive. Pour les mêmes raisons que précédemment, je vous conseille de déployer les binaires dans un répertoire sans espace (et de manière générale, de bannir les espaces des noms de fichiers !).

Vous pouvez désormais ajouter les deux répertoires à la variable système PATH, comme ceci :

L’installation d’OpenSSH se fait en Powershell, avec une élévation en administrateur :

cd C:\OpenSSH-Win64
.\install-sshd.ps1

Ce script va créer deux services que l’on peut retrouver dans la console. Par défaut, les services ne sont pas démarrés (c’est pourquoi je les ai intégrés à mon master, ainsi je peux les activer si il y a besoin, sans cela ils restent « dormants » sans avoir d’impact sur le système). Il faut donc les démarrer, et en fonction du besoin, activer le démarrage automatique.

Ensuite, il convient de générer une clef SSH. Toujours dans le répertoire d’OpenSSH :

ssh-keygen.exe -A

Le fichier de configuration est identique à celui que l’on peut retrouver sur un système GNU/Linux utilisant OpenSSH. Il suffit de copier le fichier sshd_config_default vers un nouveau fichier nommé sshd_config dans le répertoire C:\ProgramData\ssh et d’y appliquer les paramètres désirés et de redémarrer le service pour que les changements soient pris en compte.

Tout est prêt. Il ne reste plus qu’à ouvrir une connexion en SSH pour tester le bon déroulement de l’installation. Une fois la connexion établie avec son login Windows usuel, il suffit d’appeler le moteur Powershell pour faire ce que l’on souhaite :

En utilisant la console, on peut tomber sur quelques bugs d’affichage si jamais la console Putty a été redimensionnée :

En dehors de ces petites imperfections qui montrent que ces binaires n’en sont pas encore à un véritable état de release, la connexion est stable. Je me suis pris au jeu d’effectuer quelques tâches et c’est relativement plaisant de pouvoir effectuer du Powershell à distance via SSH, WinRM étant bloqué dans mon environnement. OpenSSH permet par ailleurs de faire du transfert de fichier via SSH, grâce à WinSCP par exemple :

Quelques techniques de sioux pour sécuriser un hôte Proxmox VE

Maintenant que ma nouvelle installation de Proxmox VE tourne à merveille suite aux déboires que j’ai pu avoir chez mon ancien prestataire, je vais vous dévoiler quelques-unes de mes techniques de sioux pour sécuriser un peu plus un hôte Proxmox, car en configuration par défaut ce n’est pas très excitant. Ces quelques billes ne transformeront pas votre hôte en forteresse inviolable, mais il sera déjà un peu plus blindé ! 😁

Sécuriser SSH

Un petit tour dans /etc/ssh/sshd_config rapidement, et on va procéder au changement de quelques paramètres, tout d’abord le port par défaut sur lequel SSH écoute. Le 22 étant le port par défaut, on va le changer. Naturellement, on évitera de mettre un port qui est déjà utilisé pour une autre application ou qui pourrait être bloqué par un éventuel pare-feu. Ensuite, l’option PermitRootLogin ne doit surtout pas être à yes mais à without-password, prohibit-password ou à no. Les deux premières options peuvent être utilisées avec des clefs SSH, tandis que la dernière bloquera complètement le login en root, forçant un su une fois la connexion avec un utilisateur standard établie.

Rejeter les tentatives de connexion avec une autre IP

Dans /etc/hosts.allow, on va pouvoir définir les adresses IP qui sont autorisées à communiquer avec certains services installés sur la machine. Il peut être judicieux de rejeter les connexions SSH sur toutes les IP sauf une. Par exemple, celle d’un VPN et éventuellement d’une de vos machines virtuelles si vous avez une VM dédiée à l’administration.

Dans cet exemple, je n’autorise qu’une IP à se connecter et je bloque toutes les autres.

sshd : 192.168.1.2 : allow
sshd : all : deny

Autoriser l’accès à l’interface web de Proxmox uniquement sur une adresse ou un range d’IP

Par défaut, l’interface web de Proxmox est accessible sur le port 8006 pour tout le réseau internet. Le moteur web étant basé sur Apache, il est possible d’appliquer des règles allow et deny toutes simples pour n’autoriser l’accès à l’interface web que sur les IP que l’on souhaite. Ici aussi, utiliser un VPN peut s’avérer utile car on déplace derrière une authentification supplémentaire le portail web.

On édite avec nano le fichier /etc/default/pveproxy, puis on saisit les IP qu’on souhaite autoriser ou refuser comme ceci :

ALLOW_FROM= »192.168.1.2,192.168.2.12″
DENY_FROM= »all »

POLICY= »allow »

Un redémarrage de l’interface web est nécessaire :

pveproxy restart

Installer fail2ban

fail2ban est une application tournant en tâche de fond qui écoute les divers logs système et applicatifs et repère les tentatives de brute-force et place en cas d’échecs répétés de connexion les IP dans les règles de rejet du pare-feu ; en conséquence, toutes les IP (ou plage) voient leurs connexions rejetées pendant un certain laps de temps durant la configuration. Celle par défaut suffit normalement pour le peu de services qui sont en théorie installés sur l’hôte.

apt install fail2ban

Le fichier de configuration le plus intéressant est /etc/fail2ban/jail.conf car c’est ici que l’on peut éventuellement ajouter des services à monitorer.

En dehors de ces astuces, je ne saurai que conseiller de créer des utilisateurs avec le minimum de privilège par VM, créer un compte pour l’administration du datastore, et de passer par un VPN pour vous connecter en SSH ou en web. Vous pouvez trouver plus de documentation sur ces liens concernant fail2ban, pveproxy et sshd_config.

Migration des VM d’un hôte Proxmox VE vers un autre hôte sans cluster

Suite à des déboires par rapport à l’hébergeur de mon serveur, j’ai fini par revenir chez OVH chez qui j’ai toujours été satisfait. Sur ce nouveau serveur, j’ai donc rempilé pour la même distribution que l’ancien, un Proxmox VE 5 sur base de Debian 9, pour des raisons de compatibilité principalement, et aussi car j’étais satisfait de cet hyperviseur après quelques années sous ESXi.

Le principal intérêt étant la possibilité de conserver les machines virtuelles et ne rien avoir à réinstaller à part l’hyperviseur lui-même et refaire la configuration (ou plutôt, la redéployer étant donné que j’avais tout sauvegardé), je vais expliquer dans cet article comment procéder à l’export et à l’importation des VM de l’ancien hôte vers le nouveau.

Sur l’interface de Proxmox, sélectionner la machine virtuelle que l’on souhaite sauvegarder, puis aller dans Backup, et enfin, cliquer sur Backup Now. Si le datastore est invisible, il faut activer le stockage de fichiers de sauvegarde dessus (Datacenter > Storage > Edit > Content, cocher VZDump backup file).

La fenêtre de sauvegarde d’une VM. Il faut choisir le datastore sur lequel écrire la sauvegarde, le mode (snapshot, mise en veille de la VM ou arrêt complet) et enfin, spécifier si l’on souhaite une compression de celle-ci et/ou un mail.

Un snapshot n’étant pas suffisant pour restaurer une VM sur un autre hôte sans cluster, il faut donc soit mettre en sommeil la VM le temps de la sauvegarde (option Suspend) ou l’arrêter complètement (option Stop). Dans mon cas, le mode Suspend suffit ; j’ai choisi une compression LZO pour réduire le temps de transfert vers l’autre hyperviseur.

Il se peut que la sauvegarde échoue : le message d’erreur est généralement assez clair, mais s’assurer qu’il ne reste pas un ISO de monté et inaccessible ou que la VM n’est pas en cours d’extinction déjà est un début.

Un écran apparaît alors permettant de suivre le déroulement de la sauvegarde, en fonction de la taille de la machine, de vos performances CPU et disque, il n’y a pas de vrai moyen de déterminer le temps que cela peut prendre. A titre d’exemple, une sauvegarde d’une VM avec un seul disque virtuel contenant environ 65 Go de données s’est terminée en environ 15 minutes (CPU Core i7-4770, 32 Go de RAM, disques SATA 10K).

Une fois la sauvegarde terminée, il va s’agir de la transférer. Le moyen présentant le meilleur ratio simplicité/sécurité est d’utiliser SCP. Dans un shell, nous allons donc nous placer dans le répertoire des dumps, identifier le fichier de sauvegarde, puis lancer le transfert SCP.

cd /var/lib/vz/dump/
ls

La sauvegarde est donc au format .vma.lzo puisque l’on a décidé de compresser en LZO. En cas de doute un ls -l affiche la taille, permettant de différencier le log de la sauvegarde elle-même.

Reste plus qu’à lancer le SCP :

scp vzdump-qemu-machineidtime_stamp.vma.lzo user@destination:/var/lib/vz/dump/vzdump-qemu-machineidtime_stamp.vma.lzo

A noter que machineid et time_stamp sont des variables qui changent naturellement en fonction de l’ID de la VM et de l’heure à laquelle la sauvegarde a commencé ; on utilisera bien sûr le nom récupéré plus haut. scp utilisant SSH, il peut être nécessaire de préciser le port sur lequel écoute SSH sur le serveur de destination (scp -P 2222 par exemple, si le port SSH est 2222). Il faut également que l’utilisateur spécifié soit en mesure d’écrire dans le répertoire de destination. Vous pouvez faire le transfert vers un homedirectory avec un utilisateur tout simple puis ensuite déplacer la sauvegarde vers le répertoire des dumps.

Le temps de transfert dépendant quasi-uniquement de la bande passante entre les deux hôtes, impossible de prédire celui-ci. Une fois le transfert terminé, sur le nouveau Proxmox, il suffit de se rendre sur les propriétés du datastore pour permettre de gérer les sauvegardes si cela n’est pas déjà fait  (éventuellement déjà opéré sur l’hôte d’origine pour faire les sauvegardes) :

En cochant VZDump backup file, on permet au datastore de gérer les fichiers dumps.

Puis, en se rendant dans le datastore lui-même, on aperçoit bien notre backup :

Il ne reste plus qu’à le sélectionner, cliquer sur Restore, indiquer un ID de machine virtuelle libre sur le nouvel hôte et le datastore de stockage. Puis au redémarrage, tout sera comme à l’extinction sur l’ancien hôte 😎

Si l’envie vous prend de réaliser tout en ligne de commande ou que vous ne pouvez pas utiliser l’interface web, je vous renvoie vers la documentation de vzdump et qmrestore.

Configuration d’OpenVPN pour accéder aux autres machines du réseau

Pour des raisons de sécurité, j’applique des filtres IP sur les principaux points d’entrée de mon cloud, avec un serveur ouvert vers l’extérieur qui sert de passerelle vers le réseau interne. Ayant installé OpenVPN pour d’autres usages, je me suis dit qu’il ne serait pas idiot de se servir d’OpenVPN pour accéder au réseau local et donc accéder aux machines de mon réseau cloud sur ma station personnelle, ce qui fait que peu importe mon emplacement, je suis toujours sur une IP acceptée par les différents services et accès de ma plateforme.

Pour ce faire, il suffit tout simplement d’aller dans les propriétés d’un utilisateur OpenVPN, et d’autoriser cet utilisateur à accéder à d’autres sous-réseaux :
Il reste donc à saisir par exemple 172.21.1.0/24 si les machines auxquelles on souhaite accéder sont sur ce sous-réseau.
Une fois la configuration appliquée, un simple ping permet de vérifier les machines du réseau local répondent, et on peut même s’y connecter directement, car étant sur le réseau local, nous ne sommes plus concernés par d’éventuelles règles NAT appliquées sur l’interface physique du serveur.
Ainsi, sur chacun de mes serveurs GNU/Linux, mon fichier /etc/hosts.allow est comme ceci :

sshd : 12.34.56.78 : allow
sshd : 12.34.56.79 : allow
sshd : ALL : deny

La machine est donc accessible uniquement via SSH par le serveur qui fait office de passerelle, soit par le VPN.

Dans le cadre d’un usage du bureau à distance sur une VM Windows, on peut filtrer grâce aux règles de pare-feu et aux étendues :

Je peux donc laisser plus sereinement ma VM Windows ouverte en TSE car elle rejettera systématiquement ce qui ne provient pas de mon réseau local.