☰

authorized_keys hat meinen Schlüssel, aber er wird trotzdem abgelehnt

tag-icon • tag-icon ssh authentication public-key
authorized_keys hat meinen Schlüssel, aber er wird trotzdem abgelehnt

Ich verbinde mich per SSH von Maschine M1 zu Maschine M2 (mit demselben Benutzer auf der anderen Maschine). Ich sollte auch erwähnen, dass der Benutzer auf beiden Maschinen denselben Schlüssel verwendet. Mit der Kennwortauthentifizierung funktioniert alles einwandfrei; mit der Authentifizierung mit öffentlichem Schlüssel nicht; ich habe sichergestellt, dass ~/.ssh/authorized_keysauf M2 der RSA-Schlüssel als autorisiert gilt, aber trotzdem greift SSH auf die Kennwortauthentifizierung zurück. Ich erhalte Folgendes ssh -vvv:

debug2: key: /home/joeuser/.ssh/id_rsa (0x7f42679e8200),
debug2: key: /home/joeuser/.ssh/id_dsa ((nil)),
debug2: key: /home/joeuser/.ssh/id_ecdsa ((nil)),
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/joeuser/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /home/joeuser/.ssh/id_dsa
debug3: no such identity: /home/joeuser/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/joeuser/.ssh/id_ecdsa
debug3: no such identity: /home/joeuser/.ssh/id_ecdsa: No such file or directory
debug2: we did not send a packet, disable method

Ich sollte erwähnen, dass ichBinMöglichkeit zur Verbindung mithilfe der Public-Key-Authentifizierung von anderen Rechnern (nicht mit demselben Schlüssel).

Was sind die möglichen Gründe dafür, dass die schlüsselbasierte Authentifizierung in diesem Fall fehlschlägt?

Hinweis: Bei beiden Maschinen handelt es sich um SLES (SuSE Linux Enterprise Server) 11.

Antwort1

Sie haben das Richtige getan ssh -vvv, indem Sie es vom Client aus verwendet und es mit einem SSHD im Debugmodus gekoppelt haben, und zwar wie folgt:

eine zweite Serverinstanz: # /usr/sbin/sshd -p 1234 -dddd

ein dedizierter Client zum Verbinden: $ ssh -i .ssh/id_rsa-admuser admuser@server -p 1234 -vvvv

In meinem Fall stellte sich heraus, dass die entscheidenden Informationen nur auf dem Client ausgedruckt wurden. Der Server durchlief

debug2: user_key_allowed: check options...
debug2: user_key_allowed: advance ...
debug2: key not found

während der Kunde Folgendes vorschlug:

debug1: Next authentication method: publickey
debug1: Offering public key: .ssh/id_rsa-admuser RSA SHA256:<censored> explicit agent
debug1: send_pubkey_test: no mutual signature algorithm

Also, was war hier los?

Der Server war so alt, dass sie keinen Hilfsalgorithmus aushandeln konnten; der Schlüssel war auchdatiert, aber im Allgemeinen in Ordnung.

Was wäre nun die grundsätzliche Vorgehensweise?

  1. dedizierten Server auf einem anderen Port starten
  2. In neuer Sitzung vom Client aus verbinden
  3. Vergleichen Sie den Schlüsselaustausch auf beiden Seiten, Schritt für Schritt
  4. Validieren Sie die Ergebnisse mithilfe eines neu generierten zweiten Schlüsselpaars

In diesem konkreten Beispiel gab es eine klare Erklärung, dass es sich um eine unsichere alte Methode handelte, die veraltet war, d. h. hier beschrieben wurde. https://confluence.atlassian.com/bitbucketserverkb/ssh-rsa-key-rejected-with-message-no-mutual-signature-algorithm-1026057701.html

Um diese alte Box aktualisieren zu können, könnte ich eine Verbindung herstellen, indem ich sie -o PubkeyAcceptedKeyTypes=+ssh-rsazur SSH-Befehlszeile auf dem Client hinzufüge.

Antwort2

Überprüfen Sie die Grundlagen:

  1. id_rsa und id_rsa.pub existieren sowohl auf M1 als auch auf M2
  2. id_rsa hat die Berechtigung 600 (d. h. nur der Eigentümer kann lesen und schreiben) auf M1 und M2
  3. In die Datei authorized_keys wird der Schlüssel als einzelne Zeile eingefügt (kein Zeilenumbruch)
  4. Die Berechtigung für autorisierte Schlüssel beträgt 600
  5. Normalerweise beträgt die Berechtigung für meinen .ssh-Ordner 600 (Standard).
  6. Überprüfen Sie die Berechtigung jedes Ordners /home bis hin zu .ssh
  7. Ich weiß, dass Sie RSA verwenden möchten, aber probieren Sie den DSA-Schlüssel aus und sehen Sie, ob es funktioniert. Wenn ja, haben wir die SSH- und RSA-Konfiguration auf Null gesetzt.

Antwort3

Der Fehler, den Sie erhalten, ist

/home/joeuser/.ssh/id_dsa: No such file or directory

Stellen Sie sicher, dass diese Datei vorhanden ist und den privaten Schlüssel enthält, der dem von Ihnen hinzugefügten öffentlichen Schlüssel entspricht, und dass sie dem Benutzer gehört joeuserund über 600Benutzerberechtigungen verfügt:

sudo chown joeuser /home/joeuser/.ssh/id_dsa
sudo chmod 600 /home/joeuser/.ssh/id_dsa

Sie sollten auch versuchen, den privaten Schlüssel folgendermaßen explizit zu definieren:

ssh -i ~/.ssh/id_rsa [email protected]

Wenn Sie nicht sicher sind, ob dies der richtige Schlüssel ist, empfehle ich, ein neues RSA-Schlüsselpaar zu erstellen

ssh-keygen -b 4096

und füge den Inhalt des öffentlichen Schlüssels ~/.ssh/id_rsa.pubzur Datei authorized_keys des Remote-Servers hinzu. Achte darauf, dass du keinen bestehenden privaten Schlüssel überschreibst, den du noch zum Anmelden bei anderen Servern benötigst!

verwandte Informationen