it-swarm.com.de

Welche Bedeutung hat der Benutzer / Host am Ende einer öffentlichen SSH-Schlüsseldatei?

Ich kann nicht herausfinden, warum eine öffentliche SSH-Schlüsseldatei von ssh-keygen haben einen Benutzer und einen Host am Ende.

Beispiel: id_rsa.pub

ssh-rsa ... rest of file ... /CA9gyE8HRhNMG6ZDwyhPBbDfX [email protected]

Beachten Sie die [email protected] am Ende der Datei.

Welche Bedeutung hat root @ mydomain für den Authentifizierungsprozess, wenn ich den öffentlichen Schlüssel überall mit einem Benutzer zur Authentifizierung mit meinem privaten Schlüssel verwenden kann?

Oder ist es nur ein Platzhalter, um herauszufinden, von wem es ausgestellt wurde?

84
Basil A

Dieses Feld ist ein Kommentar und kann nach Belieben geändert oder ignoriert werden. Standardmäßig ist [email protected] Auf ssh-keygen Eingestellt.

Die Manpage OpenSSH sshd(8) beschreibt das Format eines öffentlichen Schlüssels folgendermaßen:

Öffentliche Schlüssel bestehen aus den folgenden durch Leerzeichen getrennten Feldern: Optionen, Schlüsseltyp, Base64-codierter Schlüssel, Kommentar. . . . Das Kommentarfeld wird für nichts verwendet (kann jedoch für den Benutzer praktisch sein, um den Schlüssel zu identifizieren).

Die ssh-keygen(1) Manpage sagt:

Der Schlüsselkommentar kann hilfreich sein, um den Schlüssel zu identifizieren. Der Kommentar wird beim Erstellen des Schlüssels auf "user @ Host" initialisiert, kann jedoch mit der Option -c geändert werden.

118
Michael Hampton

Dies wird auf der Handbuchseite für sshd(8) im Abschnitt über autorisierte Schlüssel kurz erläutert:

Der öffentliche Schlüssel von Protokoll 2 besteht aus: Optionen, Schlüsseltyp , base64-codiert Schlüssel , comment.

Im openssh Kontext autorisierter Schlüssel gibt es nur die Bedeutung eines Kommentars. Es gibt jedoch SSH-Implementierungen, die diesem Teil die Bedeutung geben, da beispielsweise die SSH-Implementierung in LANCOM-Modems diesen Kommentar als Benutzernamen verwendet, für den der Schlüssel gültig ist.

54
Jakuje

Wie andere bereits betont haben, ist es ein Kommentar, mit dem Sie identifizieren können, welcher Schlüssel welcher ist.

Wenn Sie einen einzelnen Schlüssel in z. B. id_rsa.pub es macht keinen großen Unterschied, aber wenn man sich eine möglicherweise lange Liste von Schlüsseln ansieht, wie das, was man in authorized_keys Datei ist es sehr hilfreich, leicht identifizieren zu können, welcher Schlüssel welcher ist.

Ebenfalls, ssh-keygens Standard ist [email protected], was für typische Anwendungsfälle eine eindeutige Kennung des Schlüssels ist ([email protected] würde nicht sein).

17

Sehr, sehr einfach: Ich und Sie sind Menschen, die eine Maschine benutzen. Schauen Sie sich also dieses Beispiel an, das Sie gepostet haben:

ssh-rsa [piles of gobbledygook]…CA9gyE8HRhNMG6ZDwyhPBbDfX [email protected]

Eine Maschine kann dies lesen:

ssh-rsa [piles of gobbledygook]…CA9gyE8HRhNMG6ZDwyhPBbDfX

Ein Mensch kann diesen Kommentar lesen:

[email protected]

Die Leute neigen dazu zu vergessen, dass, obwohl die Dinge auf Computersystemen aussehen kompliziert sein könnten, sie tatsächlich Tonnen komplizierter sein könnten, wenn der Code entworfen wurde nur für Maschinenverbrauch. Ich meine, schauen Sie sich verdeckten Malware-Code an. Sobald Sie es dekodiert und formatiert haben, ist es für den Menschen lesbar. Aber jemand musste sich alle Mühe geben, um es den Menschen schwer zu machen, zu lesen.

Standardmäßig sind alle Arten von Codierungs- und Konfigurationsdateien auf einem Computersystem für den menschlichen Verzehr strukturiert, weil… wir Menschen sind, die Maschinen verwenden, und Maschinen benötigen keine Dinge wie:

  • Bemerkungen.
  • Einrückungen.
  • Variablen und Funktionen, die in einer für Menschen lesbaren Sprache geschrieben sind.

Der Kommentar ist also für dich und mich und sonst niemanden gedacht. Es würde höchstwahrscheinlich ohne Kommentar funktionieren. Aber wenn einmal um 3:00 Uhr etwas nicht funktioniert und Sie nach dem richtigen öffentlichen Schlüssel suchen, werden Sie wünschen/träumen/beten, dass der Kommentar da ist.

5
JakeGould