Faire confiance au serveur SSH basé sur la clé au lieu de si la clé + la correspondance IP

Est-il possible de faire en sorte que le client ssh ne se soucie pas de l'adresse IP derrière laquelle se trouve un serveur ssh (et si un autre serveur était derrière cette adresse IP plus tôt) mais plutôt de faire confiance à des clés de serveur spécifiques? (Et peut-être surnommer ces clés?) J'utilise le DNS dynamique et j'ai des extensions de confidentialité IPv6 activées sur certains ordinateurs et on me demande toujours s'il pense qu'il est sûr de se connecter. Une autre possibilité est que les adresses attribuées par DHCP soient attribuées à différents serveurs ssh et provoquent toutes sortes d'erreurs «clé ne correspond pas à IP».

ssh

— Azendale
source

J'aurais probablement dû également mentionner que j'ai une liste de clés publiques pour chacun de mes serveurs ssh sur une page Web qui est servie via SSL, j'ai donc un moyen facile de vérifier si je fais réellement confiance à un ensemble de clés de serveur spécifique.

— Azendale

Réponses:

Ajoutez un surnom à votre serveur ~/.ssh/configet désactivez-le CheckHostIPpour ce serveur.

Host nickname
HostName example.dyndns.org
CheckHostIP no

Avant de vous connecter au serveur pour la première fois, vous pouvez copier la clé publique hors bande: récupérer /etc/ssh/ssh_host_rsa_key.pubdu serveur, supprimer la root@hostnamepartie à la fin de la ligne, ajouter example.dyndns.orgau début et ajouter la ligne à ~/.ssh/known_hosts. Exécutez éventuellement ssh-keygen -Hpour hacher le nom d'hôte (cela n'est utile que si vous êtes préoccupé par la confidentialité de cette entrée si quelqu'un vole votre disque dur ou vos sauvegardes, ce qui pour 99,99% des personnes est inutile car les informations sont présentes dans un autre à proximité emplacement de toute façon).

— Gilles 'SO- arrête d'être méchant'
source

Avec le Host nickname, cela signifie-t-il que je peux simplement le faire ssh nickname? Si c'est le cas, c'est plutôt bien.

— Azendale

@Azendale: Exactement, c'est une fonctionnalité générale pour donner un surnom à un nom d'hôte et un ensemble d'options (nom d'utilisateur, options booléennes, tunnels,…).

— Gilles 'SO- arrête d'être méchant'

Dans /etc/ssh/ssh_configajoutez la ligne

CheckHostIP no

Cependant, cela enlève un peu de Secure dans SSH, car n'importe quelle machine peut se cacher derrière le nom IP ou DynDNS auquel vous vous connectez.

— htorque
source

Cela n'enlève aucune sécurité. L'intérêt du stockage de la clé d'hôte est d'identifier l'autre ordinateur. Le nom et l'adresse IP ne sont pas pertinents pour la sécurité lorsque vous avez la clé d'hôte. La suppression des faux messages est en fait un gain de sécurité (les faux messages absorbent votre attention, ce qui est une ressource rare).

— Gilles 'SO- arrête d'être méchant'

@Gilles: La page de manuel n'est pas d'accord. Oui, vous ne perdez aucune sécurité pour les connexions où il n'y a pas de relation IP-hôte bien connue, dans d'autres cas, vous abandonnez la protection contre les attaques d'usurpation DNS (comme indiqué dans la page de manuel).

— htorque

Je ne sais pas de quel passage de la page de manuel vous parlez. Si c'est la description de CheckHostIP, alors non, cela ne dit pas que vous abandonnez toute protection. Avec CheckHostIP no, le spoofer doit toujours obtenir la clé privée du serveur, et si elle peut le faire, il est peu probable qu'elle ne puisse pas également usurper son adresse IP de toute façon.

— Gilles 'SO- arrête d'être méchant'

Pouvez-vous me donner un exemple de la façon dont l'usurpation DNS serait dangereuse si je sais que je fais confiance à la clé? J'utilise l'authentification par clé publique pour me connecter, ce qui empêche un serveur malveillant d'obtenir un mot de passe, mais que se passe-t-il si j'utilise des mots de passe?

— Azendale

L'utilisation de l'authentification par clé publique ne protège pas vraiment votre mot de passe, le serveur pourrait vous MITMER et obtenir votre mot de passe lorsque vous sudoou similaire.

— remram