Zum Hauptinhalt springen

7. Public Key Authentication Method: "publickey"

7. Public Key Authentication Method: "publickey"

Der einzige REQUIRED-Authentifizierungs-‚method name‘ ist die Authentifizierung mit „publickey“. Alle Implementierungen MÜSSEN diese Methode unterstützen; nicht alle Benutzer benötigen jedoch öffentliche Schlüssel, und die meisten lokalen Richtlinien werden voraussichtlich in naher Zukunft nicht für alle Benutzer die Authentifizierung mit öffentlichem Schlüssel verlangen.

Bei dieser Methode dient der Besitz eines privaten Schlüssels als Authentifizierung. Die Methode funktioniert durch Senden einer mit dem privaten Schlüssel des Benutzers erstellten Signatur. Der Server MUSS prüfen, ob der Schlüssel ein gültiger Authentifikator für den Benutzer ist, und MUSS prüfen, ob die Signatur gültig ist. Sind beide Bedingungen erfüllt, MUSS die Authentifizierungsanfrage akzeptiert werden; andernfalls MUSS sie abgelehnt werden. Beachten Sie, dass der Server nach erfolgreicher Authentifizierung zusätzliche Authentifizierungen verlangen KANN.

Private Schlüssel werden auf dem Client-Host oft verschlüsselt gespeichert, und der Benutzer MUSS eine Passphrase angeben, bevor die Signatur erzeugt werden kann. Selbst wenn nicht, umfasst der Signiervorgang aufwendige Berechnungen. Um unnötige Verarbeitung und Benutzerinteraktion zu vermeiden, wird die folgende Nachricht bereitgestellt, um abzufragen, ob eine Authentifizierung mit der Methode „publickey“ akzeptabel wäre.

byte      SSH_MSG_USERAUTH_REQUEST
string user name in ISO-10646 UTF-8 encoding [RFC3629]
string service name in US-ASCII
string "publickey"
boolean FALSE
string public key algorithm name
string public key blob

Öffentliche Schlüsselalgorithmen sind in der Transportspezifikation [SSH-TRANS] definiert. Der ‚public key blob‘ KANN Zertifikate enthalten.

Jeder öffentliche Schlüsselalgorithmus KANN zur Authentifizierung angeboten werden. Insbesondere ist die Liste nicht durch das beim Schlüsselaustausch Ausgehandelte beschränkt. Unterstützt der Server einen Algorithmus nicht, MUSS er die Anfrage einfach ablehnen.

Der Server MUSS auf diese Nachricht entweder mit SSH_MSG_USERAUTH_FAILURE oder mit Folgendem antworten:

byte      SSH_MSG_USERAUTH_PK_OK
string public key algorithm name from the request
string public key blob from the request

Um die eigentliche Authentifizierung durchzuführen, KANN der Client dann eine mit dem privaten Schlüssel erzeugte Signatur senden. Der Client KANN die Signatur direkt senden, ohne zuvor zu prüfen, ob der Schlüssel akzeptabel ist. Die Signatur wird im folgenden Paket gesendet:

byte      SSH_MSG_USERAUTH_REQUEST
string user name
string service name
string "publickey"
boolean TRUE
string public key algorithm name
string public key to be used for authentication
string signature

Der Wert von ‚signature‘ ist eine Signatur mit dem entsprechenden privaten Schlüssel über die folgenden Daten in dieser Reihenfolge:

string    session identifier
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service name
string "publickey"
boolean TRUE
string public key algorithm name
string public key to be used for authentication

Empfängt der Server diese Nachricht, MUSS er prüfen, ob der gelieferte Schlüssel für die Authentifizierung akzeptabel ist, und wenn ja, MUSS er prüfen, ob die Signatur korrekt ist.

Gelingen beide Prüfungen, ist diese Methode erfolgreich. Beachten Sie, dass der Server zusätzliche Authentifizierungen verlangen KANN. Der Server MUSS mit SSH_MSG_USERAUTH_SUCCESS antworten (wenn keine weiteren Authentifizierungen nötig sind), oder mit SSH_MSG_USERAUTH_FAILURE (wenn die Anfrage fehlschlug oder weitere Authentifizierungen nötig sind).

Die folgenden methodenspezifischen Nachrichtennummern werden von der Authentifizierungsmethode „publickey“ verwendet.

SSH_MSG_USERAUTH_PK_OK              60