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
Intérressant, mais je ne comprends pas quand tu dis « personne ne le fait » ? Quand on utilise un client SSH (PuTTY par exemple) il y a un avertissement clair quand cette situation apparaît, et si je n’ai rien fait sur le serveur alors je refuse la connexion c’est qu’il y a un souci (compromis). On peut aussi utiliser uniquement l’IP pour s’assurer d’arriver sur la bonne machine.
Bonjour Xhark,
J’avoue que je n’ai pas été au bout de ma pensée.
Il m’arrive quelques fois de dépanner des copains. Ou de me connecter à mon propre serveur depuis une VM etc. Je n’ai jamais vérifié si l’empreinte du serveur était la bonne ou pas.
Pour la connexion directe sur l’IP c’est une question de feignantise 🙂 et puis ayant tendance à me connecter depuis des VMs utiliser le nom de domaine est plus simple pour moi
Moi qui pensais que mon serveur SSH était bien sécurisé, et bien pas totalement ! Avant de mettre ça en place, est-ce que cela fonctionnera aussi avec le SFTP ou ça peut poser des problèmes ?
Ensuite tu dis qu’il faut déclarer l’empreinte SSH dans son DNS, actuellement mes DNS sont gérés par OVH car je veux mettre en place un serveur Unbound avec du DNSCrypt mais j’ai l’impression que comme un serveur mail c’est pas évident cette bête là, donc via OVH on peut quand même déclarer son empreinte dans ces DNS ?
Alors, tous les prestataires gérants les DNS ne permettent pas forcément de déclarer un enregistrement SSHFP. OVH lui le permet. Tu n’auras ensuite pas de problème pour te connecter en SFTP ou SSH. Pour pouvoir profiter de cette fonctionnalité il faut aussi que les DNS (ceux que tu utilises pour ta connexion internet) gèrent DNSSEC. Peu de FAI mettent à disposition de leurs utilisateursdes serveurs DNS compatibles, les serveurs DNS de google le sont. Dernier commentaire : un serveur DNS est beaucoup moins compliqué à mettre en place qu’un serveur mail. C’est un peu fastidieux au départ c’est vrai mais… Lire la suite »
D’accord, donc je vais pouvoir mettre ça en place alors 🙂
Je n’utilise plus les DNS de mon FAI depuis un moment 😉
Oui en effet, mais j’ai vu qu’il fallait différencier les resolveur et les serveurs pour gérer un domaine.
@xhark :
« On peut aussi utiliser uniquement l’IP pour s’assurer d’arriver sur la bonne machine. »
Que tu utilises le nom de la machine ou son IP pour s’y connecter, tu seras vulnérable à une attaque MitM lors de la première connexion depuis un device qui n’a pas l’empreinte enregistré.