Désactiver la connexion par mot de passe SSH et utiliser des certificats

Une fois que la connexion par clé fonctionne, le serveur n’a plus besoin d’accepter les mots de passe via le réseau. Cela empêche toute tentative de deviner un mot de passe. Dans cette partie, vous désactivez la connexion par mot de passe et celle en tant qu’utilisateur root de manière sécurisée. Enfin, vous verrez comment les certificats SSH facilitent la gestion de l’accès à plusieurs serveurs.

Prérequis

• L’authentification par clé est fonctionnelle, voir [[SSH Level 2 - Clés au lieu de mots de passe|SSH Level 2]].
• Votre utilisateur a les privilèges sudo, voir [[Installation du serveur Niveau 4 - Préparation du serveur|Préparer le serveur]].
• La console dans Proxmox est ouverte. Elle sert d’alternative en cas de verrouillage hors accès SSH.

Désactiver la connexion par mot de passe et en tant que root

Le service SSH lit les paramètres depuis /etc/ssh/sshd_config et depuis les fichiers dans le dossier /etc/ssh/sshd_config.d/. Créez un fichier dédié, ce qui facilite l’identification des modifications effectuées et leur annulation :

sudo nano /etc/ssh/sshd_config.d/10-sikker.conf

Entrez :

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

PasswordAuthentication no désactive l’authentification par mot de passe standard. KbdInteractiveAuthentication no désactive également l’authentification interactive au clavier, qui peut sinon accepter des mots de passe via PAM. PermitRootLogin no bloque complètement la connexion en tant que superutilisateur (root).

Pour la plupart des paramètres SSH, c’est la première valeur lue par le service qui s’applique. Votre fichier ne prime donc pas automatiquement sur les autres fichiers : l’emplacement de Include, les paramètres précédents et d’éventuels blocs Match peuvent influencer le résultat. Vérifiez les valeurs effectives avant d’appiquer la modification.

Vérifiez les paramètres avant de les appliquer :

sudo sshd -t

Si aucun message n’apparaît, la syntaxe est valide. Consultez ensuite les valeurs que donne la nouvelle configuration :

sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication) '

Les trois doivent afficher no. Si vous obtenez d’autres valeurs, examinez /etc/ssh/sshd_config et les fichiers qu’il inclut avant de continuer. Avec des règles Match, vérifiez également la connexion actuelle via sudo sshd -T -C user=user,addr=IP_DU_CLIENT,host=NOM_DU_CLIENT ; remplacez les valeurs d’exemple par l’utilisateur, l’adresse du client et le nom du client pour la connexion que vous testez. Effectuez le même contrôle sur ces trois paramètres.

Une fois que les valeurs sont correctes, rechargez la modification :

sudo systemctl reload ssh

Ne fermez pas la fenêtre dans laquelle vous êtes connecté(e). Ouvrez une nouvelle fenêtre de terminal et testez :

ssh debian-vm                 # doit fonctionner
ssh root@SERVER-IP            # doit être refusé
ssh -o PubkeyAuthentication=no user@SERVER-IP   # doit être refusé, aucune demande de mot de passe

Le mot de passe de l’utilisateur est toujours requis pour sudo. Il est saisi sur le serveur et non via le réseau.

Approfondissement : certificats SSH

Avec dix serveurs et cinq administrateurs, chaque clé doit être présente sur chacun des serveurs. Il y a cinquante entrées dans authorized_keys, et lorsqu’une personne quitte l’organisation, la clé doit être supprimée partout.

Avec les certificats, un émetteur de certificat (CA) signe votre clé. Les serveurs font confiance au CA, non à chaque clé individuelle. Le certificat contient également :

• principales : les noms pour lesquels le certificat est valable, par exemple admin
• durée de validité : lorsque le certificat cesse d’être valide

Configuration du serveur

Vous avez besoin de la clé publique de l’autorité de certification auprès de celui qui gère cette autorité (par exemple, le professeur). Placez-la sur le serveur :

sudo nano /etc/ssh/lab_user_ca.pub

Déterminez quels principaux sont autorisés à se connecter en tant que l’utilisateur user :

sudo mkdir -p /etc/ssh/auth_principals
echo admin | sudo tee /etc/ssh/auth_principals/user

Informez le service SSH de l’autorité de certification (CA) :

sudo nano /etc/ssh/sshd_config.d/10-lab-ca.conf

TrustedUserCAKeys /etc/ssh/lab_user_ca.pub
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

%u est remplacé par le nom d’utilisateur en cours de connexion. Vérifiez et rechargez avec sudo sshd -t et sudo systemctl reload ssh.

Connexion avec le certificat

Le certificat se trouve à côté de la clé privée et se termine par -cert.pub. Consultez son contenu :

ssh-keygen -L -f ~/.ssh/id_ed25519-cert.pub

Recherchez Principals, Valid et Signing CA. Ajoutez le certificat dans ~/.ssh/config :

Host debian-vm
    HostName SERVER-IP
    User user
    IdentityFile ~/.ssh/id_ed25519
    CertificateFile ~/.ssh/id_ed25519-cert.pub

Vous vous connectez maintenant avec ssh debian-vm, alors que votre clé ne se trouve pas dans le fichier authorized_keys sur le serveur.

Comment l’AAC signe (pour celui qui exploite l’AAC)

ssh-keygen -t ed25519 -f lab_user_ca                  # créer la clé CA une seule fois et l'entreposer en sécurité
ssh-keygen -s lab_user_ca -I elev@skolen -n admin -V +52w id_ed25519.pub

-n est le principal, -V est la durée de validité et -I est un identifiant affiché dans les journaux du serveur. La clé privée de l’autorité de certification (CA) donne accès à tous les serveurs qui lui accordent leur confiance ; elle ne doit donc jamais être stockée sur un serveur ni partagée.

En cas de problème

1. Vous êtes verrouillé : Connectez-vous à la console Proxmox, supprimez le fichier que vous avez créé dans /etc/ssh/sshd_config.d/ et exécutez sudo systemctl reload ssh.
2. sshd -t renvoie une erreur : Le message indique le nom du fichier et le numéro de ligne. Corrigez l’erreur avant d’enregistrer les modifications.
3. Le certificat n’est pas accepté : Vérifiez que le principal dans le certificat (ssh-keygen -L) est présent dans /etc/ssh/auth_principals/user, et que le certificat n’a pas expiré. Sur le serveur, sudo journalctl -u ssh -n 20 affiche pourquoi la connexion a été refusée.

Concepts importants

Contrôles

• ssh root@SERVER-IP est rejeté.
• La connexion par mot de passe via SSH est rejetée.
• Vous pouvez expliquer pourquoi vous avez testé dans une nouvelle fenêtre avant de fermer l’ancienne.
• Approfondissement : vous pouvez expliquer pourquoi un AC (autorité de certification) est plus simple que authorized_keys sur plusieurs serveurs.

Source : OpenSSH – sshd_config.