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é .
Donc, UseDNS n’est pertinent que pour l’authentification basée sur l’hôte? Si je n'utilise pas l'authentification basée sur l'hôte et que je ne me soucie pas de savoir si le nom d'hôte ou l'adresse IP apparaît dans les journaux, UseDNS ne fait aucune différence?
user368507
5
@ user368507 Oui, c'est tout. 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).
Gilles, arrête d'être méchant
3
@Gilles bien sûr, si vous utilisez une authentification basée sur une clé et sur un nom d’hôte, 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.
Kara deniz
38
J'ai ajouté à un rapport de bogue (ancien mais toujours actuel) à ce sujet dans Ubuntu.
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.
Up upvote ... ceci est plus utile, car il contient une information que je cherchais.
0xC0000022L
1
De même, si UseDNS est no, les noms d'hôte ne peuvent pas être mis en correspondance dans les règles pam_access et les adresses IP doivent être utilisées à la place.
ColinM
1
J'ai voté en faveur de cette réponse il y a quelques années, mais ce n'est qu'aujourd'hui que j'ai remarqué que la valeur par défaut était "UseDNS no" dans OpenSSH 6.8p1, qui est disponible dans Ubuntu 15.10 et versions ultérieures .
Anthony G - justice pour Monica
RedHat (dans RHEL7) a récemment changé la valeur par défaut en non plus, ce qui rompt les contrôles d'accès basés sur le nom d'hôte (qui sont utiles en tant que contrôles principalement consultatifs sur un intranet, et non en tant que seul mécanisme de contrôle d'accès).
dannysauer
8
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.
C'est donc un filtre sur qui est autorisé à se connecter en fonction de ce qu'il y a dans le serveur DNS?
user368507
2
Pourquoi rendrait-il l'accès impossible? sshd génère simplement un avertissement si les enregistrements DNS A / PTR ne correspondent pas. La séquence de connexion sera lente en cas de résolution de problèmes.
Andrey Voitenkov
Cela empêche l'accès si la clé autorisée a été compromise tant que l'attaquant ne peut pas usurper les valeurs du from=champ avant la clé autorisée en question (si elle est utilisée).
Alecz
7
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!
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é danssshd_config. Ceci est pour la compatibilité avec les anciennes installations qui utilisent rsh, où vous pouvez dire « l'utilisateur appelébobsur la machine appeléedarkstarpeut se connecter commealicesans montrer les informations d' identification » (en écrivantdarkstar 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é .
la source
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:
la source
De la page de manuel de
sshd_config(5):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 .
la source
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).
la source
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
yespourUseDNS. Après avoir supprimé le commentaire et l'avoir réglé surno, 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 soitnoet par conséquent, je peuxsshentrer 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!
la source