web-dev-qa-db-fra.com

Quelle est la signification de l'utilisateur / hôte à la fin d'un fichier de clé publique SSH?

Je ne peux pas comprendre pourquoi un fichier de clé publique SSH généré par ssh-keygen avoir un utilisateur et un hôte à la fin.

Exemple: id_rsa.pub

ssh-rsa ... rest of file ... /CA9gyE8HRhNMG6ZDwyhPBbDfX root@mydomain

Remarquez le root@mydomain à la fin du fichier.

Si je peux utiliser la clé publique n'importe où avec n'importe quel utilisateur pour m'authentifier à l'aide de ma clé privée, quelle importance la racine @ mondomaine a-t-elle sur le processus d'authentification?

Ou est-ce juste un espace réservé pour comprendre qui a été délivré par?

84
Basil A

Ce champ est un commentaire et peut être modifié ou ignoré à volonté. Il est défini sur user@Host Par défaut par ssh-keygen.

La page de manuel OpenSSH sshd(8) décrit ainsi le format d'une clé publique:

Les clés publiques se composent des champs séparés par des espaces suivants: options, type de clé, clé encodée en base64, commentaire. . . . Le champ de commentaire n'est utilisé pour rien (mais il peut être pratique pour l'utilisateur d'identifier la clé).

La page de manuel ssh-keygen(1) indique:

Le commentaire clé peut être utile pour aider à identifier la clé. Le commentaire est initialisé à "utilisateur @ hôte" lors de la création de la clé, mais peut être modifié à l'aide de l'option -c.

118
Michael Hampton

Ceci est brièvement expliqué dans la page de manuel pour sshd(8) dans la section sur les touches autorisées:

La clé publique du protocole 2 se compose de: options, type de clé , codé en base64 clé , comment.

Dans le contexte openssh des clés autorisées, il n'y a qu'un sens de commentaire. Mais il existe une implémentation SSH, qui donne le sens à cette partie, car par exemple l'implémentation SSH dans les modems LANCOM utilise ce commentaire comme nom d'utilisateur pour lequel la clé est valide.

54
Jakuje

Comme d'autres l'ont souligné, c'est un commentaire pour permettre à yo d'identifier quelle clé est laquelle.

Lorsque vous regardez une seule clé, par exemple id_rsa.pub cela ne fait pas beaucoup de différence mais quand on regarde une liste potentiellement longue de clés, comme ce que vous avez dans le authorized_keys fichier, il est très utile de pouvoir identifier facilement quelle clé est laquelle.

Aussi, ssh-keygen par défaut est user@hostname, qui pour les cas d'utilisation typiques est un identificateur clair de quelle clé il s'agit (user@domain ne serait pas).

17
Håkan Lindqvist

Très, très simple: vous et moi sommes des humains utilisant une machine. Donc, en regardant cet exemple que vous avez publié:

ssh-rsa [piles of gobbledygook]…CA9gyE8HRhNMG6ZDwyhPBbDfX root@mydomain

Une machine peut lire ceci:

ssh-rsa [piles of gobbledygook]…CA9gyE8HRhNMG6ZDwyhPBbDfX

Un humain peut lire ce commentaire:

root@mydomain

Les gens ont tendance à oublier que même si les choses peuvent regarder compliquées sur les systèmes informatiques, elles pourraient en fait être tonnes plus compliquées si le code a été conçu seulement pour consommation de la machine. Je veux dire, regardez le code du malware obscurci. Une fois décodé et formaté, il est lisible par l'homme. Mais quelqu'un a dû faire tout son possible pour rendre la lecture difficile aux humains.

Par défaut tous les types de fichiers de codage et de configuration sur un système informatique sont structurés pour la consommation humaine parce que ... Nous sommes des humains qui utilisent des machines et les machines n'ont pas besoin de choses comme:

  • Commentaires.
  • Indentations.
  • Variables et fonctions écrites dans un langage lisible par l'homme.

Le commentaire s'adresse donc à vous, à moi et à personne d'autre. Cela fonctionnerait très probablement sans commentaire. Mais cette fois où quelque chose ne fonctionne pas à 3h00 du matin et que vous cherchez la bonne clé publique, vous allez souhaiter/rêver/prier que le commentaire soit là.

5
JakeGould