Le message «l'authenticité de l'hôte ne peut pas être établie» dans SSH reflète-t-il un risque de sécurité?

Chaque fois que je me connecte à un nouveau serveur SSH depuis mon ordinateur, je reçois ce message:

The authenticity of host '[censored]:censored ([0.0.0.0]:censored)' can't be established.
RSA key fingerprint is SHA256:censored.
Are you sure you want to continue connecting (yes/no)?

Pourquoi SSH me le demande?

Ai-je un risque de me connecter à un serveur SSH aléatoire?

Ou est-ce juste pour s'assurer que le serveur auquel vous vous connectez n'a pas été piraté?

ssh internet-security

— Charles Duffy
source

Utilisez-vous un mot de passe ou une clé pour vous connecter?

— kasperd

Il existe plusieurs meilleures façons de distribuer les clés d'hôte que la confiance lors de la première utilisation; il s'agit d'un flux de travail relativement peu sûr. Les clés d'hôte peuvent être distribuées via LDAP; via des entrées DNS signées; peut être signé avec les autorités de certification SSH; etc. Ce qui veut dire - ce que vous voyez ici indique que votre site est configuré "à la manière paresseuse" (ce qui est presque tous le cas!), ce qui est moins sûr que d'aller plus loin pour bien faire les choses.

— Charles Duffy

Réponses:

Il vous le demande car il n'est jamais connecté à cet hôte auparavant.

Si vous êtes dans un environnement sécurisé, vous connaîtrez l'empreinte digitale de l'hôte distant et la comparerez lors de la première connexion - si l'empreinte correspond à ce que vous savez qu'elle devrait être, alors parfait. Si vous êtes dans un environnement moins sécurisé, vous pouvez simplement l'accepter lors de la première connexion.

Une fois que vous avez dit " Oui, je fais confiance à cette clé d'hôte et je veux qu'elle soit associée à ce nom d'hôte / IP ", le client SSH s'en souviendra pour vous ... Si pour une raison quelconque (réinstallez / nouvelles clés d'hôte / nouveau machine / homme au milieu) la clé ne correspond pas lors d'une connexion ultérieure, vous verrez un avertissement comme ci-dessous:

$ ssh baloo
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:Su0uy/4BcRcpmyLfxO9ndlcda52F8uct6yWNp7Sa92M.
Please contact your system administrator.
Add correct host key in /home/attie/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/attie/.ssh/known_hosts:65
  remove with:
  ssh-keygen -f "/home/attie/.ssh/known_hosts" -R baloo
ECDSA host key for baloo has changed and you have requested strict checking.
Host key verification failed.

Dans cette situation, si vous savez que l'hôte distant a bien été changé, vous pouvez continuer ... en vérifiant éventuellement que l'empreinte digitale est correcte.

Si vous n'êtes pas sûr ou si vous savez que l'hôte distant n'aurait pas dû changer, cela vous indiquera une attaque potentielle.

— Attie
source

C'est le principe TOFU: Trust On First Use

— Trust Mevzek

D'accord, TOFU n'est pas une bonne idée - surtout si vous devez être sûr ... Votre opinion et votre approche dépendront (devraient) de votre modèle de thread.

— Attie

Cependant, pour l'efficacité de cela, voir cs.auckland.ac.nz/~pgut001/pubs/defending.pdf , pages 45-48.

— Joker_vD

Diapositives intéressantes, merci pour le partage @Joker_vD

— Attie

@PatrickMevzek Le problème est que notre modèle entier de "confiance" informatique est fondamentalement à la granularité d'un booléen, alors que dans le monde réel un modèle pratique de confiance (comme ce que nous utilisons intuitivement dans les relations inter-humaines) ressemble plus à un probabilité conditionnelle: étant donné une réclamation d'une entité, nous avons un certain degré de confiance que l'entité la suivra et nous limitons notre exposition au risque proportionnellement à cela.

— mtraceur

Lorsque vous recevez ce message, SSH dit simplement "Je n'ai jamais vu cet ordinateur auparavant, donc je ne peux pas être sûr que c'est qui il dit. Faites-vous confiance?" À quel moment vous pouvez dire que vous lui faites confiance et que votre ordinateur s'en souviendra et ne vous le demandera plus à l'avenir.

Idéalement, pour lui faire confiance, vous devez comparer manuellement la clé fournie avec la clé sur le serveur (comme vous feriez confiance à une clé GPG en vérifiant que la personne à qui vous pensez qu'elle appartient peut réellement générer la clé publique). Bien qu'en réalité, les gens ne se soucient pas de cela (du moins à ma connaissance).

Le véritable avantage vient de chaque fois que vous vous connectez au serveur. Si SSH se plaint que le serveur auquel vous avez déjà fait confiance n'est pas le même serveur, il est possible que vous soyez victime d'une attaque MiTM.

Dans l'ensemble, si vous êtes sur un réseau où vous êtes sûr qu'il n'y a pas d'attaque Man in The Middle en cours et que c'est la première fois que vous vous connectez à l'ordinateur, vous devez être sûr d'accepter la clé. (bien que si vous travaillez sur une mission gouvernementale top secrète, demandez peut-être à votre administrateur système de vérifier l'empreinte digitale avant de vous connecter)

— KNejad
source