One place for hosting & domains

      configurer

      Comment installer et configurer Elasticsearch sur Ubuntu 20.04


      Introduction

      Elasticsearch est une plateforme de recherche distribuée et d’analyse de données en temps réel. Il s’agit d’un choix populaire en raison de sa facilité d’utilisation, de ses puissantes fonctionnalités et de son évolutivité.

      Cet article vous guidera pour installer Elasticsearch, le configurer pour votre cas d’utilisation, sécuriser votre installation, et commencer à travailler avec votre serveur Elasticsearch.

      Conditions préalables

      Avant de suivre ce tutoriel, vous aurez besoin de :

      Pour ce tutoriel, nous travaillerons avec la quantité minimale de CPU et de RAM requise pour exécuter Elasticsearch. Notez que la quantité de CPU, de RAM et de stockage dont votre serveur Elasticsearch aura besoin dépend du volume de journaux que vous prévoyez.

      Étape 1 — Installation et configuration d’Elasticsearch

      Les composants Elasticsearch ne sont pas disponibles dans les dépôts de paquets par défaut d’Ubuntu. Ils peuvent cependant être installés avec APT après avoir ajouté la liste des sources des paquets d’Elastic.

      Tous les paquets sont signés avec la clé de signature Elasticsearch afin de protéger votre système contre l’usurpation de paquets. Les paquets qui ont été authentifiés à l’aide de la clé seront considérés comme fiables par votre gestionnaire de paquets. Dans cette étape, vous allez importer la clé GPG publique d’Elasticsearch et ajouter la liste des sources du paquet Elastic afin d’installer Elasticsearch.

      Pour commencer, utilisez cURL, l’outil de ligne de commande pour le transfert de données avec URL pour importer la clé GPG publique d’Elasticsearch dans APT. Notez que nous utilisons les arguments -fsSL pour faire taire toute progression et toute erreur éventuelle (sauf en cas de panne de serveur) et pour permettre à cURL d’effectuer une requête sur un nouvel emplacement s’il est redirigé. Transmettez la sortie de la commande cURL au programme apt-key qui ajoute la clé GPG publique à l’APT.

      • curl -fsSL https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -

      Ensuite, ajoutez la liste des sources Elastic au répertoire sources.list.d où APT cherchera de nouvelles sources :

      • echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | sudo tee -a /etc/apt/sources.list.d/elastic-7.x.list

      Ensuite, mettez à jour vos listes de paquets afin qu’APT puisse lire la nouvelle source Elastic :

      Installez ensuite Elasticsearch avec cette commande :

      • sudo apt install elasticsearch

      Elasticsearch est maintenant installé et prêt à être configuré.

      Étape 2 — Configurer Elasticsearch

      Pour configurer Elasticsearch, nous allons modifier son principal fichier de configuration elasticsearch.yml, dans lequel la plupart de ses options de configuration sont stockées. Ce dossier se trouve dans le répertoire /etc/elasticsearch. 

      Utilisez votre éditeur de texte préféré pour modifier le fichier de configuration d’Elasticsearch. Ici, nous utiliserons nano :

      • sudo nano /etc/elasticsearch/elasticsearch.yml

      Note : Le fichier de configuration d’Elasticsearch est au format YAML, ce qui signifie que nous devons conserver le format d’indentation. Veillez à ne pas ajouter d’espaces supplémentaires lorsque vous modifiez ce fichier.

      Le site elasticsearch.yml fournit des options de configuration pour votre/vos cluster, nœud, chemins, mémoire, réseau, découverte et passerelle. La plupart de ces options sont préconfigurées dans le fichier, mais vous pouvez les modifier en fonction de vos besoins. Pour les besoins de notre démonstration d’une configuration à serveur unique, nous n’ajusterons les paramètres que pour l’hôte du réseau.

      Elasticsearch écoute le trafic de partout sur le port 9200. Vous voudrez limiter l’accès extérieur à votre instance Elasticsearch pour empêcher les personnes extérieures de lire vos données ou de fermer votre cluster Elasticsearch par le biais de son API REST. Pour restreindre l’accès et donc accroître la sécurité, trouvez la ligne qui précise network.host, décommentez-le et remplacez sa valeur par localhost de façon à ce qu’il ressemble à ça :

      /etc/elasticsearch/elasticsearch.yml

      . . .
      # ---------------------------------- Network -----------------------------------
      #
      # Set the bind address to a specific IP (IPv4 or IPv6):
      #
      network.host: localhost
      . . .
      

      Nous avons spécifié localhost de sorte qu’Elasticsearch écoute sur toutes les interfaces et les IP liés. Si vous souhaitez qu’il n’écoute que sur une interface spécifique, vous pouvez spécifier son IP au lieu de localhost. Sauvegardez et fermez elasticsearch.yml. Si vous utilisez nanovous pouvez le faire en appuyant sur CTRL+X, suivi de Y et ensuite ENTRÉE. 

      Ce sont les paramètres minimums avec lesquels vous pouvez commencer pour utiliser Elasticsearch. Vous pouvez maintenant lancer Elasticsearch pour la première fois.

      Démarrez le service Elasticsearch avec systemctl. Donnez à Elasticsearch quelques instants pour démarrer. Dans le cas contraire, vous risquez d’obtenir des erreurs en ne pouvant pas vous connecter.

      • sudo systemctl start elasticsearch

      Ensuite, exécutez la commande suivante pour permettre à Elasticsearch de démarrer à chaque fois que votre serveur démarre :

      • sudo systemctl enable elasticsearch

      Elasticsearch étant activé au démarrage, passons à l’étape suivante pour discuter de la sécurité.

      Étape 3 — Sécuriser Elasticsearch

      Par défaut, Elasticsearch peut être contrôlé par toute personne pouvant accéder à l’API HTTP. Ce n’est pas toujours un risque pour la sécurité car Elasticsearch n’écoute que sur l’interface de bouclage (c’est-à-dire 127.0.0.1), qui n’est accessible que localement. Ainsi, aucun accès public n’est possible et tant que tous les utilisateurs du serveur sont fiables, la sécurité peut ne pas être une préoccupation majeure.

      Si vous devez autoriser l’accès à distance à l’API HTTP, vous pouvez limiter l’exposition du réseau avec le pare-feu par défaut d’Ubuntu, UFW. Ce pare-feu devrait déjà être activé si vous avez suivi les étapes de la condition préalable dans le tutoriel Configuration initiale du serveur avec Ubuntu 20.04.

      Nous allons maintenant configurer le pare-feu pour permettre l’accès au port par défaut de l’API HTTP d’Elasticsearch (TCP 9200) pour l’hôte à distance fiable, généralement le serveur que vous utilisez dans une configuration à serveur unique, tel que198.51.100.0. Pour autoriser l’accès, tapez la commande suivante :

      • sudo ufw allow from 198.51.100.0 to any port 9200

      Une fois que cela est fait, vous pouvez activer l’UFW avec la commande :

      Enfin, vérifiez le statut de l’UFW avec la commande suivante :

      Si vous avez correctement spécifié les règles, vous devriez recevoir un résultat similaire à ceci :

      Output

      Status: active To Action From -- ------ ---- 9200 ALLOW 198.51.100.0 22 ALLOW Anywhere 22 (v6) ALLOW Anywhere (v6)

      L’UFW devrait maintenant être activé et mis en place pour protéger le port 9200 d’Elasticsearch.

      Si vous souhaitez investir dans une protection supplémentaire, Elasticsearch vous propose la solution commerciale plugin Shield pour l’achat. 

      Étape 4 — Tester Elasticsearch

      Maintenant, Elasticsearch devrait fonctionner sur le port 9200. Vous pouvez le tester avec cURL et une demande GET.

      • curl -X GET 'http://localhost:9200'

      Vous devriez recevoir la réponse suivante :

      Output

      { "name" : "elasticsearch-ubuntu20-04", "cluster_name" : "elasticsearch", "cluster_uuid" : "qqhFHPigQ9e2lk-a7AvLNQ", "version" : { "number" : "7.6.2", "build_flavor" : "default", "build_type" : "deb", "build_hash" : "ef48eb35cf30adf4db14086e8aabd07ef6fb113f", "build_date" : "2020-03-26T06:34:37.794943Z", "build_snapshot" : false, "lucene_version" : "8.4.0", "minimum_wire_compatibility_version" : "6.8.0", "minimum_index_compatibility_version" : "6.0.0-beta1" }, "tagline" : "You Know, for Search" }

      Si vous recevez une réponse similaire à celle ci-dessus, Elasticsearch fonctionne correctement. Si ce n’est pas le cas, assurez-vous que vous avez suivi correctement les instructions d’installation et que vous avez laissé un certain temps pour qu’Elasticsearch puisse démarrer complètement.

      Pour effectuer une vérification plus approfondie d’Elasticsearch, exécutez la commande suivante :

      • curl -XGET 'http://localhost:9200/_nodes?pretty'

      Dans le résultat de la commande ci-dessus, vous pouvez vérifier tous les paramètres actuels pour le nœud, le cluster, les chemins d’application, les modules, et plus encore.

      Étape 5 — Utiliser Elasticsearch

      Pour commencer à utiliser Elasticsearch, ajoutons d’abord quelques données. Elasticsearch utilise une API RESTful, qui répond aux commandes CRUD habituelles : create, read, update, et delete. Pour l’utiliser, nous utiliserons à nouveau la commande cURL.

      Vous pouvez ajouter votre première entrée de la sorte :

      • curl -XPOST -H "Content-Type: application/json" 'http://localhost:9200/tutorial/helloworld/1' -d '{ "message": "Hello World!" }'

      Vous devriez recevoir la réponse suivante :

      Output

      {"_index":"tutorial","_type":"helloworld","_id":"1","_version":2,"result":"updated","_shards":{"total":2,"successful":1,"failed":0},"_seq_no":1,"_primary_term":1}

      Avec cURL, nous avons envoyé une requête HTTP POST au serveur Elasticsearch. L’URI de la demande était /tutorial/helloworld/1 avec plusieurs paramètres : 

      • tutorial est l’index des données dans Elasticsearch. 
      • helloworld est le type. 
      • 1 est l’identifiant de notre entrée sous l’index et le type ci-dessus. 

      Vous pouvez récupérer cette première entrée avec une requête HTTP GET.

      • curl -X GET -H "Content-Type: application/json" 'http://localhost:9200/tutorial/helloworld/1' -d '{ "message": "Hello World!" }'

      Le résultat obtenu devrait être :

      Output

      {"_index":"tutorial","_type":"helloworld","_id":"1","_version":1,"found":true,"_source":{ "message": "Hello, World!" }}

      Pour modifier une entrée existante, vous pouvez utiliser une requête HTTP PUT.

      • curl -X PUT -H "Content-Type: application/json" 'localhost:9200/tutorial/helloworld/1?pretty' -d '
      • {
      • "message": "Hello, People!"
      • }'

      Elasticsearch devrait reconnaître une modification réussie comme celle-ci :

      Output

      { "_index" : "tutorial", "_type" : "helloworld", "_id" : "1", "_version" : 2, "result" : "updated", "_shards" : { "total" : 2, "successful" : 1, "failed" : 0 }, "_seq_no" : 1, "_primary_term" : 1 }

      Dans l’exemple ci-dessus, nous avons modifié le message de la première entrée en « Hello, People ». Avec cela, le numéro de version a été automatiquement augmenté à 2. 

      Vous avez peut-être remarqué l’argument supplémentaire pretty dans la demande ci-dessus. Il permet un format lisible par un(e) utilisateur/utilisatrice, de sorte que vous pouvez écrire chaque champ de données sur une nouvelle ligne. Vous pouvez également « embellir » vos résultats lors de la récupération des données pour obtenir un résultat plus lisible en entrant la commande suivante :

      • curl -X GET -H "Content-Type: application/json" 'http://localhost:9200/tutorial/helloworld/1?pretty'

      La réponse sera maintenant formatée pour qu’un(e) utilisateur/utilisatrice puisse l’analyser :

      Output

      { "_index" : "tutorial", "_type" : "helloworld", "_id" : "1", "_version" : 2, "_seq_no" : 1, "_primary_term" : 1, "found" : true, "_source" : { "message" : "Hello, People!" } } }

      Nous avons maintenant ajouté et interrogé des données dans Elasticsearch. Pour en savoir plus sur les autres opérations, veuillez consulter la documentation de l’API. 

      Conclusion

      Vous avez maintenant installé, configuré et commencé à utiliser Elasticsearch. Pour explorer davantage les fonctionnalités d’Elasticsearch, veuillez consulter la documentation officielle d’Elasticsearch.



      Source link

      Comment mettre en place et configurer une autorité de certification (AC) sur Ubuntu 20.04


      Introduction

      Une autorité de certification (AC) est une entité chargée d’émettre des certificats numériques pour vérifier les identités sur l’internet. Bien que les AC publiques soient un choix populaire pour vérifier l’identité des sites web et autres services qui sont fournis au grand public, les AC privées sont généralement utilisées pour les groupes fermés et les services privés.

      La création d’une autorité de certification privée vous permettra de configurer, de tester et d’exécuter des programmes qui nécessitent des connexions cryptées entre un client et un serveur. Avec une AC privée, vous pouvez émettre des certificats pour les utilisateurs, les serveurs ou les programmes et services individuels au sein de votre infrastructure.

      Quelques exemples de programmes sur Linux qui utilisent leur propre AC privée sont OpenVPN et Puppet. Vous pouvez également configurer votre serveur web pour utiliser des certificats émis par une AC privée afin de faire correspondre les environnements de développement et de simulation aux serveurs de production qui utilisent TLS pour crypter les connexions.

      Dans ce guide, nous allons apprendre comment mettre en place une autorité de certification privée sur un serveur Ubuntu 20.04 et comment générer et signer un certificat de test en utilisant votre nouvelle AC. Vous apprendrez également comment importer le certificat public du serveur de l’AC dans le magasin de certificats de votre système d’exploitation afin de pouvoir vérifier la chaîne de confiance entre l’AC et les serveurs ou utilisateurs distants. Enfin, vous apprendrez comment révoquer des certificats et distribuer une liste de révocation de certificats pour vous assurer que seuls les utilisateurs et les systèmes autorisés peuvent utiliser les services qui reposent sur votre AC.

      Conditions préalables

      Pour suivre ce tutoriel, vous devrez avoir accès à un serveur Ubuntu 20.04 pour héberger votre serveur AC. Vous devrez configurer un utilisateur non root avec privilèges sudo avant de commencer ce guide. Vous pouvez suivre notre guide de configuration initiale de serveur Ubuntu 20.04 pour configurer un utilisateur avec les permissions appropriées. Le tutoriel joint permettra également de mettre en place un pare-feu, supposé rester en place tout au long de ce guide.

      Ce serveur sera appelé Serveur AC dans ce tutoriel.

      Assurez-vous que le serveur AC est un système autonome. Il ne sera utilisé que pour importer, signer et révoquer les demandes de certificats. Il ne doit pas gérer d’autres services et, dans l’idéal, il sera hors ligne ou complètement fermé lorsque vous ne travaillerez pas activement avec votre AC.

      Remarque : la dernière section de ce tutoriel est facultative si vous souhaitez en savoir plus sur la signature et la révocation des certificats. Si vous choisissez de suivre ces étapes de pratique, vous aurez besoin d’un second serveur Ubuntu 20.04 ou vous pouvez également utiliser votre propre ordinateur Linux local fonctionnant sous Ubuntu ou Debian, ou des distributions dérivées de l’un ou l’autre.

      Étape 1 — Installation d’Easy-RSA

      La première tâche de ce tutoriel consiste à installer l’ensemble de scripts easy-rsa sur votre serveur d’AC. easy-rsa est un outil de gestion d’autorité de certification que vous utiliserez pour générer une clé privée et un certificat racine public, que vous utiliserez ensuite pour signer les demandes des clients et des serveurs qui s’appuieront sur votre AC.

      Connectez-vous à votre serveur AC en tant qu’utilisateur sudo non root que vous avez créé lors des étapes de configuration initiales et exécutez ce qui suit :

      • sudo apt update
      • sudo apt install easy-rsa

      Vous serez invité à télécharger le package et à l’installer. Appuyez sur y pour confirmer que vous souhaitez installer le package.

      À ce stade, vous disposez de tout ce dont vous avez besoin, installé et prêt pour utiliser Easy-RSA. Dans l’étape suivante, vous allez créer une infrastructure à clés publiques, puis vous commencerez à construire votre autorité de certification.

      Étape 2 — Préparation d’un répertoire d’infrastructures à clés publiques

      Maintenant que vous avez installé easy-rsa​​​, il est temps de créer un squelette de l’infrastructure de clés publiques (ICP) sur le serveur AC. Assurez-vous que vous êtes encore connecté en tant qu’utilisateur non root et créez un répertoire easy-rsa Assurez-vous que vous n’utilisez pas sudo pour exécuter l’une des commandes suivantes, puisque votre utilisateur normal doit gérer et interagir avec l’AC sans privilèges élevés.

      Cela créera un nouveau répertoire appelé easy-rsa dans votre dossier de base. Nous utiliserons ce répertoire pour créer des liens symboliques pointant vers les fichiers de packages easy-rsa que nous avons installés à l’étape précédente. Ces fichiers sont situés dans le dossier /usr/share/easy-rsa sur le serveur AC.

      Créez les liens symboliques (symlinks) avec la commande ln :

      • ln -s /usr/share/easy-rsa/* ~/easy-rsa/

      Remarque : alors que d’autres guides peuvent vous demander de copier les fichiers du package easy-rsa dans votre répertoire ICP, ce tutoriel adopte une approche par lien symbolique. Par conséquent, toute mise à jour du paquet easy-rsa sera automatiquement répercutée dans les scripts de votre ICP.

      Pour restreindre l’accès à votre nouveau répertoire ICP, assurez-vous que seul le propriétaire peut y accéder en utilisant la commande chmod :

      • chmod 700 /home/sammy/easy-rsa

      Enfin, initialisez l’ICP dans le répertoire easy-rsa :

      • cd ~/easy-rsa
      • ./easyrsa init-pki

      Output

      init-pki complete; you may now create a CA or requests. Your newly created PKI dir is: /home/sammy/easy-rsa/pki

      Après avoir terminé cette section, vous disposez d’un répertoire qui contient tous les fichiers nécessaires pour créer une autorité de certification. Dans la section suivante, vous allez créer la clé privée et le certificat public pour votre AC.

      Étape 3 — Création d’une autorité de certification

      Avant de pouvoir créer la clé et le certificat privés de votre AC, vous devez créer et alimenter un fichier appelé vars avec quelques valeurs par défaut. Tout d’abord, vous allez cd dans le répertoire easy-rsa, puis vous allez créer et modifier le fichier vars avec nano ou votre éditeur de texte préféré :

      Une fois le fichier ouvert, collez les lignes suivantes et modifiez chaque valeur mise en évidence pour refléter les informations de votre propre organisation. L’important ici est de veiller à ne laisser aucune des valeurs en blanc :

      ~/easy-rsa/vars

      set_var EASYRSA_REQ_COUNTRY "US" set_var EASYRSA_REQ_PROVINCE "NewYork" set_var EASYRSA_REQ_CITY "New York City" set_var EASYRSA_REQ_ORG "DigitalOcean" set_var EASYRSA_REQ_EMAIL "admin@example.com" set_var EASYRSA_REQ_OU "Community" set_var EASYRSA_ALGO "ec" set_var EASYRSA_DIGEST "sha512"

      Lorsque vous avez terminé, enregistrez et fermez le fichier. Si vous utilisez nano, vous pouvez le faire en appuyant sur CTRL+X, puis Y et ENTER pour confirmer. Vous êtes maintenant prêt à construire votre AC.

      Pour créer la paire de clés root public et privé pour votre autorité de certification, exécutez à nouveau la commande ./easy-rsa, cette fois-ci avec l’option build-ca :

      Dans la sortie, vous verrez quelques lignes sur la version OpenSSL et vous serez invité à entrer une phrase de passe pour votre paire de clés. Assurez-vous de choisir une phrase de passe solide, et notez-le dans un endroit sûr. Vous devrez saisir la phrase de passe chaque fois vous devrez interagir avec votre AC, par exemple pour signer ou révoquer un certificat.

      Il vous sera également demandé de confirmer le Nom commun (CN) de votre AC. Le nom commun est le nom utilisé pour désigner cette machine dans le contexte de l’autorité de certification. Vous pouvez saisir n’importe quelle chaîne de caractères pour le nom commun de l’AC mais, par souci de simplicité, appuyez sur ENTER (ENTRÉE) pour accepter le nom par défaut.

      Output

      . . . Enter New CA Key Passphrase: Re-Enter New CA Key Passphrase: . . . Common Name (eg: your user, host, or server name) [Easy-RSA CA]: CA creation complete and you may now import and sign cert requests. Your new CA certificate file for publishing is at: /home/sammy/easy-rsa/pki/ca.crt

      Remarque : Si vous ne voulez pas qu’un mot de passe vous soit demandé à chaque fois que vous interagissez avec votre AC, vous pouvez exécuter la commande build-ca avec l’option nopass, comme ceci :

      • ./easyrsa build-ca nopass

      Vous disposez maintenant de deux fichiers importants – ~/easy-rsa/pki/ca.crt et ~/easy-rsa/pki/private/ca.key – qui constituent les composants publics et privés d’une autorité de certification.

      • ca.crt est le fichier de certificats public de l’AC. Les utilisateurs, les serveurs et les clients utiliseront ce certificat pour vérifier qu’ils font partie du même réseau de confiance. Chaque utilisateur et serveur qui utilise votre AC devront avoir une copie de ce fichier. Toutes les parties s’appuieront sur le certificat public pour s’assurer qu’une personne ne se fait pas passer pour un système et n’effectue pas une attaque de type Man-in-the-middle.

      • ca.key est la clé privée que l’AC utilise pour signer les clés et les certificats des serveurs et des clients. Si un intrus accède à votre AC et, à son tour, à votre fichier ca.key, vous devrez détruire votre AC. C’est pourquoi votre fichier ca.key ne doit se trouver que sur votre machine AC et votre machine AC doit idéalement être maintenue hors ligne lorsqu’elle ne signe pas de demandes de certificat, par mesure de sécurité supplémentaire.

      Avec cela, votre AC est en place et elle est prête à être utilisée pour signer des demandes de certificats et pour révoquer des certificats.

      Étape 4 — Distribuer le certificat public de votre autorité de certification

      Votre AC est maintenant configurée et prête à agir comme une racine de confiance pour tous les systèmes que vous voulez configurer en vue de son utilisation. Vous pouvez ajouter le certificat de l’AC à vos serveurs OpenVPN, serveurs web, serveurs de messagerie, etc. Tout utilisateur ou serveur qui doit vérifier l’identité d’un autre utilisateur ou serveur de votre réseau devrait avoir une copie du fichier ca.crt importé dans le magasin de certificats de son système d’exploitation.

      Pour importer le certificat public de l’AC dans un deuxième système Linux comme un autre serveur ou un ordinateur local, obtenez d’abord une copie du fichier ca.crt de votre serveur AC. Vous pouvez utiliser la commande cat pour le sortir dans un terminal, puis le copier et le coller dans un fichier sur le deuxième ordinateur qui importe le certificat. Vous pouvez également utiliser des outils comme scp, rsync pour transférer le fichier entre les systèmes. Cependant, nous utiliserons un copier-coller avec nano dans cette étape car cela fonctionne sur tous les systèmes.

      En tant qu’utilisateur non root sur le serveur AC, exécutez la commande suivante :

      • cat ~/easy-rsa/pki/ca.crt

      Il y aura une sortie dans votre terminal qui ressemblera à ce qui suit :

      Output

      -----BEGIN CERTIFICATE----- MIIDSzCCAjOgAwIBAgIUcR9Crsv3FBEujrPZnZnU4nSb5TMwDQYJKoZIhvcNAQEL BQAwFjEUMBIGA1UEAwwLRWFzeS1SU0EgQ0EwHhcNMjAwMzE4MDMxNjI2WhcNMzAw . . . . . . -----END CERTIFICATE-----

      Copiez tout, y compris les lignes -----BEGIN CERTIFICATE-----​​​ et –-----END CERTIFICATE----- et les tirets.

      Sur votre deuxième système Linux, utilisez nano ou votre éditeur de texte préféré pour ouvrir un fichier appelé /tmp/ca.crt :

      Collez le contenu que vous venez de copier du serveur AC dans l’éditeur. Lorsque vous avez terminé, enregistrez et fermez le fichier. Si vous utilisez nano, vous pouvez le faire en appuyant sur CTRL+X, puis Y et ENTER pour confirmer.

      Maintenant que vous disposez d’une copie du fichier ca.crt sur votre deuxième système Linux,il est temps d’importer le certificat dans le magasin de certificats de son système d’exploitation.

      Sur les systèmes basés sur Ubuntu et Debian, exécutez les commandes suivantes en tant qu’utilisateur non root pour importer le certificat :

      Ubuntu and Debian derived distributions

      • sudo cp /tmp/ca.crt /usr/local/share/ca-certificates/
      • sudo update-ca-certificates

      Pour importer le certificat du serveur AC sur un système basé sur CentOS, Fedora ou RedHat, copiez et collez le contenu du fichier sur le système tout comme dans l’exemple précédent dans un fichier appelé /tmp/ca.crt. Ensuite, vous copierez le certificat dans /etc/pki/ca-trust/source/anchors/, puis vous exécuterez la commande update-ca-trust.

      CentOS, Fedora, RedHat distributions

      • sudo cp /tmp/ca.crt /etc/pki/ca-trust/source/anchors/
      • sudo update-ca-trust

      Votre deuxième système Linux fera maintenant confiance à tout certificat qui a été signé par le serveur AC.

      Remarque : si vous utilisez votre AC avec des serveurs web et si vous utilisez le navigateur Firefox, vous devrez importer directement le certificat ca.crt public dans Firefox. Firefox n’utilise pas le magasin de certificats du système d’exploitation local. Pour plus de détails sur la façon d’ajouter le certificat de votre AC à Firefox, veuillez consulter cet article de Mozilla sur la configuration des autorités de certification (AC) dans Firefox.

      Si vous utilisez votre AC pour intégrer un environnement Windows ou des ordinateurs de bureau, veuillez consulter la documentation sur la façon d’utiliser certutil.exe pour installer un certificat d’AC.

      Si vous utilisez ce tutoriel comme condition préalable à un autre tutoriel, ou si vous savez comment signer et révoquer des certificats, vous pouvez vous arrêter ici. Si vous souhaitez en savoir plus sur la façon de signer et de révoquer des certificats, la section facultative suivante vous expliquera chaque processus en détail.

      (Facultatif) — Création de demandes de signature de certificats et révocation des certificats

      Les sections suivantes du tutoriel sont facultatives. Si vous avez effectué toutes les étapes précédentes, vous disposez d’une autorité de certification entièrement configurée et opérationnelle que vous pouvez utiliser comme condition préalable pour d’autres tutoriels. Vous pouvez importer le fichier ca.crt de votre AC et vérifier dans votre réseau les certificats qui ont été signés par votre AC.

      Si vous souhaitez vous entraîner et en savoir plus sur la manière de signer des demandes de certificat et sur la manière de révoquer des certificats, ces sections facultatives vous expliqueront comment fonctionnent les deux processus.

      (Facultatif) — Création et signature d’une demande de certificat de pratique

      Maintenant que vous avez une AC prête à l’emploi, vous pouvez vous entraîner à générer une clé privée et une demande de certificat pour vous familiariser avec le processus de signature et de distribution.

      Une demande de signature de certificat (CSR) se compose de trois parties : une clé publique, des informations d’identification sur le système requérant, et une signature de la requête elle-même, qui est créée en utilisant la clé privée de la partie requérante. La clé privée sera gardée secrète et sera utilisée pour chiffrer les informations que toute personne possédant le certificat public signé pourra ensuite déchiffrer.

      Les étapes suivantes seront exécutées sur votre second système Ubuntu ou Debian ou une distribution dérivée de l’un de ces systèmes. Il peut s’agir d’un autre serveur distant, ou d’une machine Linux locale comme un ordinateur portable ou un ordinateur de bureau. Comme easy-rsa n’est pas disponible par défaut sur tous les systèmes, nous utiliserons l’outil openssl pour créer une clé privée et un certificat de pratique.

      openssl est généralement installé par défaut sur la plupart des distributions Linux, mais juste pour en être certain, exécutez ce qui suit sur votre système

      • sudo apt update
      • sudo apt install openssl

      Lorsque vous êtes invité à installer openssl, entrez y pour poursuivre les étapes d’installation.  Maintenant, vous êtes prêt à créer une pratique CSR avec openssl.

      La première étape que vous devez suivre pour créer une CSR est la génération d’une clé privée. Pour créer une clé privée en utilisant openssl, créez un répertoire “practice-csr” et générez ensuite une clé à l’intérieur de celui-ci. Nous allons faire cette requête pour un serveur fictif appelé sammy-server, par opposition à la création d’un certificat qui est utilisé pour identifier un utilisateur ou une autre AC.

      • mkdir ~/practice-csr
      • cd ~/practice-csr
      • openssl genrsa -out sammy-server.key

      Output

      Generating RSA private key, 2048 bit long modulus (2 primes) . . . . . . e is 65537 (0x010001)

      Maintenant que vous avez une clé privée, vous pouvez créer une CSR correspondante, à nouveau en utilisant l’utilitaire openssl. Vous serez invité à remplir un certain nombre de champs comme Pays, État et Ville. Vous pouvez saisir un . si vous souhaitez laisser un champ vide, mais sachez que s’il s’agit d’une véritable CSR, il est préférable d’utiliser les valeurs correctes de votre localisation et votre organisation :

      • openssl req -new -key sammy-server.key -out sammy-server.req

      Output

      . . . ----- Country Name (2 letter code) [XX]:US State or Province Name (full name) []:New York Locality Name (eg, city) [Default City]:New York City Organization Name (eg, company) [Default Company Ltd]:DigitalOcean Organizational Unit Name (eg, section) []:Community Common Name (eg, your name or your server's hostname) []:sammy-server Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:

      Si vous souhaitez ajouter automatiquement ces valeurs dans le cadre de l’invocation openssl plutôt que via l’invite interactive, vous pouvez passer l’argument -subj à OpenSSL. Veillez à modifier les valeurs mises en évidence pour qu’elles correspondent à votre lieu d’exercice, à votre organisation et au nom de votre serveur :

      • openssl req -new -key sammy-server.key -out server.req -subj
      • /C=US/ST=New York/L=New York City/O=DigitalOcean/OU=Community/CN=sammy-server

      Pour vérifier le contenu d’une CSR, vous pouvez lire dans un fichier de requête avec openssl et examiner les champs à l’intérieur

      • openssl req -in sammy-server.req -noout -subject

      Output

      subject=C = US, ST = New York, L = New York City, O = DigitalOcean, OU = Community, CN = sammy-server

      Une fois que vous êtes satisfait de l’objet de votre demande de certificat de pratique, copiez le fichier sammy-server.req sur votre serveur AC en utilisant scp

      • scp sammy-server.req sammy@your_ca_server_ip:/tmp/sammy-server.req

      Au cours de cette étape, vous avez généré une demande de signature de certificat pour un serveur fictif appelé sammy-server. Dans un scénario réel, la demande peut provenir d’un serveur web de développement ou de simulation qui a besoin d’un certificat TLS pour des tests, ou d’un serveur OpenVPN qui demande un certificat pour que les utilisateurs puissent se connecter à un VPN. Au cours de l’étape suivante, nous allons passer à la signature de la demande de signature de certificat en utilisant la clé privée du serveur AC.

      (Facultatif) – Signature d’une CSR

      Dans l’étape précédente, vous avez créé une demande de certificat de pratique et une clé pour un serveur fictif. Vous l’avez copiée dans le répertoire /tmp de votre serveur AC, en émulant le processus que vous utiliseriez si vous aviez de vrais clients ou serveurs vous envoyant des demandes de CSR à signer.

      Poursuivant le scénario fictif, le serveur AC doit maintenant importer le certificat de pratique et le signer. Une fois qu’une demande de certificat est validée par l’AC et relayée à un serveur, les clients qui font confiance à l’autorité de certification pourront également faire confiance au certificat nouvellement émis.

      Comme nous opérerons au sein de l’ICP de l’AC où l’utilitaire easy-rsa est disponible, les étapes de signature utiliseront l’utilitaire easy-rsa pour faciliter les choses, au lieu d’utiliser directement openssl comme nous l’avons fait dans l’exemple précédent.

      La première étape pour signer la CSR fictive est d’importer la demande de certificat en utilisant le script easy-rsa

      • cd ~/easy-rsa
      • ./easyrsa import-req /tmp/sammy-server.req sammy-server

      Output

      . . . The request has been successfully imported with a short name of: sammy-server You may now use this name to perform signing operations on this request.

      Maintenant, vous pouvez signer la demande en exécutant le script easyrsa avec l’option sign-req suivi du type de requête et du nom commun qui est inclus dans la CSR. Le type de requête peut soit être client, server, ou ca. Comme nous nous entraînons avec un certificat pour un serveur fictif, assurez-vous d’utiliser le type de requête du serveur :

      • ./easyrsa sign-req server sammy-server

      Dans la sortie, il vous sera demandé de vérifier que la requête provient d’une source fiable. Tapez yes puis appuyez sur ENTER pour confirmer :

      Output

      You are about to sign the following certificate. Please check over the details shown below for accuracy. Note that this request has not been cryptographically verified. Please be sure it came from a trusted source or that you have verified the request checksum with the sender. Request subject, to be signed as a server certificate for 3650 days: subject= commonName = sammy-server Type the word 'yes' to continue, or any other input to abort. Confirm request details: yes . . . Certificate created at: /home/sammy/easy-rsa/pki/issued/sammy-server.crt

      Si vous avez crypté votre clé AC, on vous demandera votre mot de passe à ce stade.

      Une fois ces étapes terminées, vous avez signé la CSR sammy-server.req en utilisant la clé privée du serveur AC dans /home/sammy/easy-rsa/pki/private/ca.key. Le fichier sammy-server.crt qui en résulte contient la clé de chiffrement publique du serveur de pratique, ainsi qu’une nouvelle signature du serveur AC. Le but de la signature est de dire à toute personne qui fait confiance à l’AC qu’elle peut également faire confiance au certificat du sammy-server.

      Si cette requête concerne un vrai serveur comme un serveur web ou un serveur VPN, la dernière étape sur le serveur AC serait de distribuer les nouveaux fichiers sammy-server.crt et ca.crt du serveur AC au serveur distant qui a fait la requête CSR :

      • scp pki/issued/sammy-server.crt sammy@your_server_ip:/tmp
      • scp pki/ca.crt sammy@your_server_ip:/tmp

      À ce stade, vous pourrez utiliser le certificat délivré avec un serveur web, un VPN, un outil de gestion de la configuration, un système de base de données ou à des fins d’authentification des clients.

      (Facultatif) — Révocation d’un certificat

      Il peut arriver que vous deviez révoquer un certificat pour empêcher un utilisateur ou un serveur de l’utiliser. Il se peut que l’ordinateur portable de quelqu’un ait été volé, qu’un serveur web ait été compromis, ou qu’un employé ou un contractant ait quitté votre organisation.

      Pour révoquer un certificat, la procédure générale suit les étapes suivantes :

      1. Révoquez le certificat avec la commande ./easyrsa revoke client_name
      2. Générez une nouvelle LRC avec la commande ./easyrsa gen-crl
      3. Transférez le fichier crl.pem mis à jour vers le ou les serveurs qui dépendent de votre AC, et sur ces systèmes, copiez le fichier dans le ou les répertoires requis pour les programmes qui s’y réfèrent.
      4. Redémarrez tous les services qui utilisent votre AC et le fichier LRC.

      Vous pouvez utiliser ce processus pour révoquer à tout moment les certificats que vous avez précédemment émis. Nous allons passer en détail chaque étape dans les sections suivantes, en commençant par la commande revoke

      Révoquer un certificat

      Pour révoquer un certificat, naviguez vers le répertoire easy-rsa sur votre serveur AC :

      Ensuite, lancez le script easyrsa avec l’option revoke, suivi du nom du client que vous souhaitez révoquer : En suivant l’exemple de pratique ci-dessus, le nom commun du certificat est sammy-server :

      • ./easyrsa revoke sammy-server

      Il vous sera demandé de confirmer la révocation en entrant yes :

      Output

      Please confirm you wish to revoke the certificate with the following subject: subject= commonName = sammy-server Type the word 'yes' to continue, or any other input to abort. Continue with revocation: yes . . . Revoking Certificate 8348B3F146A765581946040D5C4D590A . . .

      Notez la valeur mise en évidence sur la ligne Revoking Certificate Cette valeur est le numéro de série unique du certificat qui est en cours de révocation. Si vous voulez examiner la liste de révocation à la dernière étape de cette section pour vérifier que le certificat y figure, vous aurez besoin de cette valeur.

      Après avoir confirmé l’action, l’AC va révoquer le certificat. Cependant, les systèmes distants qui dépendent de l’AC n’ont aucun moyen de vérifier si des certificats ont été révoqués. Les utilisateurs et les serveurs pourront toujours utiliser le certificat jusqu’à ce que la liste des certificats révoqués (LCR) de l’AC soit distribuée à tous les systèmes qui dépendent de l’AC.

      Dans l’étape suivante, vous allez générer une LCR ou mettre à jour un fichier crl.pem existant.

      Générer une liste de révocation de certificats

      Maintenant que vous avez révoqué un certificat, il est important de mettre à jour la liste des certificats révoqués sur votre serveur AC. Une fois que vous aurez mis à jour la liste des révocations, vous serez en mesure de savoir quels utilisateurs et quels systèmes ont des certificats valides dans votre AC.

      Pour générer une LRC, exécutez la commande easy-rsa avec l’option gen-crl tout en restant dans le répertoire ~/easy-rsa :

      Si vous avez utilisé une phrase de passe lors de la création de votre fichier ca.key, vous serez invité à l’entrer. La commande gen-crl générera un fichier appelé crl.pem, contenant la liste actualisée des certificats révoqués pour cette AC.

      Ensuite, vous devrez transférer le fichier crl.pem mis à jour à tous les serveurs et clients qui dépendent de cette AC chaque fois que vous exécuterez la commande gen-crl. Sinon, les clients et les systèmes pourront toujours accéder aux services et aux systèmes qui utilisent votre AC, puisque ces services doivent connaître le statut de révocation du certificat.

      Transférer une liste de révocation de certificats

      Maintenant que vous avez généré une LCR sur le serveur de votre AC, vous devez la transférer vers les systèmes distants qui dépendent de votre AC. Pour transférer ce fichier à vos serveurs, vous pouvez utiliser la commande scp.

      Remarque : ce tutoriel explique comment générer et distribuer manuellement une LCR. Bien qu’il existe des méthodes plus solides et automatisées pour distribuer et vérifier les listes de révocation, comme l’agrafage OCSP, la configuration de ces méthodes dépasse le cadre de cet article.

      Assurez-vous que vous êtes connecté à votre serveur AC en tant qu’utilisateur non racine et exécutez les opérations suivantes, en substituant l’IP ou le nom DNS de votre propre serveur à la place de your_server_ip :

      • scp ~/easy-rsa/pki/crl.pem sammy@your_server_ip:/tmp

      Maintenant que le fichier est sur le système distant, la dernière étape consiste à mettre à jour tous les services avec la nouvelle copie de la liste de révocation.

      Mise à jour des services qui prennent en charge une LCR

      L’énumération des étapes à suivre pour mettre à jour les services qui utilisent le fichier crl.pem dépasse la portée de ce tutoriel. En général, vous devrez copier le fichier crl.pem à l’emplacement prévu par le service, puis le redémarrer à l’aide de systemctl.

      Une fois que vous aurez mis à jour vos services avec le nouveau fichier crl.pem, vos services pourront rejeter les connexions des clients ou des serveurs qui utilisent un certificat révoqué.

      Examen et vérification du contenu d’une LCR

      Si vous souhaitez examiner un fichier CRL, par exemple pour confirmer une liste de certificats révoqués, utilisez la commande openssl suivante à partir de votre répertoire easy-rsa sur votre serveur AC :

      • cd ~/easy-rsa
      • openssl crl -in pki/crl.pem -noout -text

      Vous pouvez également exécuter cette commande sur tout serveur ou système qui dispose de l’outil openssl installé avec une copie du fichier crl.pem. Par exemple, si vous avez transféré le fichier crl.pem sur votre second système et que vous souhaitez vérifier que le certificat de sammy-server est révoqué, vous pouvez utiliser une commande openssl comme celle qui suit, en introduisant le numéro de série que vous avez noté précédemment lorsque vous avez révoqué le certificat à la place de numéro mis en évidence ici :

      • openssl crl -in /tmp/crl.pem -noout -text |grep -A 1 8348B3F146A765581946040D5C4D590A

      Output

      Serial Number: 8348B3F146A765581946040D5C4D590A Revocation Date: Apr 1 20:48:02 2020 GMT

      Remarquez comment la commande grep est utilisée pour vérifier le numéro de série unique que vous avez noté dans l’étape de révocation. Vous pouvez maintenant vérifier le contenu de votre liste de révocation de certificat sur tout système qui s’appuie sur elle pour restreindre l’accès aux utilisateurs et aux services.

      Conclusion

      Dans ce tutoriel, vous avez créé une autorité de certification privée en utilisant le package Easy-RSA sur un serveur Ubuntu 20.04 autonome. Vous avez appris comment fonctionne le modèle de confiance entre les parties qui s’appuient sur l’autorité de certification. Vous avez également créé et signé une demande de signature de certificat (CSR) pour un serveur de pratique, puis appris à révoquer un certificat. Enfin, vous avez appris comment générer et distribuer une liste de révocation de certificats (LRC) pour tout système qui dépend de votre AC afin de s’assurer que les utilisateurs ou les serveurs qui ne devraient pas accéder aux services en soient empêchés.

      Vous pouvez maintenant délivrer des certificats pour les utilisateurs et les utiliser avec des services comme OpenVPN. Vous pouvez également utiliser votre AC pour configurer des serveurs web de développement et de simulation avec des certificats, afin de sécuriser vos environnements hors production. L’utilisation d’une AC avec des certificats TLS pendant le développement peut contribuer à garantir que votre code et vos environnements correspondent autant que possible à votre environnement de production.

      Si vous souhaitez en savoir plus sur l’utilisation d’OpenSSL, consultez notre page sur les principes essentiels d’OpenSSL : Travailler avec les certificats SSL, les clés privées et les CSR contient de nombreuses informations supplémentaires pour vous aider à vous familiariser avec les principes fondamentaux d’OpenSSL.



      Source link

      Comment configurer des clés SSH sur Ubuntu 20.04


      Introduction

      SSH, ou secure shell, est un protocole crypté utilisé pour administrer et communiquer avec des serveurs. Lorsque vous travaillez avec un serveur Ubuntu, il y a de fortes chances que vous passiez la majeure partie de votre temps dans une session terminal connectée à votre serveur par SSH.

      Dans ce guide, nous allons nous concentrer sur la configuration des clés SSH pour une installation Ubuntu 20.04. Les clés SSH constituent un moyen simple et sûr de se connecter à votre serveur et sont recommandées à tous les utilisateurs.

      Étape 1 – Création de la paire de clés

      La première étape consiste à créer une paire de clés sur la machine cliente (généralement votre ordinateur) :

      Par défaut, les versions récentes de ssh-keygen créeront une paire de clés RSA de 3072 bits, ce qui est suffisamment sûr pour la plupart des cas d’utilisation (vous pouvez éventuellement passer le drapeau -b 4096 pour créer une clé de 4096 bits plus grande).

      Après avoir entré la commande, vous devriez voir la sortie suivante :

      Output

      Generating public/private rsa key pair. Enter file in which to save the key (/your_home/.ssh/id_rsa):

      Appuyez sur la touche Entrée pour enregistrer la paire de clés dans le sous-répertoire .ssh/ de votre répertoire de base, ou indiquez un autre chemin d’accès.

      Si vous aviez précédemment généré une paire de clés SSH, vous verrez peut-être s’afficher le message suivant :

      Output

      /home/your_home/.ssh/id_rsa already exists. Overwrite (y/n)?

      Si vous choisissez d’écraser la clé sur le disque, vous ne pourrez plus vous authentifier à l’aide de la clé précédente. Soyez très prudent lorsque vous sélectionnez « yes », car il s’agit d’un processus de suppression irréversible.

      Vous devriez alors voir le message suivant :

      Output

      Enter passphrase (empty for no passphrase):

      Ici, vous pouvez choisir d’entrer une phrase de passe sécurisée, ce qui est fortement recommandé. Une phrase de passe ajoute une sécurité supplémentaire pour empêcher les utilisateurs non autorisés de se connecter. Pour en savoir plus sur la sécurité, consultez notre tutoriel Comment configurer l’authentification par clé SSH sur un serveur Linux.

      Vous devriez alors voir une sortie semblable à ce qui suit :

      Output

      Your identification has been saved in /your_home/.ssh/id_rsa Your public key has been saved in /your_home/.ssh/id_rsa.pub The key fingerprint is: SHA256:/hk7MJ5n5aiqdfTVUZr+2Qt+qCiS7BIm5Iv0dxrc3ks user@host The key's randomart image is: +---[RSA 3072]----+ | .| | + | | + | | . o . | |o S . o | | + o. .oo. .. .o| |o = oooooEo+ ...o| |.. o *o+=.*+o....| | =+=ooB=o.... | +----[SHA256]-----+

      Vous disposez désormais d’une clé publique et privée que vous pouvez utiliser pour vous authentifier. L’étape suivante consiste à placer la clé publique sur votre serveur afin que vous puissiez utiliser l’authentification basée sur la clé SSH pour vous connecter.

      Étape 2 – Copie de la clé publique sur votre serveur Ubuntu

      La façon la plus rapide de copier votre clé publique sur l’hôte Ubuntu est d’utiliser un utilitaire appelé ssh-copy-id. En raison de sa simplicité, cette méthode est fortement recommandée si elle est disponible. Si vous ne disposez pas de ssh-copy-id sur votre machine cliente, vous pouvez utiliser l’une des deux méthodes alternatives fournies dans cette section (copie via SSH basé sur un mot de passe, ou copie manuelle de la clé).

      Copier la clé publique à l’aide de ssh-copy-id

      L’outil ssh-copy-id est inclus par défaut dans de nombreux systèmes d’exploitation, il est donc possible qu’il soit disponible sur votre système local. Pour que cette méthode fonctionne, vous devez déjà disposer d’un accès SSH à votre serveur, basé sur un mot de passe.

      Pour utiliser l’utilitaire, vous devez spécifier l’hôte distant auquel vous souhaitez vous connecter et le compte utilisateur auquel vous avez accès par mot de passe en SSH. C’est le compte sur lequel votre clé publique SSH sera copiée.

      La syntaxe est la suivante :

      • ssh-copy-id username@remote_host

      Vous verrez peut-être le message suivant :

      Output

      The authenticity of host '203.0.113.1 (203.0.113.1)' can't be established. ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe. Are you sure you want to continue connecting (yes/no)? yes

      Cela signifie que votre ordinateur local ne reconnaît pas l’hôte distant. Cela se produira la première fois que vous vous connecterez à un nouvel hôte. Tapez « yes » et appuyez sur ENTER (ENTRÉE) pour continuer.

      Ensuite, l’utilitaire recherchera sur votre compte local la clé id_rsa.pub que nous avons créée précédemment. Lorsqu’il trouvera la clé, il vous demandera le mot de passe du compte de l’utilisateur distant :

      Output

      /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys username@203.0.113.1's password:

      Saisissez le mot de passe (votre saisie ne sera pas affichée pour des raisons de sécurité) et appuyez sur ENTER . L’utilitaire se connectera au compte sur l’hôte distant en utilisant le mot de passe que vous avez fourni. Il copiera ensuite le contenu de votre clé ~/.ssh/id_rsa.pub dans un fichier situé dans le répertoire de base ~/.ssh du compte distant appelé authorized_keys.

      Vous devriez voir le message suivant :

      Output

      Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'username@203.0.113.1'" and check to make sure that only the key(s) you wanted were added.

      À ce stade, votre clé id_rsa.pub a été téléchargée sur le compte distant. Vous pouvez passer à l’étape 3.

      Copier la clé publique à l’aide de SSH

      Si vous ne disposez pas de ssh-copy-id, mais que vous avez un accès SSH par mot de passe à un compte sur votre serveur, vous pouvez télécharger vos clés en utilisant une méthode SSH classique.

      Nous pouvons le faire en utilisant la commande cat pour lire le contenu de la clé publique SSH sur notre ordinateur local et en l’acheminant par une connexion SSH vers le serveur distant.

      D’autre part, nous pouvons nous assurer que le répertoire ~/.ssh existe et a les bonnes permissions sous le compte que nous utilisons.

      Nous pouvons alors extraire le contenu que nous avons transféré dans un fichier appelé authorized_keys dans ce répertoire. Nous utiliserons le symbole de redirection >> pour ajouter le contenu au lieu d’écraser le contenu précédent. Cela nous permettra d’ajouter des clés sans détruire les clés précédemment ajoutées.

      La commande complète ressemble à ceci :

      • cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && touch ~/.ssh/authorized_keys && chmod -R go= ~/.ssh && cat >> ~/.ssh/authorized_keys"

      Vous verrez peut-être le message suivant :

      Output

      The authenticity of host '203.0.113.1 (203.0.113.1)' can't be established. ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe. Are you sure you want to continue connecting (yes/no)? yes

      Cela signifie que votre ordinateur local ne reconnaît pas l’hôte distant. Cela se produira la première fois que vous vous connecterez à un nouvel hôte. Tapez « yes » et appuyez sur ENTER pour continuer.

      Ensuite, il vous sera demandé de saisir le mot de passe du compte d’utilisateur distant :

      Output

      username@203.0.113.1's password:

      Après avoir saisi votre mot de passe, le contenu de votre clé id_rsa.pub sera copié à la fin du fichier authorized_keys du compte de l’utilisateur distant. Passez à l’étape 3 si vous avez réussi.

      Copier manuellement la clé publique

      Si vous ne disposez pas d’un accès SSH basé sur un mot de passe à votre serveur, vous devrez effectuer le processus ci-dessus manuellement.

      Nous ajouterons manuellement le contenu de votre fichier id_rsa.pub au fichier ~/.ssh/authorized_keys sur votre machine distante.

      Pour afficher le contenu de votre clé id_rsa.pub, tapez ceci dans votre ordinateur local :

      Vous verrez le contenu de la clé, qui devrait ressembler à ceci :

      Output

      ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqql6MzstZYh1TmWWv11q5O3pISj2ZFl9HgH1JLknLLx44+tXfJ7mIrKNxOOwxIxvcBF8PXSYvobFYEZjGIVCEAjrUzLiIxbyCoxVyle7Q+bqgZ8SeeM8wzytsY+dVGcBxF6N4JS+zVk5eMcV385gG3Y6ON3EG112n6d+SMXY0OEBIcO6x+PnUSGHrSgpBgX7Ks1r7xqFa7heJLLt2wWwkARptX7udSq05paBhcpB0pHtA1Rfz3K2B+ZVIpSDfki9UVKzT8JUmwW6NNzSgxUfQHGwnW7kj4jp4AT0VZk3ADw497M2G/12N0PPB5CnhHf7ovgy6nL1ikrygTKRFmNZISvAcywB9GVqNAVE+ZHDSCuURNsAInVzgYo9xgJDW8wUw2o8U77+xiFxgI5QSZX3Iq7YLMgeksaO4rBJEa54k8m5wEiEE1nUhLuJ0X/vh2xPff6SQ1BL/zkOhvJCACK6Vb15mDOeCSq54Cr7kvS46itMosi/uS66+PujOO+xt/2FWYepz6ZlN70bRly57Q06J+ZJoc9FfBCbCyYH7U/ASsmY095ywPsBo1XQ9PqhnN1/YOorJ068foQDNVpm146mUpILVxmq41Cj55YKHEazXGsdBIbXWhcrRf4G2fJLRcGUr9q8/lERo9oxRm5JFX6TCmj6kmiFqv+Ow9gI0x8GvaQ== demo@test

      Accédez à votre hôte distant en utilisant la méthode dont vous disposez.

      Une fois que vous avez accès à votre compte sur le serveur distant, vous devez vous assurer que le répertoire ~/.ssh existe. Cette commande va créer le répertoire si nécessaire, ou ne rien faire s’il existe déjà :

      Maintenant, vous pouvez créer ou modifier le fichier authorized_keys dans ce répertoire. Vous pouvez ajouter le contenu de votre fichier id_rsa.pub à la fin du fichier authorized_keys, en le créant si nécessaire, à l’aide de cette commande :

      • echo public_key_string >> ~/.ssh/authorized_keys

      Dans la commande ci-dessus, remplacez la chaîne public_key_string par la sortie de la commande cat ~/.ssh/id_rsa.pub que vous avez exécutée sur votre système local. Elle devrait commencer par ssh-rsa AAAA....

      Enfin, nous nous assurerons que le répertoire ~/.ssh et le fichier authorized_keys ont les permissions appropriées :

      Cela supprime récursivement toutes les permissions « group » et « other » pour le répertoire ~/.ssh/.

      Si vous utilisez le compte root pour configurer les clés d’un compte utilisateur, il est également important que le répertoire ~/.ssh appartienne à l’utilisateur et non au compte root :

      • chown -R sammy:sammy ~/.ssh

      Dans ce tutoriel, notre utilisateur est nommé sammy mais vous devez substituer le nom d’utilisateur approprié dans la commande ci-dessus.

      Nous pouvons désormais tenter une authentification sans mot de passe avec notre serveur Ubuntu.

      Étape 3 – Authentification sur votre serveur Ubuntu à l’aide de clés SSH

      Si vous avez effectué avec succès l’une des procédures ci-dessus, vous devriez pouvoir vous connecter à l’hôte distant sans fournir le mot de passe du compte distant.

      Le processus de base est le même :

      Si c’est la première fois que vous vous connectez à cet hôte (si vous avez utilisé la dernière méthode ci-dessus), vous verrez peut-être quelque chose comme ceci :

      Output

      The authenticity of host '203.0.113.1 (203.0.113.1)' can't be established. ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe. Are you sure you want to continue connecting (yes/no)? yes

      Cela signifie que votre ordinateur local ne reconnaît pas l’hôte distant. Tapez « yes » et appuyez sur ENTER pour continuer.

      Si vous n’avez pas fourni de phrase de passe pour votre clé privée, vous serez immédiatement connecté. Si vous avez fourni une phrase de passe lorsque vous avez créé la clé privée, vous serez invité à la saisir maintenant (notez que votre saisie ne s’affichera pas dans la session du terminal pour des raisons de sécurité). Après authentification, une nouvelle session shell devrait s’ouvrir pour vous avec le compte configuré sur le serveur Ubuntu.

      Si l’authentification par clé a réussi, continuez le tutoriel pour apprendre comment sécuriser davantage votre système en désactivant l’authentification par mot de passe.

      Étape 4 – Désactivation de l’authentification par mot de passe sur votre serveur

      Si vous avez pu vous connecter à votre compte en utilisant SSH sans mot de passe, vous avez réussi à configurer une authentification basée sur la clé SSH pour votre compte. Cependant, votre mécanisme d’authentification par mot de passe est toujours actif, ce qui signifie que votre serveur est toujours exposé aux attaques par force brute.

      Avant d’effectuer les étapes de cette section, assurez-vous que vous avez configuré une authentification basée sur une clé SSH pour le compte root sur ce serveur, ou de préférence, que vous avez configuré une authentification basée sur une clé SSH pour un compte non root sur ce serveur avec des privilèges sudo. Cette étape permettra de verrouiller les connexions par mot de passe, il est donc essentiel de s’assurer que vous pourrez toujours obtenir un accès administratif.

      Une fois que vous avez confirmé que votre compte distant a des privilèges administratifs, connectez-vous à votre serveur distant avec des clés SSH, soit en tant que root, soit avec un compte ayant des privilèges sudo. Ensuite, ouvrez le fichier de configuration du démon SSH :

      • sudo nano /etc/ssh/sshd_config

      Dans le fichier, recherchez une directive appelée PasswordAuthentication. Cette ligne peut être commentée avec un # au début de la ligne. Décommentez la ligne en supprimant le #, et fixez la valeur à no. Cela désactivera votre capacité à vous connecter via SSH en utilisant les mots de passe de compte :

      /etc/ssh/sshd_config

      . . .
      PasswordAuthentication no
      . . .
      

      Sauvegardez et fermez le fichier lorsque vous avez terminé en appuyant sur CTRL+X, puis Y pour confirmer la sauvegarde du fichier, et enfin ENTER pour quitter nano. Pour activer ces changements de manière effective, nous devons redémarrer le service sshd :

      • sudo systemctl restart ssh

      Par précaution, ouvrez une nouvelle fenêtre de terminal et vérifiez que le service SSH fonctionne correctement avant de fermer votre session actuelle :

      Une fois que vous avez vérifié que votre service SSH fonctionne correctement, vous pouvez fermer en toute sécurité toutes les sessions de serveur en cours.

      Le démon SSH sur votre serveur Ubuntu ne répond plus qu’aux authentifications basées sur des clés SSH. Les connexions basées sur un mot de passe ont été désactivées.

      Conclusion

      Vous devriez maintenant avoir une authentification basée sur une clé SSH configurée sur votre serveur, vous permettant de vous connecter sans fournir de mot de passe de compte.

      Si vous souhaitez en savoir plus sur SSH, consultez notre Guide des fondamentaux SSH.



      Source link