« Sécurisation DNS avancée » : différence entre les versions

De Linux Server Wiki
Aller à la navigation Aller à la recherche
Ligne 41 : Ligne 41 :


De cette manière, il sera necessaire que la clé soit confirmée a la fois par dns et par StrictHostKeyChecking.
De cette manière, il sera necessaire que la clé soit confirmée a la fois par dns et par StrictHostKeyChecking.
Si vous souhaitez faire confiance automatiquement aux nouvelles clés ssh obtenue par dns (aka ajouter directement la clé dans votre fichier known_hosts sans que celà vous soit demandé), modifiez la ligne de cette manière : <code>VerifyHostKeyDNS yes</code>
Si vous souhaitez faire confiance automatiquement aux nouvelles clés ssh obtenue par dns (aka ajouter directement la clé dans votre fichier known_hosts sans que celà vous soit demandé), modifiez la ligne de cette manière : <code>VerifyHostKeyDNS yes</code>. Notez que même dans ce cas, ssh n'ajoutera automatiquement la clé QUE si le serveur dns utilisé pour résoudre l'hostname a utilisé dnssec pour authentifier le résultat !

Version du 15 février 2015 à 13:45

DNSsec

DANE

SSHFP

pourquoi ?=

En l'état actuel des choses, lorsque vous vous connectez à un nouveau serveur ssh, votre client doit (s'il ne le fait pas, changez en) vous informer que le serveur sur lequel vous tentez de vous connecter d'identifie avec une certaine fingerprint :

The authenticity of host 'wiki.csnu.org (2001:41d0:2:475e::201)' can't be established.
RSA key fingerprint is 20:c2:7e:a9:f5:c2:8b:ca:c7:08:47:06:a0:74:e0:06.
Are you sure you want to continue connecting (yes/no)?

Si vous confirmez la fingerprint, elle sera ajouté au fichier ~/.ssh/known_hosts et ssh ne vous demandera plus de confirmation a moins que la clé ssh change.

Problème : Vous avez probablement vérifié que vous vous connecté au bon nom dns (voir à la bonne ip), mais avez vous vérifié l'identité du serveur via sa fingerprint ssh ? Probablement pas. Pourtant, vous devriez. C'est ici que vient se glisser le champ sshfp : il permet de spécifier, dans la zone dns, un hash correspondant aux différentes fingerprint utiisé par le serveur ssh "officiel" du domaine en question. Si la zone est de surcroît signée avec dnssec, vous ajoutez ainsi une grosse couche de sécurité à votre installation ssh.

Génération avec ssh-keygen

La syntaxe est simple : ssh-keygen -r <hostname de votre serveur>

ssh-keygen -r wiki.csnu.org.

Cela devrait vous sortir une série de champ DNS que vous pouvez copier directement dans votre zone dns. N'oubliez pas de mettre a jour le SERIAL de la zone et de recharger la zone dans votre serveur dns ensuite.

Génération avec hash-slinger

Pour debian wheezy, vous pouvez télécharger directement le paquet hash-slinger sur le site packages.debian.org. Installez le avec dpkg -i et réglez les dépendances par la suite avec aptitude -f install.

ssh-keyscan -t rsa,dsa,ecdsa wiki.csnu.org. > sshkeys
sshfp -k sshkeys

Cela devrait vous sortir une série de champ DNS que vous pouvez copier directement dans votre zone dns. N'oubliez pas de mettre a jour le SERIAL de la zone et de recharger la zone dans votre serveur dns ensuite.

Forcez la vérification dns sur le client ssh

Par défaut, openssh ne vérifie pas les enregistrements DNS SSHFP. Pour activer la vérification, editez le fihchier de configuration de votre client ssh (~/.ssh/config par exemple) et ajoutez y la ligne suivante :

VerifyHostKeyDNS ask

De cette manière, il sera necessaire que la clé soit confirmée a la fois par dns et par StrictHostKeyChecking. Si vous souhaitez faire confiance automatiquement aux nouvelles clés ssh obtenue par dns (aka ajouter directement la clé dans votre fichier known_hosts sans que celà vous soit demandé), modifiez la ligne de cette manière : VerifyHostKeyDNS yes. Notez que même dans ce cas, ssh n'ajoutera automatiquement la clé QUE si le serveur dns utilisé pour résoudre l'hostname a utilisé dnssec pour authentifier le résultat !