Avant de plonger dans le vif du sujet, c’est à dire sécuriser SSH avec SSHFP, quelques explications sont nécessaires.
Tout d’abord parlons du système SSH, celui-ci utilise un système d’empreinte de clé pour vérifier l’authenticité du serveur lorsque le client se connecte. Lors des futures connexions, l’empreinte de la clé sauvegardé est vérifiée. Le client SSH vous avertira si l’empreinte stockée localement diffère de l’empreinte reçue lors de futures tentatives de connexion. (documentation freebsd)
Pour faire court : le client vérifie que le serveur auquel vous vous connectez soit le bon. Génial, non ? Hé bien non puisqu’en pratique presque personne ne le fait.
SSHFP permet donc à un administrateur de déclarer dans son DNS (qu’il faudra avoir protégé par DNSSEC sinon cette protection sera moins efficace) l’empreinte de ses serveurs SSH.
Composition de l’enregistrement
Un enregistrement SSHFP se compose de 3 éléments :
- L’algorithme : dépend du type de clés SSH : RSA (1), DSA (2), ECDSA (3), ED25519 (4)
- Le type d’empreinte : SHA-1 (1) ou SHA-256 (2)
- L’empreinte (hexadécimale) du serveur SSH
Générer des enregistrements SSHFP
Pour générer vos enregistrements SSHFP rien de plus simple, il vous suffit d’utiliser la commande suivante
ssh-keygen -r subdomain.domain.tld
N’acceptant que des authentifications par clé Ed25519 sur mon serveur j’ai choisi d’utiliser l’enregistrement suivant
root@noobunbox.net:~$ ssh-keygen -r www.noobunbox.net www.noobunbox.net IN SSHFP 4 1 33f75f87a4dc9e1084d0aeb91e92e8fbb3a3f676
Test et configuration du client
Une fois les modifications au niveau du DNS effectuées et propagées, connectez vous à votre serveur SSH via la commande suivante
ssh -o "VerifyHostKeyDNS yes" subdomain.domain.tld -v
Si DNSSEC et SSHFP sont correctement configurés sur votre domaine vous devriez voir les lignes suivantes
debug1: found 2 secure fingerprints in DNS debug1: matching host key fingerprint found in DNS
Si vous voyez l’erreur No matching host key fingerprint found in DNS cela peut signifier que vos enregistrements SSHFP sont incorrects ou non propagés
Si vous voyez l’erreur DNS lookup error: data does not exist ainsi que The authenticity of host 'subdomain.domain.tld (XXX.XXX.XXX.XXX)' can't be established., cela signifie que votre resolveur DNS ne prend pas en charge DNSSEC ou que DNSSEC est mal configuré ou non configuré.
Afin de ne pas avoir à utiliser l’option « VerifyHostKeyDNS yes » à chaque connexion, modifiez le fichier de configuration du client ssh
sudo nano /etc/ssh/ssh_config
Afin d’y ajouter
VerifyHostKeyDNS yes
Puis relancez le service SSH
/etc/init.d/ssh reload
Source