Vincent

Vincent

This user hasn't shared any profile information

Home page: http://www.fintch.org/

Posts by Vincent

[Mémo] Imposer des paramètres Mozilla Firefox pour un poste en entreprise

0

Pour éviter de chercher à chaque fois, et pour vous faire profiter de l’occasion, voici un petit mémo qui compile et filtre une partie de la littérature (souvent en anglais) à propos de la gestion de configuration des profils Mozilla Firefox, notamment en entreprise.

D’abord le point d’entrée

Ce fichier porte une trace forte héritée du long passé de Firefox et les recommandations pour son nom et son emplacement ont évoluées plusieurs fois. Pour les branches récentes (soit l’ESR actuelle (branche 52) et la précédente (branche 45), ça fonctionne), on utilisera un fichier « C:\Program Files\Mozilla Firefox\defaults\pref\autoconfig.js ». Ce fichier est le déclencheur pour la configuration forcée de Firefox. Bien évidemment, vous devrez adapter le chemin d’accès en fonction de votre contexte, sachant que ce qui est dit ici, et illustré dans un contexte Microsoft, fonctionne parfaitement en environnement Linux (voir les chemins d’accès courants en référence).

Dans ce fichier, on trouvera seulement trois lignes indiquant globalement l’utilisation d’un fichier de configurations forcées.

// Utilisation de configurations forcées
pref("general.config.filename", "mozilla.cfg");
pref("general.config.obscure_value", 0);

Notez que le commentaire en première ligne est obligatoire, quand bien même il serait vide (donc juste deux slashs).

De plus, remarquez l’apparition en clair du nom de fichier que nous allons aborder, ici « mozilla.cfg ». Il pourrait tout aussi bien s’appeler « monentreprise.cfg », le fonctionnement n’en serait pas affecté.

Ensuite le fichier de configuration lui-même

Ici aussi, je préfère ajouter une ligne de commentaire au début. Dans ce cas, c’est plutôt recommandé suite à un vieux bug (antérieur à la version 22). C’est normalement corrigé depuis bien longtemps mais on l’a gardé plus par habitude (commentez vos codes !) que par nécessité. Moi-même j’ai cédé et je l’ai gardé dans mes cas d’usage.

Le fichier en question, que nous appellerons « mozilla.cfg » pour être en phase avec le fichier précédent, se place directement dans « C:\Program Files\Mozilla Firefox\ ».

Il contient, outre le commentaire de la première ligne, et les éventuels commentaires à différents endroits de ce fichier, les configurations à effectuer.

Généralement, on appelle les trois fonctions suivantes :

  • lockPref : pour forcer une configuration (et verrouiller l’élément qui permet de la modifier dans l’interface utilisateur)
  • pref : pour écraser une configuration à chaque démarrage du navigateur
  • defaultPref : pour configurer certains paramètres lors de la création d’un profil (soit la plupart du temps à la première ouverture de Firefox)

En voici un exemple appliqué, lequel interdit l’exécution de la mise à jour automatique. Je ne recommande pas l’application de ces éléments si vous n’avez pas une politique fiable chargée du suivi de version et de la mise à jour par d’autres moyen.

// Fichier de configurations forcées
lockPref("app.update.auto", false);
lockPref("app.update.enabled", false);
lockPref("app.update.mode", 0);
lockPref("app.update.service.enabled", false);
lockPref("browser.search.update", false);

Mais on peut avoir des choses plus compliquées. Vous trouverez une référence pour aller plus loin, puisqu’après tout, c’est bien un fichier JavaScript, mais pour le coup, ça devient hors-sujet.

Et sinon

Il existe aussi un autre moyen de forcer des configurations en utilisant un fichier « user.js » dans le profil de l’utilisateur. Cela permet d’écraser les valeurs contenues dans « prefs.js » par celles de « user.js ». Cependant, un utilisateur averti saura se rendre dans son profil Firefox et modifier ou supprimer le fichier « user.js ».

Au moins, ce moyen a été cité !

Sachez qu’il existe un outil appelé CCK2 qui peut vous faciliter grandement la tâche. Mais comme je reste un adepte de la méthode manuelle (et donc formatrice), c’est celle-ci que j’ai décrite dans cet article.

L’avenir

Sachez qu’avec la version 60 ESR, Mozilla fournira un véritable outil de configuration. Difficile de dire avec précision s’il sera bien ou pas, ni comment il évoluera. Cependant l’initiative était vivement attendue depuis longtemps afin de cesser le bidouillage à base de fichiers comme indiqué ici. Affaire à suivre.

Références

[Astuce] Accès distant avec OpenVPN

0

En voulant configurer un serveur d’accès distant avec OpenVPN, je suis tombé dans quelques petits pièges. Aussi, pour que mon expérience puisse servir à d’autres, autant vous en faire part.

Contexte

C’est très simple, presque bateau : un serveur, avec OpenVPN, des clients, avec OpenVPN également et quelques petites subtilités côté serveur. Les clients se connectent au serveur et accèdent à des ressources locales au serveur mais aussi à l’infrastructure qui se trouve derrière. Imaginez que l’infrastructure est importante et que le serveur serve de bordure à un protocole de routage dynamique.

Première astuce : les types de tunnels

D’abord, j’ai fait l’erreur de laisser les clients se connecter via un VPN TAP. Bien que ça fonctionne, ce n’est pas vraiment adapté en pratique. Sommairement, les tunnels de type TAP sont principalement conçus pour des connexions de site à site, et les tunnels de type TUN servent aux accès distant pour un terminal (ordinateur, téléphone, tablette…). Bref, on repasse en TUN pour le cas qui m’intéresse, c’est-à-dire de l’accès en itinérance de terminaux.

Deuxième astuce : la topologie des tunnels de type TUN

Les interfaces de type TUN fonctionnent au niveau 3 du modèle OSI, mais en fait c’est un montage un peu complexe quand on y regarde de très près mais qui fonctionne très bien. Sauf bien évidemment quand on utilise déjà des astuces de routage ou de pare-feu, ce qui était le cas sur mon serveur.

Regardons justement plus en détail. Sur une extrémité de tunnel TAP, on trouve une interface réseau virtuelle, possédant son adresse IP et son masque, et un pair en face. On est donc pas bien loin du tunnel GRE si on enlève le chiffrement qui va autour, dans le principe bien sûr.

Pour une extrémité TUN, il faut tenir compte de la notion de topologie. Par défaut, un serveur TUN démarre avec une topologie dite « net30 », soit assignation d’un sous-réseau /30 (2 IP possibles, le serveur et le client). Et pour que le client communique avec le serveur (au sens applicatif, par exemple un serveur Web abrité derrière la connexion VPN), il faut que le noyau puisse recevoir les paquets, et il n’y a qu’une seule interface virtuelle qui est montée. Dans ce cas, on va tomber sur une interface TUN déclarée dans le noyau avec une adresse IP /32, une route injectée « manuellement » par OpenVPN pour tout le sous-réseau, et un routage strictement interne à OpenVPN entre les clients. Obscur hein ! Décryptons avec un dessin.

Ce schéma représente le principe de fonctionnement d’une topologie Net30. Le serveur réel (le noyau du système d’exploitation) voit une unique adresse IP en 192.168.90.1/32, tout le reste étant masqué par le processus OpenVPN. Chaque client voit sa propre adresse IP dans un sous-réseau dédié par OpenVPN. Par exemple le client ayant l’adresse 192.168.90.6/30 discutera avec le serveur via l’adresse 192.168.90.5/30 et ne pourra pas communiquer avec le reste du monde, sauf à lui « pousser » des routes.

Il faut bien comprendre qui va tenir le rôle de routeur : est-ce le serveur OpenVPN ou est-ce le noyau de l’OS ? La réponse dépend de la configuration : avec l’option « client-to-client », c’est OpenVPN qui s’occupera du routage, sinon c’est le noyau.

Avec un Net30 et une plage réduite dans la configuration d’OpenVPN, disons 192.168.90.0/29, on peut avoir un serveur et un client (et un seul), et instancier autant de processus OpenVPN que nécessaire, et donc autant d’interfaces dans le noyau. Ca peut éventuellement servir pour appliquer des règles de pare-feu très fines entre clients ou différentes d’un client à l’autre.

Mais c’est peut-être un peu beaucoup… Et c’est pas tout à fait ça que je cherchais. Tout simplement parce que l’interface déclarée en tant que 192.168.90.1/32 crée du souci à mon protocole de routage, même avec la route « manuelle » évoquée plus haut qui serait ici 192.168.90.0/24. Dans mon cas, le protocole choisit le masque le plus restreint plutôt que la route statique, même en lui forçant la main.

Et c’est là qu’entre en jeu le paramètre « topology ». Moyennant de lui indiquer le mode « subnet », on retombe sur le même principe de fonctionnement que les interfaces TAP, et le noyau verra de nouveau l’interface virtuelle en tant que 192.168.90.1/24. Et voilà que mon routage s’est remis d’aplomb presque instantanément !

Troisième astuce : tout ça pour le client OpenVPN sur Android

Le client OpenVPN pour Android ne supporte pas les tunnels TAP ! C’est de là que tout est parti. Quand, lorsque j’ai bêtement converti mon serveur de TAP vers TUN, j’ai vu surgir tous ces problèmes de topologie mais aussi de routes et de DNS !

Parce que malgré un « ip route » sur un teminal Android (7.1.2), impossible de voir les routes poussées par le serveur dans le noyau Linux de l’Android. Même en root. Alors qu’elles sont bien présentes et bien inscrites par OpenVPN. Bref, que faut-il alors faire pour que ça fonctionne ?

Sur le serveur, il faut pousser les routes et éventuellement si c’est nécessaire (comme dans mon cas) les serveurs DNS. On placera donc les éléments suivants, que vous aurez bien évidemment pris soin d’adapter à votre cas, dans la configuration côté serveur :

push "route 10.0.0.0 255.0.0.0"
push "dhcp-option DOMAIN labcellar.com"
push "dhcp-option DNS 10.0.0.10"
push "dhcp-option DNS 10.0.0.11"

Je ne veux rediriger que le trafic interne dans le tunnel, c’est pouquoi je ne fais que pousser la route adaptée. Vous trouverez sur Internet pléthore de sites vous expliquant comment rediriger l’intégralité du trafic dans le tunnel. Ici, c’est l’accès aux outils internes qui m’intéresse, et la résolution des noms. Côté client Android, il faut bien penser à laisser l’option « pull » activée afin que soient pris en compte tous ces paramètres « pushés » par le serveur. Et n’oubliez pas dans les versions récentes d’Android d’aller régler les « Applications autorisées », soit en mode « liste blanche » (seulement les applications cochées), soit en mode « liste noire » (interdire les applications cochées).

En fait, au delà de l’astuce de configuration, il faut savoir que le seul moyen d’avoir des informations de débogage consiste à augmenter la « verbosité » du logiciel OpenVPN et à faire confiance au fait qu’il affiche ou non des erreurs à chacune de ses actions. Demander ces informations directement au noyau Android aboutit à n’avoir que des informations erronées ou incomplètes si l’on tente de procéder comme sur un ordinateur classique.

Références

Il y a une petite coquille dans cet article (qui n’est pas liée à la syntaxe ou à la grammaire mais bien sur le sujet de fond), et qui n’a pas d’impact sur toutes les explications données, ni sur la solution mise en œuvre. Je l’ai laissée (presque) exprès. Saurez-vous la retrouver ? J’éditerai cet article dans un mois environ pour indiquer la solution.

Edit du 09/04/2018 : si vous avez bien suivi les explications sur la topologie Net30, vous avez peut-être remarqué qu’il y a une incohérence dans le schéma que j’ai proposé. En effet si le pseudo-serveur qui émule le switch interne qui relie les tunnels entre eux s’attribue d’abord une adresse avant d’en attribuer une à son client, ça signifie que la patte en haut à gauche qui représente la machine physique ne contient pas les bonnes adresses. Côté switch, c’est l’adresse .1 et côté serveur physique, c’est .2. Et c’est effectivement le cas : l’adresse visible avec un « ifconfig » ou un « ip address » est bien une valeur paire, et généralement .2 pour un subnet /24 divisés en morceaux de /30.

[Mémo] Démarrer des instances OpenVPN avec systemd

0

Remarque préliminaire : cet article traite du démarrage d’instances d’OpenVPN sur un système Linux, ici une Debian Stretch, avec systemd. Il ne traite pas de la manière dont on configure une instance OpenVPN (paramètres et clés).

Avec SysV, un démon maître était lancé et chaque instance à démarrer automatiquement se faisait par configuration dans le fichier « /etc/default/openvpn » (du moins sur les Debian-like).

systemd est conçu pour gérer nativement ces problématiques de multi-instances, alors autant en profiter.

Contexte

Supposons que votre ordinateur portable nécessite d’être raccordé à trois infrastructures distantes via VPN, dont une de manière permanente. Imaginez que vous êtes un prestataire qui prend le contrôle à distance chez ses clients, tout en gardant en permanence un lien vers son serveur NAS à la maison,

On a donc 3 configurations différentes que nous appellerons « maison », « client-a » et « client-b ». Ces trois configurations et tous les fichiers nécessaires (notamment les clés) se placent dans leurs dossiers respectifs. Ce qui donne :

$ ls /etc/openvpn
client   client-a   client-b   maison   server

Cela dit, on remarque la présence de deux dossiers supplémentaires appelés « client » et « server ». Ils sont liés au fonctionnement prédéfini par les gabarits d’unités systemd pour OpenVPN 2.4.

Mise en œuvre

Pour chaque dossier créé, on trouve un certain nombre d’éléments, dont le fichier de configuration. Voici un exemple :

$ ls /etc/openvpn/maison
maison.conf   shared.key

Remarque : on pourrait tout bourrer comme des sagoins dans le dossier « client », mais je ne trouve pas ça très propre et très maintenable si les tunnels se multiplient.

Cependant, c’est bien le dossier « client » qui va faire foi dans un premier temps, vu la manière dont le gabarit est construit. Un simple lien symbolique suffit :

# ln -s /etc/openvpn/maison/maison.conf /etc/openvpn/client/maison.conf

Le gabarit n’est pas amorçable directement, il faut nommer explicitement une instance. Ici le fichier s’appelle « maison.conf ». Inscrire l’instance « maison » (qui ira bien chercher « maison.conf » dans le dossier « client ») est enfantin :

# systemctl enable openvpn-client@maison
Created symlink /etc/systemd/system/multi-user.target.wants/openvpn-client@maison.service → /lib/systemd/system/openvpn-server@.service.

Désormais, le VPN vers la maison se lance automatiquement au démarrage du système !

Et pour lancer les autres instances, pas besoin de les inscrire, systemd se débrouille à partir du nom indiqué pour retrouver ses petits.

# systemctl start openvpn-client@client-a

Remarques

Le paquet OpenVPN exploite donc désormais les services systemd, et non plus les scripts de type UNIX System V. Pour bien décortiquer l’affaire, il faut donc comprendre le fonctionnement des « unités » systemd. La petite bête réside dans ce paragraphe (en langue de Shakespeare) :

Optionally, units may be instantiated from a template file at runtime. This allows creation of multiple units from a single configuration file. If systemd looks for a unit configuration file, it will first search for the literal unit name in the file system. If that yields no success and the unit name contains an « @ » character, systemd will look for a unit template that shares the same name but with the instance string (i.e. the part between the « @ » character and the suffix) removed. Example: if a service getty@tty3.service is requested and no file by that name is found, systemd will look for getty@.service and instantiate a service from that configuration file if it is found.

Soit en gros : il détecte la présence d’un arobase, donc il suppose une instanciation. Il extrait le nom de l’instance entre le ‘@’ et le ‘.’, et lance le gabarit (reconnaissable au ‘@.service’) avec en paramètre le nom de l’instance.

Le paquet lui-même installe ces fichiers :

# ls -l /lib/systemd/system/openvpn*
-rw-r--r-- 1 root root 707 juil. 18 22:15 /lib/systemd/system/openvpn-client@.service
-rw-r--r-- 1 root root 780 juil. 18 22:15 /lib/systemd/system/openvpn-server@.service
-rw-r--r-- 1 root root 320 juil. 18 22:15 /lib/systemd/system/openvpn.service
-rw-r--r-- 1 root root 894 juil. 18 22:15 /lib/systemd/system/openvpn@.service

Dans le fichier « openvpn-client@.service », on trouve ces directives (parmi d’autres) :

WorkingDirectory=/etc/openvpn/client
[...]
ExecStart=/usr/sbin/openvpn --suppress-timestamps --nobind --config %i.conf

Et voilà grosso modo comment systemd s’y retrouve pour lancer des instances différentes à partir d’un même fichier. Même principe pour le gabarit « openvpn-server ».

Et les deux derniers ? Ce sont les versions pour OpenVPN 2.3, que je recommande d’abandonner si vous le pouvez. Ces instances cherchent leur configuration dans le dossier « /etc/openvpn » et sont lancées de manière significativement différentes. Si vous n’êtes pas un expert OpenVPN, ou ne recherchant pas explicitement ces détails de lancement, vous pouvez les abandonner sans regret. Sachez qu’un OpenVPN 2.4 peut parfaitement discuter avec un OpenVPN 2.3 moyennant de les laisser s’entendre sur les algorithmes et certains paramètres nouvellement introduits : c’est testé et approuvé !

systemd, faut en manger ! C’est bon ! (Mais des fois ça croque un peu sous la dent…)

[Debian] Basculer la mise en réseau de System V à systemd

1

Depuis Debian Jessie (8.X), systemd se fait de plus en plus présent dans la distribution, et permet d’effectuer une migration en douceur au fil des versions. Parmi celles à noter, je voudrais vous faire découvrir la partie mise en réseau élémentaire.

L’objectif est de remplacer la gestion classique avec l’ensemble ifupdown et le client DHCP de l’ISC. On pourra même supprimer les paquets à la fin de la migration. Pour corser les choses, je vais appliquer ce cas d’usage à un VPS 2016 chez OVH, dont la gestion manuelle révèle quelques surprises.

Testez vos configurations dans une machine virtuelle ! Ça vous évitera des surprises en production. Et lisez cet article en entier avant de vous lancer : systemd est super, mais aussi super chiant parfois…

Configurer systemd

La configuration des éléments réseau de systemd se fait dans le dossier /etc/systemd/network. Pour ce qui nous concerne, on va créer un fichier avec en préfixe un nombre quelconque, par exemple « 30 » puis un nom représentatif pour vous, je prendrai « wired » pour mes liens filaires, et l’extension « .network ». Dans cet exemple, ca me donne donc « 30-wired.network ».

(suite…)

[Windows] Dépendances de mises à jour sur Windows 7 SP1

0

Cet article est en fait un mémo pour rapidement mettre à jour les composants fondamentaux d’un Windows 7 SP1.

Exigences initiales

Mon problème est de bénéficier de la dernière version de PowerShell (5.1 au moment où je rédige cet article, 6.0 en cours de finalisation par Microsoft), de la dernière version du framework .NET (4.7.1), et de la dernière version d’Internet Explorer (11). De plus, ces logiciels doivent s’installer sans connexion à Internet.

Mise à jour d’Internet Explorer

Dans un premier temps, on s’occupera d’Internet Explorer. Windows 7 est livré par défaut avec Internet Explorer 8, lequel est obsolète depuis un bon moment, tant par l’arrivée de nouvelles versions et de fonctionnalités, que par l’arrêt progressif du support par Microsoft. Officiellement, l’éditeur ne le supporte plus depuis le 12 janvier 2016 (mais des correctifs sortent encore aujourd’hui…) Bref, il est grandement temps de le mettre à jour. (suite…)

[Mémo] Chiffrer un disque dur externe sous Linux

1

Afin de ne plus chercher partout « comment je m’y étais pris la dernière fois » pour fabriquer mon disque dur externe chiffré, je me suis fait un petit mémo. L’objectif est donc d’utiliser LUKS, et quelques lignes de commande.

J’avais un disque dur SATA de 500 Go, récupéré dans une de mes anciennes machines, que je voulais transformer en disque de sauvegarde. J’ai donc utilisé un dock USB, puis branché sur une machine Linux.

Toutes les commandes se font en root ou bien préfixées par sudo. Moi je suis plutôt root sur mes machines, surtout quand j’enchaîne les commandes à privilèges (quitte à faire un sudo /bin/bash…) Mais c’est un vieux troll poilu une autre histoire…

Première étape : le repartitionnement

Fdisk est votre ami.

Fdisk vous affiche les partitions d’un disque donné :

# fdisk -l /dev/sdb

Mais fdisk est avant-tout interactif. Voici ce que ça donne :

# fdisk /dev/sdb

Avec o (lettre o minuscule) : je crée une table des partitions vide, donc je vide en une fois toutes les partitions existantes.

Avec n : je crée une partition. En laissant les valeurs par défaut, la partition occupera l’espace maximal disponible. (suite…)

[Windows] Activation des produits Microsoft

0

L’activation est un processus qui certifie que vous utilisez légalement une copie d’un logiciel Microsoft. Elle consiste en un échange de données entre un produit et un serveur de licences. Sommairement, le produit construit un identifiant unique à partir de divers renseignements techniques (produit, version, identifiant unique généré et surtout, la clé de licence), et le serveur retourne une information indiquant le succès ou non de la procédure.

À la maison, l’activation est généralement négociée avec des serveurs Internet de Microsoft. Les principaux produits concernés sont Windows (depuis Windows XP) et Office (depuis Office 2007), cependant le système pourrait tout aussi bien servir à d’autres produits de l’éditeur. Votre licence se présente généralement sous forme d’étiquette sécurisée collé sur votre unité centrale ou au dos de votre portable, voire cachée sous la batterie de certains modèles via des étiquettes au format réduit. Cependant, la dématérialisation vous permet de ne conserver qu’un courriel avec un certificat d’authenticité sur lequel est inscrit votre clé de licence, ce qui est généralement le cas pour Office.

Pour les entreprises ayant une infrastructure Microsoft importante – on prendra comme exemple une cinquantaine de postes et une quinzaine de serveurs – il peut devenir fastidieux pour un administrateur de jongler avec les processus d’activation Microsoft. L’éditeur commence alors à fournir des solutions plus adaptés à la gestion de parc.

(suite…)

[Tutoriel] Installation de Passbolt sur Debian Stretch

3

Introduction

Passbolt est un gestionnaire de mots de passe à vocation collaborative. Il est composé d’un serveur centralisant les mots de passe sous forme chiffrée et d’extensions pour navigateurs Web. Son installation n’est pas tout à fait triviale et nécessite un article dédié. Je vous conseille de lire l’article une fois jusqu’au bout avant de vous lancer dans l’installation du produit.

Cette article n’aurait pas de raison d’être si, d’une part il n’était pas écrit en français alors que la grande majorité de la littérature sur Passbolt est en anglais, et si d’autre part, je n’avais pas eu envie de sortir des sentiers battus par les tutoriels d’installation, outre le fait d’être tombé sur des petits bogues ou des raccourcis documentaires engendrant des problèmes.

Fonctionnalités

Passbolt permet de générer, stocker et partager des mots de passe, le tout sous forme chiffrée. Plus techniquement, il s’appuie sur GnuPG et OpenPGP pour effectuer le chiffrement et le partage des clés.

D’une certaine manière, il n’y a pas de « coffre-fort » dédié par utilisateur. Toutes les clés sont stockées au même endroit. En revanche, n’importe qui ne peut pas lire n’importe quelle clé : il faut qu’il soit inscrit sur chaque clé pour pouvoir la déchiffrer. Soit dit autrement : il existe autant de coffres-fort que de clés. Les utilisateurs admis dans ces coffres possèdent l’un des trois niveaux de privilèges suivant : Peut lire, Peut mettre à jour, Est propriétaire.

Le premier, comme son nom l’indique, ne peut que consulter le mot de passe et ses métadonnées, le second peut modifier le mot de passe stocké, tandis que le propriétaire peut partager ou révoquer le partage du mot de passe.

Enfin, il est possible d’accéder à Passbolt en ligne de commandes, mais ce moyen n’est pas décrit de manière détaillée dans cet article. Globalement, on y trouve des actions d’administration, rien de plus, vous en verrez quelques-unes plus loin.

(suite…)

[Astuces] Connexion automatique en SSH avec PuTTY

0

Lorsque vous gérez un parc important de serveurs, il peut devenir vite fastidieux de retenir tous les identifiants et mots de passe, voire même de les saisir plusieurs fois par jour, des fois même par heure. Dans mon cas, c’est principalement l’administration de machines Linux avec PuTTY qui nécessitait un coup de main.

Objectif : se connecter en quelques clics à un serveur Linux en SSH à l’aide de clés depuis une machine Windows.

Remarque : la configuration du serveur SSH n’est pas dans le périmètre de cet article. Une brève recherche sur n’importe quel moteur du Web vous retournera une surabondance de littérature à ce sujet. On partira donc du principe que votre serveur SSH est configuré et fonctionnel. De même, la gestion de l’authentification par clé publique et les manipulations à effectuer côté serveur ne sont pas détaillées.

Génération d’une paire de clés

La suite logicielle PuTTY propose l’outil PuTTY Key Generator, que vous trouverez en tant que PuTTYgen dans le menu Démarrer. Il est très simple à utiliser.

Génération d’une paire de clés avec PuTTY Key Generator

Au lancement, le logiciel ne contient aucune clé. Un clic sur Generate, comme son nom l’indique, vous permettra de générer une clé. L’aléa de génération est pris à l’aide des mouvements de votre souris dans une zone vide située sous la barre de progression. Vous la verrez avancer à chaque déplacement de votre pointeur.

Dès la génération terminée, des éléments supplémentaires apparaissent, dont les champs de mot de passe permettant de protéger la clé privée. Laissez ces champs vides pour la suite de l’article. (suite…)

Vincent's RSS Feed
Go to Top