Procédure

1. Démarrer le démon sshd dans la session en cours et le configurer pour qu'il démarre automatiquement au moment du démarrage :

   # systemctl start sshd
   # systemctl enable sshd

2. Pour spécifier des adresses différentes des adresses par défaut 0.0.0.0 (IPv4) ou :: (IPv6) pour la directive ListenAddress dans le fichier de configuration /etc/ssh/sshd_config et pour utiliser une configuration réseau dynamique plus lente, ajoutez la dépendance de l'unité cible network-online.target au fichier d'unité sshd.service. Pour ce faire, créez le fichier /etc/systemd/system/sshd.service.d/local.conf avec le contenu suivant :

   [Unit]
   Wants=network-online.target
   After=network-online.target

3. Vérifiez que les paramètres du serveur OpenSSH dans le fichier de configuration /etc/ssh/sshd_config répondent aux exigences de votre scénario.

4. Vous pouvez également modifier le message de bienvenue que votre serveur OpenSSH affiche avant qu'un client ne s'authentifie en éditant le fichier /etc/issue, par exemple :

   Welcome to ssh-server.example.com
   Warning: By accessing this server, you agree to the referenced terms and conditions.

   Assurez-vous que l'option Banner n'est pas commentée dans /etc/ssh/sshd_config et que sa valeur contient /etc/issue:

   # less /etc/ssh/sshd_config | grep Banner
   Banner /etc/issue

   Notez que pour modifier le message affiché après une connexion réussie, vous devez éditer le fichier /etc/motd sur le serveur. Voir la page de manuel pam_motd pour plus d'informations.

5. Rechargez la configuration de systemd et redémarrez sshd pour appliquer les changements :

   # systemctl daemon-reload
   # systemctl restart sshd

Vérification

1. Vérifiez que le démon sshd est en cours d'exécution :

   # systemctl status sshd
   ● sshd.service - OpenSSH server daemon
      Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
      Active: active (running) since Mon 2019-11-18 14:59:58 CET; 6min ago
        Docs: man:sshd(8)
              man:sshd_config(5)
    Main PID: 1149 (sshd)
       Tasks: 1 (limit: 11491)
      Memory: 1.9M
      CGroup: /system.slice/sshd.service
              └─1149 /usr/sbin/sshd -D -oCiphers=aes128-ctr,aes256-ctr,aes128-cbc,aes256-cbc -oMACs=hmac-sha2-256,>
   
   Nov 18 14:59:58 ssh-server-example.com systemd[1]: Starting OpenSSH server daemon...
   Nov 18 14:59:58 ssh-server-example.com sshd[1149]: Server listening on 0.0.0.0 port 22.
   Nov 18 14:59:58 ssh-server-example.com sshd[1149]: Server listening on :: port 22.
   Nov 18 14:59:58 ssh-server-example.com systemd[1]: Started OpenSSH server daemon.

2. Connectez-vous au serveur SSH avec un client SSH.

   # ssh user@ssh-server-example.com
   ECDSA key fingerprint is SHA256:dXbaS0RG/UzlTTku8GtXSz0S1++lPegSy31v3L/FAEc.
   Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
   Warning: Permanently added 'ssh-server-example.com' (ECDSA) to the list of known hosts.
   
   user@ssh-server-example.com's password:

Procédure

1. Ouvrez la configuration de /etc/ssh/sshd_config dans un éditeur de texte, par exemple :

   # vi /etc/ssh/sshd_config

2. Remplacer l'option PasswordAuthentication par no:

   PasswordAuthentication no

   Sur un système autre qu'une nouvelle installation par défaut, vérifiez que PubkeyAuthentication no n'a pas été défini et que la directive KbdInteractiveAuthentication est définie sur no. Si vous êtes connecté à distance, sans utiliser la console ou l'accès hors bande, testez le processus de connexion par clé avant de désactiver l'authentification par mot de passe.

3. Pour utiliser l'authentification par clé avec les répertoires personnels montés sur NFS, activez le booléen SELinux use_nfs_home_dirs:

   # setsebool -P use_nfs_home_dirs 1

4. Rechargez le démon sshd pour appliquer les modifications :

   # systemctl reload sshd

Procédure

1. Pour générer une paire de clés ECDSA pour la version 2 du protocole SSH :

   $ ssh-keygen -t ecdsa
   Generating public/private ecdsa key pair.
   Enter file in which to save the key (/home/joesec/.ssh/id_ecdsa):
   Enter passphrase (empty for no passphrase):
   Enter same passphrase again:
   Your identification has been saved in /home/joesec/.ssh/id_ecdsa.
   Your public key has been saved in /home/joesec/.ssh/id_ecdsa.pub.
   The key fingerprint is:
   SHA256:Q/x+qms4j7PCQ0qFd09iZEFHA+SqwBKRNaU72oZfaCI joesec@localhost.example.com
   The key's randomart image is:
   +---[ECDSA 256]---+
   |.oo..o=++        |
   |.. o .oo .       |
   |. .. o. o        |
   |....o.+...       |
   |o.oo.o +S .      |
   |.=.+.   .o       |
   |E.*+.  .  . .    |
   |.=..+ +..  o     |
   |  .  oo*+o.      |
   +----[SHA256]-----+

   Vous pouvez également générer une paire de clés RSA en utilisant l'option -t rsa avec la commande ssh-keygen ou une paire de clés Ed25519 en entrant la commande ssh-keygen -t ed25519.

2. Pour copier la clé publique sur une machine distante :

   $ ssh-copy-id joesec@ssh-server-example.com
   /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
   joesec@ssh-server-example.com's password:
   ...
   Number of key(s) added: 1
   
   Now try logging into the machine, with: "ssh 'joesec@ssh-server-example.com'" and check to make sure that only the key(s) you wanted were added.

   Si vous n'utilisez pas le programme ssh-agent dans votre session, la commande précédente copie la clé publique ~/.ssh/id*.pub la plus récemment modifiée si elle n'est pas encore installée. Pour spécifier un autre fichier de clé publique ou pour donner la priorité aux clés contenues dans les fichiers par rapport aux clés mises en mémoire par ssh-agent, utilisez la commande ssh-copy-id avec l'option -i.

Vérification

1. Connectez-vous au serveur OpenSSH sans fournir de mot de passe :

   $ ssh joesec@ssh-server-example.com
   Welcome message.
   ...
   Last login: Mon Nov 18 18:28:42 2019 from ::1

Procédure

1. Dresser la liste de toutes les clés fournies par le module PKCS #11 d'OpenSC, y compris leurs URI PKCS #11, et enregistrer le résultat dans le fichier keys.pub:

   $ ssh-keygen -D pkcs11: > keys.pub
   $ ssh-keygen -D pkcs11:
   ssh-rsa AAAAB3NzaC1yc2E...KKZMzcQZzx pkcs11:id=%02;object=SIGN%20pubkey;token=SSH%20key;manufacturer=piv_II?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so
   ecdsa-sha2-nistp256 AAA...J0hkYnnsM= pkcs11:id=%01;object=PIV%20AUTH%20pubkey;token=SSH%20key;manufacturer=piv_II?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so

2. Pour permettre l'authentification à l'aide d'une carte à puce sur un serveur distant (example.com), transférez la clé publique sur le serveur distant. Utilisez la commande ssh-copy-id avec keys.pub créé à l'étape précédente :

   $ ssh-copy-id -f -i keys.pub username@example.com

3. Pour vous connecter à example.com à l'aide de la clé ECDSA issue de la commande ssh-keygen -D à l'étape 1, vous pouvez utiliser uniquement un sous-ensemble de l'URI, qui fait référence de manière unique à votre clé, par exemple :

   $ ssh -i "pkcs11:id=%01?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so" example.com
   Enter PIN for 'SSH key':
   [example.com] $

4. Vous pouvez utiliser la même chaîne URI dans le fichier ~/.ssh/config pour rendre la configuration permanente :

   $ cat ~/.ssh/config
   IdentityFile "pkcs11:id=%01?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so"
   $ ssh example.com
   Enter PIN for 'SSH key':
   [example.com] $

   Comme OpenSSH utilise le wrapper p11-kit-proxy et que le module OpenSC PKCS #11 est enregistré dans le kit PKCS#11, vous pouvez simplifier les commandes précédentes :

   $ ssh -i "pkcs11:id=%01" example.com
   Enter PIN for 'SSH key':
   [example.com] $

Procédure

1. Définissez l'hôte de saut en modifiant le fichier ~/.ssh/config sur votre système local, par exemple :

   Host jump-server1
     HostName jump1.example.com

   • Le paramètre Host définit un nom ou un alias pour l'hôte que vous pouvez utiliser dans les commandes ssh. La valeur peut correspondre au nom réel de l'hôte, mais peut également être une chaîne quelconque.
   • Le paramètre HostName définit le nom d'hôte ou l'adresse IP de l'hôte de saut.

2. Ajoutez la configuration de saut du serveur distant avec la directive ProxyJump au fichier ~/.ssh/config de votre système local, par exemple :

   Host remote-server
     HostName remote1.example.com
     ProxyJump jump-server1

3. Utilisez votre système local pour vous connecter au serveur distant via le serveur de saut :

   $ ssh remote-server

   La commande précédente est équivalente à la commande ssh -J jump-server1 remote-server si vous omettez les étapes de configuration 1 et 2.

Procédure

1. Facultatif : Vérifiez que vous pouvez utiliser la clé pour vous authentifier auprès de l'hôte distant :

   1. Connectez-vous à l'hôte distant à l'aide de SSH :

      $ ssh example.user1@198.51.100.1 hostname

   2. Saisissez la phrase de passe que vous avez définie lors de la création de la clé pour autoriser l'accès à la clé privée.

      $ ssh example.user1@198.51.100.1 hostname
       host.example.com

2. Démarrer le site ssh-agent.

   $ eval $(ssh-agent)
   Agent pid 20062

3. Ajouter la clé à ssh-agent.

   $ ssh-add ~/.ssh/id_rsa
   Enter passphrase for ~/.ssh/id_rsa:
   Identity added: ~/.ssh/id_rsa (example.user0@198.51.100.12)

Procédure

1. Copiez l'exemple de playbook pour le rôle de système sshd:

   # cp /usr/share/doc/rhel-system-roles/sshd/example-root-login-playbook.yml path/custom-playbook.yml

2. Ouvrez le playbook copié en utilisant un éditeur de texte, par exemple :

   # vim path/custom-playbook.yml
   
   ---
   - hosts: all
     tasks:
     - name: Configure sshd to prevent root and password login except from particular subnet
       include_role:
         name: rhel-system-roles.sshd
       vars:
         sshd:
           # root login and password login is enabled only from a particular subnet
           PermitRootLogin: no
           PasswordAuthentication: no
           Match:
           - Condition: "Address 192.0.2.0/24"
             PermitRootLogin: yes
             PasswordAuthentication: yes

   Le playbook configure le nœud géré en tant que serveur SSH configuré de telle sorte que :

   • et le login de l'utilisateur root est désactivé
   • et root n'est possible qu'à partir du sous-réseau 192.0.2.0/24

   Vous pouvez modifier les variables en fonction de vos préférences. Pour plus de détails, voir Variables de rôle du système du serveur SSH.

3. Facultatif : Vérifier la syntaxe du playbook.

   # ansible-playbook --syntax-check path/custom-playbook.yml

4. Exécutez le playbook sur votre fichier d'inventaire :

   # ansible-playbook -i inventory_file path/custom-playbook.yml
   
   ...
   
   PLAY RECAP
   **************************************************
   
   localhost : ok=12 changed=2 unreachable=0 failed=0
   skipped=10 rescued=0 ignored=0

Vérification

1. Connectez-vous au serveur SSH :

   $ ssh user1@10.1.1.1

   Où ?

   • user1 est un utilisateur du serveur SSH.
   • 10.1.1.1 est l'adresse IP du serveur SSH.

2. Vérifiez le contenu du fichier sshd_config sur le serveur SSH :

   $ cat /etc/ssh/sshd_config.d/00-ansible_system_role.conf
   #
   # Ansible managed
   #
   PasswordAuthentication no
   PermitRootLogin no
   Match Address 192.0.2.0/24
     PasswordAuthentication yes
     PermitRootLogin yes

3. Vérifiez que vous pouvez vous connecter au serveur en tant que root depuis le sous-réseau 192.0.2.0/24:

   1. Déterminez votre adresse IP :

      $ hostname -I
      192.0.2.1

      Si l'adresse IP se situe dans la plage 192.0.2.1 - 192.0.2.254, vous pouvez vous connecter au serveur.

   2. Se connecter au serveur en tant que root:

      $ ssh root@10.1.1.1

Procédure

1. Créez un nouveau fichier playbook.yml avec le contenu suivant :

   ---
   - hosts: all
     tasks:
     - name: "Configure ssh clients"
       include_role:
         name: rhel-system-roles.ssh
       vars:
         ssh_user: root
         ssh:
           Compression: true
           GSSAPIAuthentication: no
           ControlMaster: auto
           ControlPath: ~/.ssh/.cm%C
           Host:
             - Condition: example
               Hostname: example.com
               User: user1
         ssh_ForwardX11: no

   Ce playbook configure les préférences du client SSH de l'utilisateur root sur les nœuds gérés avec les configurations suivantes :

   • La compression est activée.
   • Le multiplexage ControlMaster est réglé sur auto.
   • L'alias example pour se connecter à l'hôte example.com est user1.
   • L'alias example l'alias de l'hôte est créé, ce qui représente une connexion à l'hôte example.com hôte avec le user1 nom d'utilisateur.
   • Le transfert X11 est désactivé.

   En option, vous pouvez modifier ces variables selon vos préférences. Pour plus de détails, voir ssh System Role variables.

2. Facultatif : Vérifier la syntaxe du playbook.

   # ansible-playbook --syntax-check path/custom-playbook.yml

3. Exécutez le playbook sur votre fichier d'inventaire :

   # ansible-playbook -i inventory_file path/custom-playbook.yml

Procédure

1. Ajoutez un extrait de configuration avec la variable sshd_config_file au playbook :

   ---
   - hosts: all
     tasks:
     - name: <Configure sshd to accept some useful environment variables>
       include_role:
         name: rhel-system-roles.sshd
       vars:
         sshd_config_file: /etc/ssh/sshd_config.d/<42-my-application>.conf
         sshd:
           # Environment variables to accept
           AcceptEnv:
             LANG
             LS_COLORS
             EDITOR

   Dans la variable sshd_config_file, définissez le fichier .conf dans lequel le rôle de système sshd écrit les options de configuration.

   Utilisez un préfixe à deux chiffres, par exemple 42- pour spécifier l'ordre dans lequel les fichiers de configuration seront appliqués.

   Lorsque vous appliquez le playbook à l'inventaire, le rôle ajoute les options de configuration suivantes au fichier défini par la variable sshd_config_file.

   # Ansible managed
   #
   AcceptEnv LANG LS_COLORS EDITOR

Procédure

1. Générez une clé privée pour votre autorité de certification. Par exemple, la commande suivante crée une clé ECDSA (Elliptic Curve Digital Signature Algorithm) de 256 bits :

   $ openssl genpkey -algorithm ec -pkeyopt ec_paramgen_curve:P-256 -out <ca.key>

   La durée du processus de génération des clés dépend du matériel et de l'entropie de l'hôte, de l'algorithme sélectionné et de la longueur de la clé.

2. Créez un certificat signé à l'aide de la clé privée générée dans la commande précédente :

   $ openssl req -key <ca.key> -new -x509 -days 3650 -addext keyUsage=critical,keyCertSign,cRLSign -subj "/CN=<Example CA>" -out <ca.crt>

   Le fichier ca.crt généré est un certificat d'autorité de certification auto-signé que vous pouvez utiliser pour signer d'autres certificats pendant dix ans. Dans le cas d'une autorité de certification privée, vous pouvez remplacer <Example CA> par n'importe quelle chaîne de caractères comme nom commun (CN).

3. Définissez des autorisations sécurisées pour la clé privée de votre autorité de certification, par exemple :

   # chown <root>:<root> <ca.key>
   # chmod 600 <ca.key>

Vérification

1. Créez une demande de signature de certificat (CSR) et utilisez votre autorité de certification pour signer la demande. L'autorité de certification doit réussir à créer un certificat sur la base de la RSC, par exemple :

   $ openssl x509 -req -in <client-cert.csr> -CA <ca.crt> -CAkey <ca.key> -CAcreateserial -days 365 -extfile <openssl.cnf> -extensions <client-cert> -out <client-cert.crt>
   Signature ok
   subject=C = US, O = Example Organization, CN = server.example.com
   Getting CA Private Key

   Voir Section 3.5, « Utilisation d'une autorité de certification privée pour émettre des certificats pour les CSR avec OpenSSL » pour plus d'informations.

2. Affichez les informations de base sur votre AC auto-signée :

   $ openssl x509 -in <ca.crt> -text -noout
   Certificate:
   …
           X509v3 extensions:
               …
               X509v3 Basic Constraints: critical
                   CA:TRUE
               X509v3 Key Usage: critical
                   Certificate Sign, CRL Sign
   …

3. Vérifier la cohérence de la clé privée :

   $ openssl pkey -check -in <ca.key>
   Key is valid
   -----BEGIN PRIVATE KEY-----
   MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgcagSaTEBn74xZAwO
   18wRpXoCVC9vcPki7WlT+gnmCI+hRANCAARb9NxIvkaVjFhOoZbGp/HtIQxbM78E
   lwbDP0BI624xBJ8gK68ogSaq2x4SdezFdV1gNeKScDcU+Pj2pELldmdF
   -----END PRIVATE KEY-----

Procédure

1. Générez une clé privée sur votre système serveur, par exemple :

   $ openssl genpkey -algorithm ec -pkeyopt ec_paramgen_curve:P-256 -out <server-private.key>

2. Facultatif : Utilisez un éditeur de texte de votre choix pour préparer un fichier de configuration qui simplifie la création de votre CSR, par exemple :

   $ vim <example_server.cnf>
   [server-cert]
   keyUsage = critical, digitalSignature, keyEncipherment, keyAgreement
   extendedKeyUsage = serverAuth
   subjectAltName = @alt_name
   
   [req]
   distinguished_name = dn
   prompt = no
   
   [dn]
   C = <US>
   O = <Example Organization>
   CN = <server.example.com>
   
   [alt_name]
   DNS.1 = <example.com>
   DNS.2 = <server.example.com>
   IP.1 = <192.168.0.1>
   IP.2 = <::1>
   IP.3 = <127.0.0.1>

   L'option extendedKeyUsage = serverAuth limite l'utilisation d'un certificat.

3. Créez une RSC à l'aide de la clé privée que vous avez créée précédemment :

   $ openssl req -key <server-private.key> -config <example_server.cnf> -new -out <server-cert.csr>

   Si vous omettez l'option -config, l'utilitaire req vous demande des informations supplémentaires, par exemple :

   You are about to be asked to enter information that will be incorporated
   into your certificate request.
   What you are about to enter is what is called a Distinguished Name or a DN.
   There are quite a few fields but you can leave some blank
   For some fields there will be a default value,
   If you enter '.', the field will be left blank.
   -----
   Country Name (2 letter code) [XX]: <US>
   State or Province Name (full name) []: <Washington>
   Locality Name (eg, city) [Default City]: <Seattle>
   Organization Name (eg, company) [Default Company Ltd]: <Example Organization>
   Organizational Unit Name (eg, section) []:
   Common Name (eg, your name or your server's hostname) []: <server.example.com>
   Email Address []: <server@example.com>

Vérification

1. Après avoir obtenu le certificat demandé auprès de l'autorité de certification, vérifiez que les parties lisibles par l'homme du certificat correspondent à vos exigences, par exemple :

   $ openssl x509 -text -noout -in <server-cert.crt>
   Certificate:
   …
           Issuer: CN = Example CA
           Validity
               Not Before: Feb  2 20:27:29 2023 GMT
               Not After : Feb  2 20:27:29 2024 GMT
           Subject: C = US, O = Example Organization, CN = server.example.com
           Subject Public Key Info:
               Public Key Algorithm: id-ecPublicKey
                   Public-Key: (256 bit)
   …
           X509v3 extensions:
               X509v3 Key Usage: critical
                   Digital Signature, Key Encipherment, Key Agreement
               X509v3 Extended Key Usage:
                   TLS Web Server Authentication
               X509v3 Subject Alternative Name:
                   DNS:example.com, DNS:server.example.com, IP Address:192.168.0.1, IP
   …

Procédure

1. Générez une clé privée sur votre système client, par exemple :

   $ openssl genpkey -algorithm ec -pkeyopt ec_paramgen_curve:P-256 -out <client-private.key>

2. Facultatif : Utilisez un éditeur de texte de votre choix pour préparer un fichier de configuration qui simplifie la création de votre CSR, par exemple :

   $ vim <example_client.cnf>
   [client-cert]
   keyUsage = critical, digitalSignature, keyEncipherment
   extendedKeyUsage = clientAuth
   subjectAltName = @alt_name
   
   [req]
   distinguished_name = dn
   prompt = no
   
   [dn]
   CN = <client.example.com>
   
   [clnt_alt_name]
   email= <client@example.com>

   L'option extendedKeyUsage = clientAuth limite l'utilisation d'un certificat.

3. Créez une RSC à l'aide de la clé privée que vous avez créée précédemment :

   $ openssl req -key <client-private.key> -config <example_client.cnf> -new -out <client-cert.csr>

   Si vous omettez l'option -config, l'utilitaire req vous demande des informations supplémentaires, par exemple :

   You are about to be asked to enter information that will be incorporated
   into your certificate request.
   …
   Common Name (eg, your name or your server's hostname) []: <client.example.com>
   Email Address []: <client@example.com>

Vérification

1. Vérifiez que les parties du certificat lisibles par l'homme correspondent à vos exigences, par exemple :

   $ openssl x509 -text -noout -in <client-cert.crt>
   Certificate:
   …
               X509v3 Extended Key Usage:
                   TLS Web Client Authentication
               X509v3 Subject Alternative Name:
                   email:client@example.com
   …

Procédure

1. Facultatif : Utilisez un éditeur de texte de votre choix pour préparer un fichier de configuration OpenSSL afin d'ajouter des extensions aux certificats, par exemple :

   $ vim <openssl.cnf>
   [server-cert]
   extendedKeyUsage = serverAuth
   
   [client-cert]
   extendedKeyUsage = clientAuth

2. Utilisez l'utilitaire x509 pour créer un certificat basé sur une CSR, par exemple :

   $ openssl x509 -req -in <server-cert.csr> -CA <ca.crt> -CAkey <ca.key> -days 365 -extfile <openssl.cnf> -extensions <server-cert> -out <server-cert.crt>
   Signature ok
   subject=C = US, O = Example Organization, CN = server.example.com
   Getting CA Private Key

Procédure

1. Générez une clé privée pour votre autorité de certification. Par exemple, la commande suivante crée une clé ECDSA (Elliptic Curve Digital Signature Algorithm) de 256 bits :

   $ certtool --generate-privkey --sec-param High --key-type=ecdsa --outfile <ca.key>

   La durée du processus de génération des clés dépend du matériel et de l'entropie de l'hôte, de l'algorithme sélectionné et de la longueur de la clé.

2. Créer un fichier modèle pour un certificat.

   1. Créez un fichier avec votre éditeur de texte préféré, par exemple vi :

      $ vi <ca.cfg>

   2. Modifiez le fichier pour y inclure les détails nécessaires à la certification :

      organization = "Example Inc."
      state = "Example"
      country = EX
      cn = "Example CA"
      serial = 007
      expiration_days = 365
      ca
      cert_signing_key
      crl_signing_key

3. Créez un certificat signé à l'aide de la clé privée générée à l'étape 1 :

   Le fichier <ca.crt> généré est un certificat CA auto-signé que vous pouvez utiliser pour signer d'autres certificats pendant un an. Le fichier <ca.crt> est la clé publique (certificat). Le fichier chargé <ca.key> est la clé privée. Vous devez conserver ce fichier dans un endroit sûr.

   $ certtool --generate-self-signed --load-privkey <ca.key> --template <ca.cfg> --outfile <ca.crt>

4. Définissez des autorisations sécurisées pour la clé privée de votre autorité de certification, par exemple :

   # chown <root>:<root> <ca.key>
   # chmod 600 <ca.key>

Vérification

1. Affichez les informations de base sur votre AC auto-signée :

   $ certtool --certificate-info --infile <ca.crt>
   Certificate:
   …
       	X509v3 extensions:
           	…
           	X509v3 Basic Constraints: critical
               	CA:TRUE
           	X509v3 Key Usage: critical
               	Certificate Sign, CRL Sign

2. Créez une demande de signature de certificat (CSR) et utilisez votre autorité de certification pour signer la demande. L'autorité de certification doit réussir à créer un certificat sur la base de la RSC, par exemple :

   1. Générez une clé privée pour votre autorité de certification :

      $ certtool --generate-privkey --outfile <example-server.key>

   2. Créez un fichier avec votre éditeur de texte préféré, par exemple vi :

      $ vi <example-server.cfg>

   3. Modifiez le fichier pour y inclure les détails nécessaires à la certification :

      signing_key
      encryption_key
      key_agreement
      
      tls_www_server
      
      country = "US"
      organization = "Example Organization"
      cn = "server.example.com"
      
      dns_name = "example.com"
      dns_name = "server.example.com"
      ip_address = "192.168.0.1"
      ip_address = "::1"
      ip_address = "127.0.0.1"

   4. Générer une demande avec la clé privée créée précédemment

      $ certtool --generate-request --load-privkey <example-server.key> --template <example-server.cfg> --outfile <example-server.crq>

   5. Générer le certificat et le signer avec la clé privée de l'autorité de certification :

      $ certtool --generate-certificate --load-request <example-server.crq> --load-privkey <example-server.key> --load-ca-certificate <ca.crt> --load-ca-privkey <ca.key> --outfile <example-server.crt>

      Ressources supplémentaires

      • certtool(1) et trust(1) pages de manuel

Procédure

1. Générez une clé privée sur votre système serveur, par exemple :

   $ certtool --generate-privkey --sec-param High --outfile <example-server.key>

2. Facultatif : Utilisez un éditeur de texte de votre choix pour préparer un fichier de configuration qui simplifie la création de votre CSR, par exemple :

   $ vim <example_server.cnf>
   signing_key
   encryption_key
   key_agreement
   
   tls_www_server
   
   country = "US"
   organization = "Example Organization"
   cn = "server.example.com"
   
   dns_name = "example.com"
   dns_name = "server.example.com"
   ip_address = "192.168.0.1"
   ip_address = "::1"
   ip_address = "127.0.0.1"

3. Créez une RSC à l'aide de la clé privée que vous avez créée précédemment :

   $ certtool --generate-request --template <example-server.cfg> --load-privkey <example-server.key> --outfile <example-server.crq>

   Si vous omettez l'option --template, l'utilitaire certool vous demande des informations supplémentaires, par exemple :

   You are about to be asked to enter information that will be incorporated
   into your certificate request.
   What you are about to enter is what is called a Distinguished Name or a DN.
   There are quite a few fields but you can leave some blank
   For some fields there will be a default value,
   If you enter '.', the field will be left blank.
   -----
   Generating a PKCS #10 certificate request...
   Country name (2 chars): <US>
   State or province name: <Washington>
   Locality name: <Seattle>
   Organization name: <Example Organization>
   Organizational unit name:
   Common name: <server.example.com>

Vérification

1. Après avoir obtenu le certificat demandé auprès de l'autorité de certification, vérifiez que les parties lisibles par l'homme du certificat correspondent à vos exigences, par exemple :

   $ certtool --certificate-info --infile <example-server.crt>
   Certificate:
   …
           Issuer: CN = Example CA
           Validity
               Not Before: Feb  2 20:27:29 2023 GMT
               Not After : Feb  2 20:27:29 2024 GMT
           Subject: C = US, O = Example Organization, CN = server.example.com
           Subject Public Key Info:
               Public Key Algorithm: id-ecPublicKey
                   Public-Key: (256 bit)
   …
           X509v3 extensions:
               X509v3 Key Usage: critical
                   Digital Signature, Key Encipherment, Key Agreement
               X509v3 Extended Key Usage:
                   TLS Web Server Authentication
               X509v3 Subject Alternative Name:
                   DNS:example.com, DNS:server.example.com, IP Address:192.168.0.1, IP
   …

Procédure

1. Générez une clé privée sur votre système client, par exemple :

   $ certtool --generate-privkey --sec-param High --outfile <example-client.key>

2. Facultatif : Utilisez un éditeur de texte de votre choix pour préparer un fichier de configuration qui simplifie la création de votre CSR, par exemple :

   $ vim <example_client.cnf>
   signing_key
   encryption_key
   
   tls_www_client
   
   cn = "client.example.com"
   email = "client@example.com"

3. Créez une RSC à l'aide de la clé privée que vous avez créée précédemment :

   $ certtool --generate-request --template <example-client.cfg> --load-privkey <example-client.key> --outfile <example-client.crq>

   Si vous omettez l'option --template, l'utilitaire certtool vous demande des informations supplémentaires, par exemple :

   Generating a PKCS #10 certificate request...
   Country name (2 chars): <US>
   State or province name: <Washington>
   Locality name: <Seattle>
   Organization name: <Example Organization>
   Organizational unit name:
   Common name: <server.example.com>

Vérification

1. Vérifiez que les parties du certificat lisibles par l'homme correspondent à vos exigences, par exemple :

   $ certtool --certificate-info --infile <example-client.crt>
   Certificate:
   …
               X509v3 Extended Key Usage:
                   TLS Web Client Authentication
               X509v3 Subject Alternative Name:
                   email:client@example.com
   …

Procédure

1. Facultatif : Utilisez un éditeur de texte de votre choix pour préparer un fichier de configuration GnuTLS afin d'ajouter des extensions aux certificats, par exemple :

   $ vi <server-extensions.cfg>
   honor_crq_extensions
   ocsp_uri = "http://ocsp.example.com"

2. Utilisez l'utilitaire certtool pour créer un certificat basé sur une CSR, par exemple :

   $ certtool --generate-certificate --load-request <example-server.crq> --load-ca-privkey <ca.key> --load-ca-certificate <ca.crt> --template <server-extensions.cfg> --outfile <example-server.crt>

Procédure

1. Pour ajouter un certificat au format simple PEM ou DER à la liste des autorités de certification approuvées par le système, copiez le fichier de certificat dans le répertoire /usr/share/pki/ca-trust-source/anchors/ ou /etc/pki/ca-trust/source/anchors/, par exemple :

   # cp ~/certificate-trust-examples/Cert-trust-test-ca.pem /usr/share/pki/ca-trust-source/anchors/

2. Pour mettre à jour la configuration du magasin de confiance à l'échelle du système, utilisez la commande update-ca-trust:

   # update-ca-trust

Procédure

1. Installez les paquets libreswan:

   # dnf install libreswan

2. Si vous réinstallez Libreswan, supprimez ses anciens fichiers de base de données et créez une nouvelle base de données :

   # systemctl stop ipsec
   # rm /var/lib/ipsec/nss/*db
   # ipsec initnss

3. Démarrez le service ipsec et activez le service pour qu'il soit démarré automatiquement au démarrage :

   # systemctl enable ipsec --now

4. Configurez le pare-feu pour qu'il autorise les ports 500 et 4500/UDP pour les protocoles IKE, ESP et AH en ajoutant le service ipsec:

   # firewall-cmd --add-service="ipsec"
   # firewall-cmd --runtime-to-permanent

Procédure

1. Générer une paire de clés RSA brutes sur chaque hôte :

   # ipsec newhostkey

2. L'étape précédente a renvoyé la clé générée à ckaid. Utilisez cette ckaid avec la commande suivante sur left, par exemple :

   # ipsec showhostkey --left --ckaid 2d3ea57b61c9419dfd6cf43a1eb6cb306c0e857d

   La sortie de la commande précédente a généré la ligne leftrsasigkey= nécessaire à la configuration. Faites de même sur le second hôte (right) :

   # ipsec showhostkey --right --ckaid a9e1f6ce9ecd3608c24e8f701318383f41798f03

3. Dans le répertoire /etc/ipsec.d/, créez un nouveau fichier my_host-to-host.conf. Inscrivez dans le nouveau fichier les clés d'hôte RSA provenant de la sortie des commandes ipsec showhostkey de l'étape précédente. Par exemple :

   conn mytunnel
       leftid=@west
       left=192.1.2.23
       leftrsasigkey=0sAQOrlo+hOafUZDlCQmXFrje/oZm [...] W2n417C/4urYHQkCvuIQ==
       rightid=@east
       right=192.1.2.45
       rightrsasigkey=0sAQO3fwC6nSSGgt64DWiYZzuHbc4 [...] D/v8t5YTQ==
       authby=rsasig

4. Après l'importation des clés, redémarrez le service ipsec:

   # systemctl restart ipsec

5. Charger la connexion :

   # ipsec auto --add mytunnel

6. Établir le tunnel :

   # ipsec auto --up mytunnel

7. Pour démarrer automatiquement le tunnel lorsque le service ipsec est démarré, ajoutez la ligne suivante à la définition de la connexion :

   auto=start

Procédure

1. Copiez le fichier contenant la configuration de votre VPN hôte à hôte dans un nouveau fichier, par exemple :

   # cp /etc/ipsec.d/my_host-to-host.conf /etc/ipsec.d/my_site-to-site.conf

2. Ajoutez la configuration du sous-réseau au fichier créé à l'étape précédente, par exemple :

   conn mysubnet
        also=mytunnel
        leftsubnet=192.0.1.0/24
        rightsubnet=192.0.2.0/24
        auto=start
   
   conn mysubnet6
        also=mytunnel
        leftsubnet=2001:db8:0:1::/64
        rightsubnet=2001:db8:0:2::/64
        auto=start
   
   # the following part of the configuration file is the same for both host-to-host and site-to-site connections:
   
   conn mytunnel
       leftid=@west
       left=192.1.2.23
       leftrsasigkey=0sAQOrlo+hOafUZDlCQmXFrje/oZm [...] W2n417C/4urYHQkCvuIQ==
       rightid=@east
       right=192.1.2.45
       rightrsasigkey=0sAQO3fwC6nSSGgt64DWiYZzuHbc4 [...] D/v8t5YTQ==
       authby=rsasig

Procédure

1. Sur chaque nœud, importer les fichiers PKCS #12. Cette étape nécessite le mot de passe utilisé pour générer les fichiers PKCS #12 :

   # ipsec import nodeXXX.p12

2. Créez les trois définitions de connexion suivantes pour les profils IPsec required (privé), IPsec optional (privé ou clair) et No IPsec (clair) :

   # cat /etc/ipsec.d/mesh.conf
   conn clear
   	auto=ondemand
   	type=passthrough
   	authby=never
   	left=%defaultroute
   	right=%group
   
   conn private
   	auto=ondemand
   	type=transport
   	authby=rsasig
   	failureshunt=drop
   	negotiationshunt=drop
   	# left
   	left=%defaultroute
   	leftcert=nodeXXXX
   	leftid=%fromcert
           leftrsasigkey=%cert
   	# right
   	rightrsasigkey=%cert
   	rightid=%fromcert
   	right=%opportunisticgroup
   
   conn private-or-clear
   	auto=ondemand
   	type=transport
   	authby=rsasig
   	failureshunt=passthrough
   	negotiationshunt=passthrough
   	# left
   	left=%defaultroute
   	leftcert=nodeXXXX
   	leftid=%fromcert
           leftrsasigkey=%cert
   	# right
   	rightrsasigkey=%cert
   	rightid=%fromcert
   	right=%opportunisticgroup

3. Ajoutez l'adresse IP du réseau dans la catégorie appropriée. Par exemple, si tous les nœuds résident dans le réseau 10.15.0.0/16 et que tous les nœuds doivent utiliser le cryptage IPsec :

   # echo "10.15.0.0/16" >> /etc/ipsec.d/policies/private

4. Pour permettre à certains nœuds, par exemple 10.15.34.0/24, de fonctionner avec et sans IPsec, ajoutez ces nœuds au groupe privé ou clair en utilisant :

   # echo "10.15.34.0/24" >> /etc/ipsec.d/policies/private-or-clear

5. Pour définir un hôte, par exemple 10.15.1.2, qui n'est pas capable d'IPsec dans le groupe clair, utilisez :

   # echo "10.15.1.2/32" >> /etc/ipsec.d/policies/clear

   Les fichiers du répertoire /etc/ipsec.d/policies peuvent être créés à partir d'un modèle pour chaque nouveau nœud, ou peuvent être approvisionnés à l'aide de Puppet ou Ansible.

   Notez que chaque nœud a la même liste d'exceptions ou des attentes différentes en matière de flux de trafic. Deux nœuds peuvent donc ne pas être en mesure de communiquer parce que l'un d'eux nécessite IPsec et que l'autre ne peut pas l'utiliser.

6. Redémarrez le nœud pour l'ajouter au maillage configuré :

   # systemctl restart ipsec

7. Une fois l'ajout de nœuds terminé, une commande ping suffit pour ouvrir un tunnel IPsec. Pour savoir quels tunnels un nœud a ouvert :

   # ipsec trafficstatus

Procédure

1. Installez les paquets libreswan:

   # dnf install libreswan

2. Si vous réinstallez Libreswan, supprimez son ancienne base de données NSS :

   # systemctl stop ipsec
   
   # rm /var/lib/ipsec/nss/*db

3. Démarrez le service ipsec et activez le service pour qu'il soit démarré automatiquement au démarrage :

   # systemctl enable ipsec --now

4. Configurez le pare-feu pour qu'il autorise les ports 500 et 4500/UDP pour les protocoles IKE, ESP et AH en ajoutant le service ipsec:

   # firewall-cmd --add-service="ipsec"
   # firewall-cmd --runtime-to-permanent

5. Passer le système en mode FIPS :

   # fips-mode-setup --enable

6. Redémarrez votre système pour permettre au noyau de passer en mode FIPS :

   # reboot

Vérification

1. Pour confirmer que Libreswan fonctionne en mode FIPS :

   # ipsec whack --fipsstatus
   000 FIPS mode enabled

2. Il est également possible de vérifier les entrées de l'unité ipsec dans le journal systemd:

   $ journalctl -u ipsec
   ...
   Jan 22 11:26:50 localhost.localdomain pluto[3076]: FIPS Mode: YES

3. Pour connaître les algorithmes disponibles en mode FIPS :

   # ipsec pluto --selftest 2>&1 | head -6
   Initializing NSS using read-write database "sql:/var/lib/ipsec/nss"
   FIPS Mode: YES
   NSS crypto library initialized
   FIPS mode enabled for pluto daemon
   NSS library is running in FIPS mode
   FIPS HMAC integrity support [disabled]

4. Pour interroger les algorithmes désactivés en mode FIPS :

   # ipsec pluto --selftest 2>&1 | grep disabled
   Encryption algorithm CAMELLIA_CTR disabled; not FIPS compliant
   Encryption algorithm CAMELLIA_CBC disabled; not FIPS compliant
   Encryption algorithm NULL disabled; not FIPS compliant
   Encryption algorithm CHACHA20_POLY1305 disabled; not FIPS compliant
   Hash algorithm MD5 disabled; not FIPS compliant
   PRF algorithm HMAC_MD5 disabled; not FIPS compliant
   PRF algorithm AES_XCBC disabled; not FIPS compliant
   Integrity algorithm HMAC_MD5_96 disabled; not FIPS compliant
   Integrity algorithm HMAC_SHA2_256_TRUNCBUG disabled; not FIPS compliant
   Integrity algorithm AES_XCBC_96 disabled; not FIPS compliant
   DH algorithm MODP1536 disabled; not FIPS compliant
   DH algorithm DH31 disabled; not FIPS compliant

5. Pour dresser la liste de tous les algorithmes et chiffrements autorisés en mode FIPS :

   # ipsec pluto --selftest 2>&1 | grep ESP | grep FIPS | sed "s/^.*FIPS//"
   aes_ccm, aes_ccm_c
   aes_ccm_b
   aes_ccm_a
   NSS(CBC)  3des
   NSS(GCM)  aes_gcm, aes_gcm_c
   NSS(GCM)  aes_gcm_b
   NSS(GCM)  aes_gcm_a
   NSS(CTR)  aesctr
   NSS(CBC)  aes
   aes_gmac
   NSS       sha, sha1, sha1_96, hmac_sha1
   NSS       sha512, sha2_512, sha2_512_256, hmac_sha2_512
   NSS       sha384, sha2_384, sha2_384_192, hmac_sha2_384
   NSS       sha2, sha256, sha2_256, sha2_256_128, hmac_sha2_256
   aes_cmac
   null
   NSS(MODP) null, dh0
   NSS(MODP) dh14
   NSS(MODP) dh15
   NSS(MODP) dh16
   NSS(MODP) dh17
   NSS(MODP) dh18
   NSS(ECP)  ecp_256, ecp256
   NSS(ECP)  ecp_384, ecp384
   NSS(ECP)  ecp_521, ecp521

Procédure

1. Activer la protection par mot de passe de la base de données NSS pour Libreswan :

   # certutil -N -d sql:/var/lib/ipsec/nss
   Enter Password or Pin for "NSS Certificate DB":
   Enter a password which will be used to encrypt your keys.
   The password should be at least 8 characters long,
   and should contain at least one non-alphabetic character.
   
   Enter new password:

2. Créez le fichier /etc/ipsec.d/nsspassword contenant le mot de passe que vous avez défini à l'étape précédente, par exemple :

   # cat /etc/ipsec.d/nsspassword
   NSS Certificate DB:MyStrongPasswordHere

   Notez que le fichier nsspassword utilise la syntaxe suivante :

   token_1_name:the_password
   token_2_name:the_password

   Le jeton par défaut du logiciel NSS est NSS Certificate DB. Si votre système fonctionne en mode FIPS, le nom du jeton est NSS FIPS 140-2 Certificate DB.

3. Selon votre scénario, démarrez ou redémarrez le service ipsec après avoir terminé le fichier nsspassword:

   # systemctl restart ipsec

Vérification

1. Vérifiez que le service ipsec fonctionne après avoir ajouté un mot de passe non vide à sa base de données NSS :

   # systemctl status ipsec
   ● ipsec.service - Internet Key Exchange (IKE) Protocol Daemon for IPsec
      Loaded: loaded (/usr/lib/systemd/system/ipsec.service; enabled; vendor preset: disable>
      Active: active (running)...

2. En option, vérifiez que le journal Journal contient des entrées confirmant la réussite de l'initialisation :

   # journalctl -u ipsec
   ...
   pluto[6214]: Initializing NSS using read-write database "sql:/var/lib/ipsec/nss"
   pluto[6214]: NSS Password from file "/etc/ipsec.d/nsspassword" for token "NSS Certificate DB" with length 20 passed to NSS
   pluto[6214]: NSS crypto library initialized
   ...

Procédure

1. Ajoutez l'option suivante au fichier /etc/ipsec.conf dans la section config setup:

   listen-tcp=yes

2. Pour utiliser l'encapsulation TCP comme option de repli lorsque la première tentative via UDP échoue, ajoutez les deux options suivantes à la définition de la connexion du client :

   enable-tcp=fallback
   tcp-remoteport=4500

   Sinon, si vous savez que UDP est bloqué en permanence, utilisez les options suivantes dans la configuration de la connexion du client :

   enable-tcp=yes
   tcp-remoteport=4500

Procédure

1. Modifiez le fichier de configuration Libreswan dans le répertoire /etc/ipsec.d/ de la connexion qui doit utiliser la détection automatique de la prise en charge du délestage matériel ESP.
2. Assurez-vous que le paramètre nic-offload n'est pas défini dans les paramètres de la connexion.

3. Si vous avez supprimé nic-offload, redémarrez le service ipsec:

   # systemctl restart ipsec

1. Affiche les compteurs tx_ipsec et rx_ipsec du périphérique Ethernet utilisé par la connexion IPsec :

   # ethtool -S enp1s0 | egrep "_ipsec"
        tx_ipsec: 10
        rx_ipsec: 10

2. Envoyer du trafic à travers le tunnel IPsec. Par exemple, envoyer un ping à une adresse IP distante :

   # ping -c 5 remote_ip_address

3. Affichez à nouveau les compteurs tx_ipsec et rx_ipsec de l'appareil Ethernet :

   # ethtool -S enp1s0 | egrep "_ipsec"
        tx_ipsec: 15
        rx_ipsec: 15

   Si les valeurs des compteurs ont augmenté, le délestage matériel ESP fonctionne.

Procédure

1. Activer la prise en charge de la décharge matérielle ESP sur la liaison réseau :

   # nmcli connection modify bond0 ethtool.feature-esp-hw-offload on

   Cette commande active la prise en charge du délestage matériel ESP sur la connexion bond0.

2. Réactiver la connexion bond0:

   # nmcli connection up bond0

3. Modifiez le fichier de configuration de Libreswan dans le répertoire /etc/ipsec.d/ de la connexion qui doit utiliser le délestage matériel ESP, et ajoutez l'instruction nic-offload=yes à l'entrée de la connexion :

   conn example
       ...
       nic-offload=yes

4. Redémarrez le service ipsec:

   # systemctl restart ipsec

Vérification

1. Affiche le port actif de la liaison :

   # grep "Currently Active Slave" /proc/net/bonding/bond0
   Currently Active Slave: enp1s0

2. Affiche les compteurs tx_ipsec et rx_ipsec du port actif :

   # ethtool -S enp1s0 | egrep "_ipsec"
        tx_ipsec: 10
        rx_ipsec: 10

3. Envoyer du trafic à travers le tunnel IPsec. Par exemple, envoyer un ping à une adresse IP distante :

   # ping -c 5 remote_ip_address

4. Affichez à nouveau les compteurs tx_ipsec et rx_ipsec du port actif :

   # ethtool -S enp1s0 | egrep "_ipsec"
        tx_ipsec: 15
        rx_ipsec: 15

   Si les valeurs des compteurs ont augmenté, le délestage matériel ESP fonctionne.

1. Rechargez la connexion vpn.example.com:

   # ipsec auto --add vpn.example.com
   002 added connection description "vpn.example.com"

2. Ensuite, lancez la connexion VPN :

   # ipsec auto --up vpn.example.com

Procédure

1. Créez un nouveau fichier playbook.yml avec le contenu suivant :

   - name: Host to host VPN
     hosts: managed_node1, managed_node2
     roles:
       - rhel-system-roles.vpn
     vars:
       vpn_connections:
         - hosts:
             managed_node1:
             managed_node2:
       vpn_manage_firewall: true
       vpn_manage_selinux: true

   Ce playbook configure la connexion managed_node1-to-managed_node2 en utilisant l'authentification par clé pré-partagée avec des clés générées automatiquement par le rôle système. Puisque vpn_manage_firewall et vpn_manage_selinux sont tous deux définis sur true, le rôle vpn utilisera les rôles firewall et selinux pour gérer les ports utilisés par le rôle vpn.

2. Facultatif : Configurez les connexions entre les hôtes gérés et les hôtes externes qui ne sont pas répertoriés dans le fichier d'inventaire en ajoutant la section suivante à la liste d'hôtes vpn_connections:

       vpn_connections:
         - hosts:
             managed_node1:
             managed_node2:
             external_node:
               hostname: 192.0.2.2

   Cela permet de configurer deux connexions supplémentaires : managed_node1-to-external_node et managed_node2-to-external_node.

1. Facultatif : vous pouvez spécifier plusieurs connexions VPN pour les nœuds gérés en utilisant des sections supplémentaires dans vpn_connections, par exemple un plan de contrôle et un plan de données :

   - name: Multiple VPN
     hosts: managed_node1, managed_node2
     roles:
       - rhel-system-roles.vpn
     vars:
       vpn_connections:
         - name: control_plane_vpn
           hosts:
             managed_node1:
               hostname: 192.0.2.0 # IP for the control plane
             managed_node2:
               hostname: 192.0.2.1
         - name: data_plane_vpn
           hosts:
             managed_node1:
               hostname: 10.0.0.1 # IP for the data plane
             managed_node2:
               hostname: 10.0.0.2

2. Facultatif : vous pouvez modifier les variables selon vos préférences. Pour plus de détails, voir le fichier /usr/share/doc/rhel-system-roles/vpn/README.md.

3. Facultatif : Vérifier la syntaxe du playbook.

   # ansible-playbook --syntax-check /path/to/file/playbook.yml -i /path/to/file/inventory_file

4. Exécutez le playbook sur votre fichier d'inventaire :

   # ansible-playbook -i /path/to/file/inventory_file /path/to/file/playbook.yml

Vérification

1. Sur les nœuds gérés, confirmez que la connexion est chargée avec succès :

   # ipsec status | grep connection.name

   Remplacez connection.name par le nom de la connexion de ce nœud, par exemple managed_node1-to-managed_node2.

1. Sur les nœuds gérés, confirmez que la connexion a été lancée avec succès :

   # ipsec trafficstatus | grep connection.name

2. Facultatif : si une connexion n'a pas été chargée avec succès, ajoutez-la manuellement en entrant la commande suivante. Vous obtiendrez ainsi des informations plus précises sur la raison pour laquelle la connexion n'a pas pu être établie :

   # ipsec auto --add connection.name

   Note

   Toutes les erreurs qui ont pu se produire au cours du processus de chargement et de démarrage de la connexion sont signalées dans les journaux, qui se trouvent à l'adresse /var/log/pluto.log. Comme ces journaux sont difficiles à analyser, essayez d'ajouter manuellement la connexion afin d'obtenir les messages de journaux à partir de la sortie standard à la place.

Procédure

1. Créez un nouveau fichier playbook.yml avec le contenu suivant :

   - name: Mesh VPN
     hosts: managed_node1, managed_node2, managed_node3
     roles:
       - rhel-system-roles.vpn
     vars:
       vpn_connections:
         - opportunistic: true
           auth_method: cert
           policies:
             - policy: private
               cidr: default
             - policy: private-or-clear
               cidr: 198.51.100.0/24
             - policy: private
               cidr: 192.0.2.0/24
             - policy: clear
               cidr: 192.0.2.7/32
       vpn_manage_firewall: true
       vpn_manage_selinux: true

   Note

   Puisque vpn_manage_firewall et vpn_manage_selinux sont tous deux définis sur true, le rôle vpn utilisera les rôles firewall et selinux pour gérer les ports utilisés par le rôle vpn.

2. Facultatif : vous pouvez modifier les variables selon vos préférences. Pour plus de détails, voir le fichier /usr/share/doc/rhel-system-roles/vpn/README.md.

3. Facultatif : Vérifier la syntaxe du playbook.

   # ansible-playbook --syntax-check playbook.yml

4. Exécutez le playbook sur votre fichier d'inventaire :

   # ansible-playbook -i inventory_file /path/to/file/playbook.yml

Procédure

1. Ajouter des règles de pare-feu, par exemple :

   • Limiter les connexions TCP et n'accepter que les paquets provenant de l'hôte 192.168.0.0/24 via le port 111:

     # firewall-cmd --add-rich-rule='rule family="ipv4" port port="111" protocol="tcp" source address="192.168.0.0/24" invert="True" drop'

   • Limiter les connexions TCP et n'accepter que les paquets provenant de l'hôte local via le port 111:

     # firewall-cmd --add-rich-rule='rule family="ipv4" port port="111" protocol="tcp" source address="127.0.0.1" accept'

   • Limiter les connexions UDP et n'accepter que les paquets provenant de l'hôte 192.168.0.0/24 via le port 111:

     # firewall-cmd --permanent --add-rich-rule='rule family="ipv4" port port="111" protocol="udp" source address="192.168.0.0/24" invert="True" drop'

     Pour rendre les paramètres du pare-feu permanents, utilisez l'option --permanent lors de l'ajout de règles de pare-feu.

2. Rechargez le pare-feu pour appliquer les nouvelles règles :

   # firewall-cmd --reload

Procédure

1. Ajouter des règles de pare-feu au serveur, par exemple :

   • Accepter les connexions mountd à partir de l'hôte 192.168.0.0/24:

     # firewall-cmd --add-rich-rule 'rule family="ipv4" service name="mountd" source address="192.168.0.0/24" invert="True" drop'

   • Accepter les connexions mountd à partir de l'hôte local :

     # firewall-cmd --permanent --add-rich-rule 'rule family="ipv4" source address="127.0.0.1" service name="mountd" accept'

     Pour rendre les paramètres du pare-feu permanents, utilisez l'option --permanent lors de l'ajout de règles de pare-feu.

2. Rechargez le pare-feu pour appliquer les nouvelles règles :

   # firewall-cmd --reload

Procédure

1. Installer PostgreSQL :

   # yum install postgresql-server

2. Initialiser une zone de stockage de la base de données à l'aide de l'une des options suivantes :

   1. Utilisation de l'utilitaire initdb:

      $ initdb -D /home/postgresql/db1/

      La commande initdb avec l'option -D crée le répertoire que vous spécifiez s'il n'existe pas déjà, par exemple /home/postgresql/db1/. Ce répertoire contient alors toutes les données stockées dans la base de données ainsi que le fichier de configuration de l'authentification du client.

   2. Utilisation du script postgresql-setup:

      $ postgresql-setup --initdb

      Par défaut, le script utilise le répertoire /var/lib/pgsql/data/. Ce script aide les administrateurs système à gérer les bases de données en cluster.

3. Pour permettre à n'importe quel utilisateur local authentifié d'accéder à n'importe quelle base de données avec son nom d'utilisateur, modifiez la ligne suivante dans le fichier pg_hba.conf:

   local   all             all                                     trust

   Cela peut s'avérer problématique lorsque vous utilisez des applications en couches qui créent des utilisateurs de base de données et aucun utilisateur local. Si vous ne souhaitez pas contrôler explicitement tous les noms d'utilisateur du système, supprimez la ligne local du fichier pg_hba.conf.

4. Redémarrez la base de données pour appliquer les modifications :

   # systemctl restart postgresql

   La commande précédente met à jour la base de données et vérifie également la syntaxe du fichier de configuration.

Procédure

1. Sur le premier hôte sur lequel vous configurez MACsec :

   • Créez la clé d'association de connectivité (CAK) et le nom de la clé d'association de connectivité (CKN) pour la clé pré-partagée :

     1. Créer un CAK hexadécimal de 16 octets :

        # dd if=/dev/urandom count=16 bs=1 2> /dev/null | hexdump -e '1/2 "%04x"'
        50b71a8ef0bd5751ea76de6d6c98c03a

     2. Créer un CKN hexadécimal de 32 octets :

        # dd if=/dev/urandom count=32 bs=1 2> /dev/null | hexdump -e '1/2 "%04x"'
        f2b4297d39da7330910a74abc0449feb45b5c0b9fc23df1430e1898fcf1c4550

2. Sur les deux hôtes, vous souhaitez établir une connexion MACsec :

3. Créer la connexion MACsec :

   # nmcli connection add type macsec con-name macsec0 ifname macsec0 connection.autoconnect yes macsec.parent enp1s0 macsec.mode psk macsec.mka-cak 50b71a8ef0bd5751ea76de6d6c98c03a macsec.mka-ckn f2b4297d39da7330910a7abc0449feb45b5c0b9fc23df1430e1898fcf1c4550

   Utilisez les CAK et CKN générés à l'étape précédente dans les paramètres macsec.mka-cak et macsec.mka-ckn. Les valeurs doivent être identiques sur chaque hôte du réseau protégé par MACsec.

4. Configurez les paramètres IP de la connexion MACsec.

   1. Configurez les paramètres IPv4. Par exemple, pour définir une adresse IPv4 statique, un masque de réseau, une passerelle par défaut et un serveur DNS pour la connexion macsec0, entrez :

      # nmcli connection modify macsec0 ipv4.method manual ipv4.addresses '192.0.2.1/24' ipv4.gateway '192.0.2.254' ipv4.dns '192.0.2.253'

   2. Configurez les paramètres IPv6. Par exemple, pour définir une adresse IPv6 statique, un masque de réseau, une passerelle par défaut et un serveur DNS pour la connexion macsec0, entrez :

      # nmcli connection modify macsec0 ipv6.method manual ipv6.addresses '2001:db8:1::1/32' ipv6.gateway '2001:db8:1::fffe' ipv6.dns '2001:db8:1::fffd'

5. Activer la connexion :

   # nmcli connection up macsec0

Vérification

1. Vérifiez que le trafic est crypté :

   # tcpdump -nn -i enp1s0

2. Facultatif : Affichez le trafic non crypté :

   # tcpdump -nn -i macsec0

3. Affiche les statistiques MACsec :

   # ip macsec show

4. Afficher les compteurs individuels pour chaque type de protection : intégrité seule (cryptage désactivé) et cryptage (cryptage activé)

   # ip -s macsec show

Procédure

1. Configurer Dovecot :

   1. Inclure les lignes suivantes dans le fichier /etc/dovecot/conf.d/10-master.conf:

      service auth {
        unix_listener /var/spool/postfix/private/auth {
          mode = 0660
          user = postfix
          group = postfix
        }
      }

      L'exemple précédent utilise des sockets de domaine UNIX pour la communication entre Postfix et Dovecot. L'exemple suppose également des paramètres de serveur SMTP Postfix par défaut, qui incluent la file d'attente de courrier située dans le répertoire /var/spool/postfix/, et l'application fonctionnant sous l'utilisateur et le groupe postfix.

   2. Optionnel : Configurer Dovecot pour qu'il écoute les demandes d'authentification de Postfix via TCP :

      service auth {
        inet_listener {
            port = port-number
        }
      }

   3. Spécifiez la méthode que le client de messagerie utilise pour s'authentifier avec Dovecot en éditant le paramètre auth_mechanisms dans le fichier /etc/dovecot/conf.d/10-auth.conf:

      auth_mechanisms = plain login

      Le paramètre auth_mechanisms prend en charge différentes méthodes d'authentification en texte clair et en texte non clair.

2. Configurez Postfix en modifiant le fichier /etc/postfix/main.cf:

   1. Activer l'authentification SMTP sur le serveur SMTP Postfix :

      smtpd_sasl_auth_enable = yes

   2. Activer l'utilisation de l'implémentation SASL de Dovecot pour l'authentification SMTP :

      smtpd_sasl_type = dovecot

   3. Indiquez le chemin d'authentification relatif au répertoire de la file d'attente Postfix. Notez que l'utilisation d'un chemin relatif garantit que la configuration fonctionne indépendamment du fait que le serveur Postfix tourne sur chroot ou non :

      smtpd_sasl_path = private/auth

      Cette étape utilise des sockets de domaine UNIX pour la communication entre Postfix et Dovecot.

      Pour configurer Postfix afin qu'il recherche Dovecot sur une autre machine dans le cas où vous utilisez des sockets TCP pour la communication, utilisez des valeurs de configuration similaires à ce qui suit :

      smtpd_sasl_path = inet : ip-address: port-number

      Dans l'exemple précédent, remplacez ip-address par l'adresse IP de la machine Dovecot et port-number par le numéro de port spécifié dans le fichier /etc/dovecot/conf.d/10-master.conf de Dovecot.

   4. Spécifiez les mécanismes SASL que le serveur SMTP Postfix met à la disposition des clients. Notez que vous pouvez spécifier des mécanismes différents pour les sessions cryptées et non cryptées.

      smtpd_sasl_security_options = noanonymous, noplaintext
      smtpd_sasl_tls_security_options = noanonymous

      Les directives précédentes précisent que lors des sessions non chiffrées, aucune authentification anonyme n'est autorisée et qu'aucun mécanisme transmettant des noms d'utilisateur ou des mots de passe non chiffrés n'est autorisé. Pour les sessions cryptées utilisant TLS, seuls les mécanismes d'authentification non anonymes sont autorisés.