Consultez le manuel avec : man 5 exports et identifiez les paramètres utiles relativement aux choix retenus.

Créez un nouveau script de génération du fichier /etc/exports.

#!/bin/bash

IPV4_NETWORK=172.28.101.0/24
IPV6_NETWORK=2001:678:3fc:65::/64

cat << EOF > /etc/exports
/home/exports           ${IPV4_NETWORK}(rw,sync,fsid=0,crossmnt,no_subtree_check,sec=krb5p,xprtsec=tls:mtls)
/home/exports/home      ${IPV4_NETWORK}(rw,sync,no_subtree_check,sec=krb5p,xprtsec=tls:mtls)

/home/exports           ${IPV6_NETWORK}(rw,sync,fsid=0,crossmnt,no_subtree_check,sec=krb5p,xprtsec=tls:mtls)
/home/exports/home      ${IPV6_NETWORK}(rw,sync,no_subtree_check,sec=krb5p,xprtsec=tls:mtls)
EOF

Relativement à la configuration initiale, les deux options ajoutées sont :

Si le code du script ci-dessus est enregistré dans un fichier appelé secure-nfs-exports.sh, on peut lancer la création du nouveau fichier /etc/exports.

Créez une copie de sauvegarde de la version actuelle du fichier /etc/exports.

sudo cp /etc/exports /etc/exports.backup

Générez la nouvelle version du fichier de configuration de l'exportation.

sudo bash secure-nfs-exports.sh

Redémarrez le service pour que la nouvelle configuration soit prise en charge.

sudo systemctl restart nfs-server

Vérifiez que le service est bien actif et sans erreur de configuration.

systemctl status nfs-server

Consultez les pages des manuels du service autofs. Par exemple : man 5 autofs.

Comme l'objectif est de reproduire le jeu d'options du serveur, on doit retrouver les mêmes éléments que dans la question précédente.

Créez une copie de sauvegarde des fichiers actuels.

sudo cp /etc/auto.master.d/ahome.autofs /etc/auto.master.d/ahome.autofs.backup

sudo cp /etc/auto.home /etc/auto.home.backup

Créez les nouvelles version de ces fichiers.

echo "/ahome  /etc/auto.home --timeout=300" | \
    sudo tee /etc/auto.master.d/ahome.autofs

echo "*    -fstype=nfs4,hard,sec=krb5p,xprtsec=mtls,nosuid,nodev,_netdev    nfs-server.lab.local:/home/&" | \
    sudo tee /etc/auto.home

On retrouve les mêmes options que sur le serveur auxquelles on a ajouté les paramètres suivants.

Redémarrez le service pour que la nouvelle configuration soit prise en charge.

sudo systemctl restart autofs

Vérifiez que le service est bien actif et sans erreur de configuration.

systemctl status autofs

Lancez la recherche avec le gestionnaire de paquets.

apt search --names-only ^krb5

On obtient ainsi une liste d'une vingtaine de paquets. Affichez les informations de chaque paquet pour décider s'il faut le retenir dans le contexte d'un serveur KDC.

apt show krb5-kdc | grep -A5 "This package"

 This package contains the Kerberos key server (KDC).  The KDC manages all
 authentication credentials for a Kerberos realm, holds the master keys
 for the realm, and responds to authentication requests.  This package
 should be installed on both master and slave KDCs.

Répétez cette opération pour les autres paquets de la liste.

Installez les paquets suivants :

sudo apt install krb5-kdc krb5-admin-server krb5-user

Lors de l'installation de ces paquets, une série de questions apparaît. Voici ce qu'il faut saisir pour rester conforme au contexte de ces manipulations.

Lancez une recherche par mot clé dans les pages de manuels.

man -k kerberos | grep realm

krb5_newrealm (8)    - Create a new Kerberos Realm

man krb5_newrealm

Générez le mot de passe de l'administrateur Kerberos.

openssl rand -base64 8 > krb-admin.password

chmod 600 krb-admin.password

cat krb-admin.password

Copiez le mot de passe et Lancez la commande krb5_newrealm

sudo sudo krb5_newrealm

This script should be run on the master KDC/admin server to initialize
a Kerberos realm.  It will ask you to type in a master key password.
This password will be used to generate a key that is stored in
/etc/krb5kdc/stash.  You should try to remember this password, but it
is much more important that it be a strong password than that it be
remembered.  However, if you lose the password and /etc/krb5kdc/stash,
you cannot decrypt your Kerberos database.
Initializing database '/var/lib/krb5kdc/principal' for realm 'LAB.LOCAL',
master key name 'K/M@LAB.LOCAL'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.

Enter KDC database master key: Collez le mot de passe

Re-enter KDC database master key to verify: Collez le mot de passe à nouveau

Now that your realm is set up you may wish to create an administrative
principal using the addprinc subcommand of the kadmin.local program.
Then, this principal can be added to /etc/krb5kdc/kadm5.acl so that
you can use the kadmin program on other computers.  Kerberos admin
principals usually belong to a single user and end in /admin.  For
example, if jruser is a Kerberos administrator, then in addition to
the normal jruser principal, a jruser/admin principal should be
created.

Don't forget to set up DNS information so your clients can find your
KDC and admin servers.  Doing so is documented in the administration
guide.

Redémarrez le service Kerberos.

sudo systemctl restart krb5-kdc

Vérifiez l'état du service.

systemctl status krb5-kdc

Remplacez le modèle de fichier /etc/krb5.conf par votre propre fichier.

cat << EOF | sudo tee /etc/krb5.conf
[libdefaults]
        default_realm = LAB.LOCAL
        kdc_timesync = 1
        ccache_type = 4
        forwardable = true
        proxiable = true
        rdns = false
        allow_weak_crypto = false
        default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
        default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
        permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96

[realms]
        LAB.LOCAL = {
                kdc = nfs-server.lab.local
                admin_server = nfs-server.lab.local
                default_domain = lab.local
        }

[domain_realm]
    .lab.local = LAB.LOCAL
    lab.local = LAB.LOCAL
EOF

Expliquez le choix des différents paramètres.

Un principal Kerberos est une identité unique utilisée pour l'authentification sécurisée au sein d'un domaine. Il est généralement composé d'un nom d'utilisateur ou de service, d'une instance optionnelle et d'un royaume (realm). Cette combinaison, enregistrée dans la base de données Kerberos, permet d'associer des clés de chiffrement à l'identité et de garantir qu'un utilisateur, un service ou un hôte dispose d'une entité distincte pour établir des communications sécurisées.

Un keytab Kerberos est un fichier qui stocke de manière sécurisée les identités (principaux) et leurs clés de chiffrement associées pour des services ou des hôtes. Il permet à ces services de s'authentifier automatiquement auprès du serveur Kerberos (KDC) sans intervention humaine ni saisie de mot de passe, ce qui facilite l'authentification forte et automatisée au sein du domaine Kerberos.

Lancez la recherche des commandes contenant la chaîne kadmin.

sudo dpkg -S kadmin | grep bin

krb5-admin-server: /usr/sbin/kadmind
krb5-user: /usr/bin/kadmin.mit
krb5-admin-server: /usr/sbin/kadmin.local

Notez que kadmin est un lien symbolique vers la commande kadmin.mit.

ls -l /usr/bin/kadmin

lrwxrwxrwx 1 root root 24 23 févr.  2025 /usr/bin/kadmin -> /etc/alternatives/kadmin

ls -l /etc/alternatives/kadmin

lrwxrwxrwx 1 root root 19 23 févr.  2025 /etc/alternatives/kadmin -> /usr/bin/kadmin.mit

On distingue deux commandes fournies par deux paquets différents.

Créez le principal à partir du serveur KDC.

sudo kadmin.local -q "addprinc admin/admin"

Entrez un mot de passe sécurisé. Cette commande ajoute le principal admin/admin@LAB.LOCAL à la base Kerberos.

Vérifiez la présence de ce nouveau principal.

sudo kadmin.local -q "listprincs"

K/M@LAB.LOCAL
kadmin/admin@LAB.LOCAL

Décommentez ou ajoutez la ligne suivante dans le fichier /etc/krb5kdc/kadm5.acl.

 sudo grep -v ^# /etc/krb5kdc/kadm5.acl

*/admin *

Redémarrez le service d'administration Kerberos.

sudo systemctl restart krb5-admin-server

Testez l'accès au service d'administration Kerberos depuis le client NFS pour valider l'accès à distance.

sudo kadmin -p kadmin/admin -q "listprincs"

Authenticating as principal kadmin/admin with password.
Password for kadmin/admin@LAB.LOCAL:

K/M@LAB.LOCAL
kadmin/admin@LAB.LOCAL

Il est possible de renouveler ou changer le mot de passe depuis le serveur KDC à l'aide de la commande suivante :

sudo kadmin.local -q "cpw kadmin/admin"

Authenticating as principal root/admin@LAB.LOCAL with password.
Enter password for principal "kadmin/admin@LAB.LOCAL":
Re-enter password for principal "kadmin/admin@LAB.LOCAL":
Password for "kadmin/admin@LAB.LOCAL" changed.

sudo kadmin.local -q "listprincs"

K/M@LAB.LOCAL
kadmin/admin@LAB.LOCAL
kadmin/changepw@LAB.LOCAL

Commencez par définir les principaux à créer :

Créez les objets de la base Kerberos depuis le serveur NFS et KDC.

sudo kadmin.local -q "addprinc -randkey nfs/nfs-server@LAB.LOCAL"

sudo kadmin.local -q "addprinc -randkey nfs/nfs-client@LAB.LOCAL"

sudo kadmin.local -q "addprinc etu-nfs@LAB.LOCAL"

Dans le cas de l'utilisateur etu-nfs, il faut impérativement saisir le même mot de passe que celui utilisé lors de la création du compte. Cette double saisie est la conséquence de l'absence de gestion d'identité intégrée.

C'est l'instruction ktadd qui permet l'enregistrement des objets.

Ajoutez les objets serveur et client NFS au keytab.

sudo kadmin.local -q "ktadd nfs/nfs-server@LAB.LOCAL"

sudo kadmin.local -q "ktadd nfs/nfs-client@LAB.LOCAL"

Affichez la liste des objets enregistrés.

sudo klist -k -t /etc/krb5.keytab

Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   2 20/09/2025 18:15:26 nfs/nfs-client@LAB.LOCAL
   2 20/09/2025 18:15:26 nfs/nfs-client@LAB.LOCAL
   2 20/09/2025 18:18:02 nfs/nfs-server@LAB.LOCAL
   2 20/09/2025 18:18:02 nfs/nfs-server@LAB.LOCAL

Affichez la liste des paquets relatifs à Kerberos.

apt search --names-only krb5

De cette longue liste on retient deux paquets : krb5-user et libpam-krb5.

Installez les paquets identifiés.

sudo apt install krb5-user libpam-krb5

Le serveur KDC et les clients doivent notamment s'accorder sur le domaine par défaut, les emplacements des KDC (noms de domaine complets et ports), les serveurs d'administration, etc. Toute incompatibilité peut entraîner des échecs d'authentification.

Il est donc conseillé de maintenir des fichiers /etc/krb5.conf identiques entre les KDC Kerberos et les clients, afin d'assurer une interopérabilité optimale.

Remplacez le contenu du fichier /etc/krb5.conf par celui appliqué sur le serveur dans la section précédente.

cat << EOF | sudo tee /etc/krb5.conf
[libdefaults]
        default_realm = LAB.LOCAL
        kdc_timesync = 1
        ccache_type = 4
        forwardable = true
        proxiable = true
        rdns = false
        allow_weak_crypto = false
        default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
        default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
        permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96

[realms]
        LAB.LOCAL = {
                kdc = nfs-server.lab.local
                admin_server = nfs-server.lab.local
                default_domain = lab.local
        }

[domain_realm]
    .lab.local = LAB.LOCAL
    lab.local = LAB.LOCAL
EOF

Commencez par prendre l'identité créée dans la base Kerberos.

su - etu-nfs

Password:
etu-nfs@clnt:~$

Lancez la demande de ticket

kinit etu-nfs@LAB.LOCAL

Password for etu-nfs@LAB.LOCAL:

Affichez la liste des tickets.

klist

Ticket cache: FILE:/tmp/krb5cc_1002_4zwha6
Default principal: etu-nfs@LAB.LOCAL

Valid starting       Expires              Service principal
28/09/2025 15:39:09  29/09/2025 01:39:09  krbtgt/LAB.LOCAL@LAB.LOCAL
        renew until 29/09/2025 15:39:06

Le résultat affiché par la commande klist montre qu'un ticket associé à l'identité etu-nfs a bien été obtenu et que celui-ci est présent dans le cache de cet utilisateur.

ls -l /tmp/krb5cc_1002_4zwha6

-rw------- 1 etu-nfs etu-nfs 960 28 sept. 15:39 /tmp/krb5cc_1002_4zwha6

Lancez une recherche à l'aide du gestionnaire de paquets en combinant les clés tls et nfs.

apt search tls.*nfs

ktls-utils/testing,now 1.2.1-3+b1 amd64 [installé]
  TLS handshake support for NFS and other in-kernel TLS users

Installez le paquet ktls-utils sur le serveur et sur le client NFS.

sudo apt install ktls-utils

Lancez la recherche dans la liste des fichiers du paquet.

dpkg -L ktls-utils | grep conf

/etc/tlshd.conf
/usr/share/man/man5/tlshd.conf.5.gz

Consultez les pages de manuels du fichiers /etc/tlshd.conf et repérez les entrées des certificats X.509.

man tlshd.conf

Créez les fichiers de configuration du serveur et du client NFS.

Sur les systèmes Debian GNU/Linux, le répertoire /etc/ssl/certs/ contient les certificats publics utilisés pour l'authentification des services et la validation des connexions sécurisées. Le répertoire /etc/ssl/private/ stocke les clés privées associées, qui sont indispensables au chiffrement. Ce répertoire doit rester strictement protégé et accessible uniquement à l'administrateur système afin de garantir la sécurité.

Proposez un tableau respectant la règle selon laquelle Chaque extrémité de la session TLS détient sa propre clé privée, tandis que les certificats sont partagés.

Codez un script qui rassemble toutes les traitements et stocke les clés et les certificats dans un répertoire dédié.

Si le code du script qui suit est enregistré sur le serveur dans le fichier generate-nfs-certs.sh, on lance le traitement en tant qu'utilisateur normal.

bash ./generate-nfs-certs.sh

#!/bin/bash
set -e

NFS_CA=nfs-ca
NFS_SERVER=nfs-server
NFS_CLIENT=nfs-client
CERT_DIR="$HOME/certs"

# 1. Créer le dossier des certificats si nécessaire
mkdir -p "${CERT_DIR}"
chmod 700 "${CERT_DIR}"
cd "${CERT_DIR}"

# 2. Créer les fichiers de configuration OpenSSL pour les extensions
cat > ca_extensions.conf << EOF
[v3_ca]
basicConstraints = critical,CA:TRUE
keyUsage = critical,keyCertSign,cRLSign
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
EOF

cat > server_extensions.conf << EOF
[v3_server]
basicConstraints = CA:FALSE
extendedKeyUsage = serverAuth
keyUsage = critical,digitalSignature,keyEncipherment
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
EOF

cat > client_extensions.conf << EOF
[v3_client]
basicConstraints = CA:FALSE
extendedKeyUsage = clientAuth
keyUsage = critical,digitalSignature,keyEncipherment
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
EOF

# 3. Générer la clé privée de la CA (RSA 4096)
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -out ${NFS_CA}.key

# 4. Générer le certificat auto-signé de la CA avec extensions X.509
openssl req -x509 -new -nodes -key ${NFS_CA}.key \
    -sha256 -days 3650 -subj "/CN=NFS-CA" \
    -out ${NFS_CA}.crt \
    -extensions v3_ca \
    -config <(cat ca_extensions.conf; echo "[req]"; echo "distinguished_name=req")

# 5. Générer la clé privée et CSR du serveur
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -out ${NFS_SERVER}.key
openssl req -new -key ${NFS_SERVER}.key -out ${NFS_SERVER}.csr -subj "/CN=${NFS_SERVER}.lab.local"

# 6. Signer le certificat serveur via la CA avec extensions TLS serveur
openssl x509 -req -in ${NFS_SERVER}.csr -CA ${NFS_CA}.crt -CAkey ${NFS_CA}.key -CAcreateserial \
    -out ${NFS_SERVER}.crt -days 730 -sha256 \
    -extfile server_extensions.conf -extensions v3_server

# 7. Générer la clé privée et CSR du client
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -out ${NFS_CLIENT}.key
openssl req -new -key ${NFS_CLIENT}.key -out ${NFS_CLIENT}.csr -subj "/CN=${NFS_CLIENT}.lab.local"

# 8. Signer le certificat client via la CA avec extensions TLS client
openssl x509 -req -in ${NFS_CLIENT}.csr -CA ${NFS_CA}.crt -CAkey ${NFS_CA}.key -CAcreateserial \
    -out ${NFS_CLIENT}.crt -days 730 -sha256 \
    -extfile client_extensions.conf -extensions v3_client

echo "Certificats et clés générés dans ${CERT_DIR}"
echo "Transférez ${NFS_CA}.crt, ${NFS_CLIENT}.key, ${NFS_CLIENT}.crt vers le client."

# 9. Effacer les fichiers de configuration temporaires
rm -f *_extensions.conf

exit 0

Redémarrez le service tlshd.service sur le serveur et le client NFS.

sudo systemctl restart tlshd.service

Vérifiez que le service est bien actif après redémarrage.

systemctl status tlshd.service

● tlshd.service - Handshake service for kernel TLS consumers
     Loaded: loaded (/usr/lib/systemd/system/tlshd.service; enabled; preset: enabled)
     Active: active (running) since Sat 2025-09-27 15:57:45 CEST; 1 day 19h ago
 Invocation: 8310411c0f7c4b5694e16326574252cc
       Docs: man:tlshd(8)
   Main PID: 381 (tlshd)
      Tasks: 1 (limit: 973)
     Memory: 5.1M (peak: 6.1M)
        CPU: 94ms
     CGroup: /system.slice/tlshd.service
             └─381 /usr/sbin/tlshd

sept. 27 15:57:45 srvr tlshd[381]: Built from ktls-utils 1.2.1 on Sep 24 2025 11:38:29
Notice: journal has been rotated since unit was started, output may be incomplete.