Je sais ce que ça fait, mais je ne sais pas pourquoi . Quelles attaques empêche-t-il?
Est-ce pertinent pour tous les types de méthodes d'authentification? (hôte, mot de passe, publickey, clavier interactif ...)
Réponses:
L' UseDNSoption est la plupart du temps inutile. Si les ordinateurs clients sont présents sur Internet, ils risquent fort de ne pas avoir de DNS inversé, leur DNS inversé ne se résout pas, ou leur DNS ne fournit aucune information autre que «appartient à cette ISP ”que l'adresse IP vous indique déjà.
Dans les configurations classiques, DNS n’est utilisé que pour la journalisation. Il peut être utilisé pour l'authentification, mais uniquement si IgnoreRhosts noest spécifié dans sshd_config. Ceci est pour la compatibilité avec les anciennes installations qui utilisent rsh, où vous pouvez dire « l'utilisateur appelé bobsur la machine appelée darkstarpeut se connecter comme alicesans montrer les informations d' identification » (en écrivant darkstar bobdans ~alice/.rhosts). Ce n'est sécurisé que si vous faites confiance à toutes les machines susceptibles de se connecter au serveur ssh. En d'autres termes, ceci est très très rarement utilisable de manière sécurisée.
Étant donné que la recherche DNS ne fournit aucune information utile, sauf dans des circonstances très particulières, elle doit être désactivée. Autant que je sache, la seule raison pour laquelle il est activé par défaut est son technicité plus sûre (si vous vous souciez de l'authentification, pas de la disponibilité), même si cela ne s'applique qu'à une infime série de circonstances.
Un autre argument pour désactiver cette fonctionnalité est que chaque fonctionnalité superflue constitue un risque inutile pour la sécurité .
UseDNSn'est même pas utile si vous utilisez l' authentification d'hôte basée sur une clé , uniquement si vous utilisez l'authentification d'hôte basée sur un nom d'hôte (c'est-à-dire une authentification extrêmement faible).
UseDNSest très utile et essentiel. Vous authentifiez un utilisateur en fonction de la clé et le serveur en fonction du nom d'hôte, attribué à une adresse MAC.
J'ai ajouté à un rapport de bogue (ancien mais toujours actuel) à ce sujet dans Ubuntu.
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/424371
J'ai proposé de changer la valeur par défaut en Non et d'ajouter de la documentation plus récente:
# UseDNS - Determines whether IP Address to Hostname lookup and comparison is performed
# Default value is No which avoids login delays when the remote client's DNS cannot be resolved
# Value of No implies that the usage of "from=" in authorized_keys will not support DNS host names but only IP addresses.
# Value of Yes supports host names in "from=" for authorized_keys. Additionally if the remote client's IP address does not match the resolved DNS host name (or could not be reverse lookup resolved) then a warning is logged.
De la page de manuel de sshd_config(5):
UseDNS Specifies whether sshd(8) should look up the remote host name and
check that the resolved host name for the remote IP address maps
back to the very same IP address. The default is “yes”.
Si vous activez cette option, l'accès depuis un emplacement sans DNS approprié (avant et arrière) génère un avertissement dans les journaux.
Donc, cela n'empêche aucune attaque, sauf qu'il aurait besoin d'une adresse distante qualifiée du client afin de ne pas enregistrer d'avertissement. Un tel avertissement peut vous aider à identifier l’attaquant uniquement si cet enregistrement PTR a un sens.
edit: mis à jour selon le commentaire de Andrey Voitenkov .
from=champ avant la clé autorisée en question (si elle est utilisée).
Cela est nécessaire lorsque vous utilisez l'option FROM dans un fichier allowed_keys et que vous souhaitez filtrer par noms et pas uniquement par les adresses IP.
L'option FROM dans une ligne d'un fichier allowed_keys vous permet de limiter les hôtes pouvant utiliser une clé spécifique.
Cela augmente la capacité de gérer plusieurs serveurs ayant accès les uns aux autres sans permettre aux clones d'une machine d'emprunter l'identité de son origine, généralement par inadvertance (restes de crontabs, erreur humaine).
J'aimerais ajouter que sur CentOS 7 (7.1.1503) et donc Red Hat Enterprise Linux 7, je ne pouvais pas me connecter avec le paramètre par défaut de yespour UseDNS. Après avoir supprimé le commentaire et l'avoir réglé sur no, j'ai pu me connecter. Il semble donc que le service peut être refusé si le DNS ne fonctionne pas correctement! Dans CentOS 6, il semble que la valeur par défaut soit noet par conséquent, je peux sshentrer sans DNS actif!
J'aimerais ajouter que mes expériences ont été menées sur des conteneurs LXC et non sur des machines physiques, au cas où cela ferait une différence!