Tous ceux qui utilisent SSH savent que la première fois qu'ils se connectent au serveur, un message apparaît confirmant l'empreinte digitale de la clé. En outre, la clé est stockée côté client et ce message ne s'affiche plus tant que la clé enregistrée n'est pas modifiée. Mais quelle est la signification pratique de cette procédure?Dans la vraie vie, presque personne ne vérifie l'empreinte digitale de la clé SSH du serveur sans vraiment penser à la possibilité d'attaques MiTM. Avec l'avènement de l'enregistrement DNS SSHFP, l'empreinte digitale de la clé du serveur peut être stockée dans DNS et authentifiée à l'aide de DNSSEC. Dans ce cas, vous n'avez même pas besoin de confirmer la clé lors de la première connexion. Cet article vous montrera comment configurer un enregistrement SSHFP pour votre serveur SSH.Serveur de test
Tout d'abord, nous avons besoin d'un serveur. Dans le panneau RuVDS, les détails de l'accès SSH se trouvent immédiatement sur la carte serveur. Nous enregistrons l'adresse IP et le mot de passe pour la connexion.
Vous pouvez également configurer le pare-feu directement à partir du panneau de commande pour autoriser l'accès SSH uniquement pour votre IP.Pour configurer SSHFP, un domaine doit être dirigé vers l'adresse IP du serveur; nous allons configurer les enregistrements DNS pour ce domaine.Fonctionnement des clés dans SSH
Dans les exemples, nous ne considérerons que le package OpenSSH, car c'est l'option la plus populaire.Lors de l'installation d'un nouveau serveur, des clés SSH aléatoires sont générées, cela se produit généralement immédiatement lors de l'installation du package OpenSSH ou lors du premier démarrage si des images système prêtes à l'emploi sont utilisées.Les fichiers clés se trouvent ici:$ ls -la /etc/ssh/ssh_host_*_key*
/etc/ssh/ssh_host_dsa_key
/etc/ssh/ssh_host_dsa_key.pub
/etc/ssh/ssh_host_ecdsa_key
/etc/ssh/ssh_host_ecdsa_key.pub
/etc/ssh/ssh_host_ed25519_key
/etc/ssh/ssh_host_ed25519_key.pub
/etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_rsa_key.pub
Dans cette liste, il existe plusieurs clés de types différents à la fois: dsa, rsa, ecdsa, ed25519. Ceci est fait pour la compatibilité avec différents clients SSH. Au stade de la connexion, le client et le serveur conviennent de l'algorithme clé à utiliser. Le client peut demander au serveur d'utiliser un algorithme différent si celui proposé n'est pas pris en charge. Le serveur envoie la partie publique de sa clé au client et l'utilisateur est invité à vérifier manuellement son empreinte digitale.
Le serveur envoie l'empreinte de la clé publique au client au moment de la connexion.S'il s'agit de la première connexion, un message sera affiché au client avec la demande de vérification manuelle de l'empreinte:The authenticity of host 'example.com (123.45.67.89)' can't be established.
ECDSA key fingerprint is SHA256:7Q4nIqjuo/lSXWFkt9RaJYVHrT6LUAc6KWrdQ4/DDeA.
Are you sure you want to continue connecting (yes/no/[fingerprint])?
À ce stade, nous cliquons tous généralement sur Oui sans hésitation et l'empreinte digitale de la clé est enregistrée dans un fichier ~/.ssh/known_hosts. Désormais, si la clé du serveur change, un message s'affiche à propos d'une éventuelle attaque MiTM. Il est supposé que pour la toute première fois, le client a effectué lui-même un contrôle des clés et s'est assuré de son authenticité.Cette approche est assez risquée, car si l'attaquant a réussi à saisir l'instant de la première connexion, il pourra glisser sa clé et intercepter la connexion. Dans le cas de c HTTPS, nous avons un tiers qui confirme la clé du serveur avec un certificat. Si la même approche que dans SSH était utilisée sur le Web, nous serions constamment tourmentés par les messages de vérification des clés et les attaques MiTM seraient partout, car personne ne vérifierait les clés, mais serait tout simplement toujours d'accord.Nous stockons une impression de clé dans DNS. Que sont les entrées SSHFP
Comment savoir que la clé SSH proposée par le serveur est bien réelle et qu'il ne s'agit pas d'une attaque MiTM? En effet, pour entrer sur le serveur et vérifier la clé, vous devez d'abord saisir le mot de passe. Mais l'attaquant pourra alors pirater instantanément le serveur et remplacer toutes les données qu'il contient, à tel point que nous ne remarquerons pas le hic. Par conséquent, nous avons besoin d'un moyen de vérifier l'authenticité de la clé AVANT la connexion réelle.Pendant longtemps, la seule façon de vérifier la clé SSH du serveur avant la connexion était d'utiliser un canal différent, par exemple, demander à l'administrateur du serveur de fournir l'empreinte digitale de la clé du serveur. Cela n'est pas pratique, il est donc plus facile d'ignorer le problème et de toujours accepter sans hésitation.
SSHFP permet l'authentification par clé du serveur avant de se connecter via SSHFP DNS- type d'enregistrements DNS pour stocker les clés SSH. L'empreinte de la clé SSH est placée dans le serveur DNS comme un enregistrement TXT et signée avec la clé DNSSEC. Autrement dit, lors de la première connexion au serveur à l'aide du nom d'hôte, le client pourra connaître à l'avance l'empreinte digitale de la clé de serveur via DNS, et si elle correspond au serveur proposé, connectez-vous sans avertissement .Configurer DNSSEC
Pour utiliser SSHFP, vous avez besoin d'un nom de domaine avec DNSSEC configuré. Il existe de nombreux services DNS publics qui offrent immédiatement un panneau de contrôle DNS avec la fonction DNSSEC. Le service le plus populaire est CloudFlare. Considérez la configuration en utilisant son exemple. Pour les étapes suivantes, le domaine doit être délégué au serveur Cloudflare NS.▍Étape 1 - générer une clé
Allez dans le panneau DNS -> Activer DNSSEC.À ce stade, des clés seront générées pour signer votre zone de domaine. On vous montrera les clés publiques. Ils devront être ajoutés du côté du registraire de domaine.▍ Étape 2 - ajout de clés publiques au bureau d'enregistrement
Ensuite, vous devez créer des enregistrements DS contenant la clé publique du registraire de domaine.Selon votre registraire, l'interface d'ajout de clé DNSSEC peut être différente. Il est important de ne pas confondre les valeurs, car elles peuvent être nommées différemment et différer des noms affichés dans CloudFlare.L'exemple ci-dessous montre comment les valeurs affichées dans le panneau CloudFlare sont liées aux valeurs dans le panneau de contrôle de domaine du registraire Uniregistry.
▍ Étape 3 - vérifier les enregistrements DS ajoutés
Après avoir ajouté des enregistrements DS sur le côté du bureau d'enregistrement, vous pouvez vérifier que les paramètres sont corrects. Du côté de CloudFlare, la signature des enregistrements DNS ne sera activée que lorsque la vérification de l'exactitude de l'ajout d'enregistrements DS du côté du bureau d'enregistrement sera réussie.
En attente de l'ajout d'enregistrements DSAprès quelques minutes ou heures, si les enregistrements ont été ajoutés correctement, vous verrez un tel message. Cela signifie que les réponses DNS sont désormais signées à l'aide de DNSSEC.
▍ Étape 4 - vérifier le fonctionnement DNSSEC
Vous pouvez maintenant tester le fonctionnement de DNSSEC sur notre domaine en utilisant des services en ligne comme dnssec-analyzer.verisignlabs.com . Toutes les coches doivent être vertes.
Résultat de validation DNSSECAjout d'entrées SSHFP
Nous générerons des enregistrements SSHFP sur le serveur. Dans notre exemple, nous administrons un serveur avec l'adresse myserver.com . Pour ce nom de domaine, nous avons précédemment configuré DNSSEC.Sur le serveur, exécutez la commande:
sudo ssh-keygen -r myserver.com
myserver.com IN SSHFP 1 1 057ecce168ace29d5a0099e3b63df2850e4c8e20
myserver.com IN SSHFP 1 2 52cd6099a304b9b8f57f2cd914e96a1b7477eb2f88c98c602
myserver.com IN SSHFP 2 1 42d677482e4450ee515d3aac94d96302a99bd4ec
myserver.com IN SSHFP 2 2 edda5fa445dc0da570c772a6df0d4012037e1a102840d29c4
...
Des empreintes digitales seront générées pour toutes les clés du dossier / etc / ssh / . Vous pouvez générer de manière sélective des empreintes digitales pour des clés spécifiques en spécifiant le chemin d'accès au fichier.Maintenant, tous ces enregistrements doivent être ajoutés dans le panneau DNS, dans notre cas Cloudflare.
Ajout d'un enregistrement SSHFP au panneau CloudflareVous devez donc ajouter toutes les clés obtenues à l'étape précédente. Vous pouvez maintenant vérifier que les clés sont ajoutées:dig SSHFP myserver.com
Dans la réponse, vous devriez voir toutes les clés ajoutées. La signature de nouvelles entrées peut prendre du temps, de sorte que les clés de la réponse peuvent ne pas apparaître immédiatement. Cela ne prend généralement pas plus de 10 à 15 minutes.Connectez-vous au serveur
Pour que le client SSH vérifie la validité des clés via DNS, vous devez ajouter l'activer dans les paramètres. La configuration du client se trouve dans le dossier de départ de l'utilisateur. Ajoutez-y une ligne.
vi ~/.ssh/config
VerifyHostKeyDNS yes
Vous pouvez maintenant vous connecter au serveur. Pour la pureté de l'expérience, vous pouvez supprimer la ligne avec l'empreinte digitale de ~ / .ssh / known_hosts . Pour plus de clarté, vous pouvez ajouter l'option -v
ssh -v root@myserver.com
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
.....
DNS lookup error: data does not exist
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
....
debug1: found 8 insecure fingerprints in DNS
debug1: matching host key fingerprint found in DNS
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
....
debug1: found 8 secure fingerprints in DNS
debug1: matching host key fingerprint found in DNS
debug1: ssh_rsa_verify: signature correct
Si tout est correctement configuré, la première fois que vous vous connectez au serveur, il ne vous sera pas demandé de vérifier manuellement l'empreinte digitale de la clé. Cela nécessite également que le résolveur DNS du système prenne en charge la validation DNSSEC.Il est important de se rappeler que SSHFP ne fonctionnera que lorsqu'il sera connecté à un serveur par nom de domaine et ne fonctionnera pas lorsqu'il est connecté par IP ou un autre domaine qui n'a pas d'enregistrements SSHFP.