it-swarm.com.de

Öffentlicher SSH-Schlüssel - Keine unterstützten Authentifizierungsmethoden verfügbar (Server hat öffentlichen Schlüssel gesendet)

Ich habe eine 12.10-Serverkonfiguration in einer virtuellen Maschine, deren Netzwerk auf Bridged eingestellt ist (im Wesentlichen wird dies als Computer angesehen, der mit meinem Switch verbunden ist).

Ich habe opensshd über apt-get installiert und konnte mit PuTTY und meinem Benutzernamen und Passwort eine Verbindung zum Server herstellen.

Ich machte mich dann daran zu versuchen, ihn dazu zu bringen, die Authentifizierung mit öffentlichen/privaten Schlüsseln zu verwenden. Ich habe folgendes gemacht:

  1. Generierte die Schlüssel mit PuttyGen.
  2. Verschob den öffentlichen Schlüssel nach /etc/ssh/myusername/authorized_keys (ich verwende verschlüsselte Home-Verzeichnisse).
  3. Richten Sie sshd_config folgendermaßen ein:

    PubkeyAuthentication yes
    AuthorizedKeysFile /etc/ssh/%u/authorized_keys
    StrictModes no
    PasswordAuthentication no
    UsePAM yes
    

Wenn ich mit PuTTY oder WinSCP eine Verbindung herstelle, wird die Fehlermeldung "Keine unterstützten Authentifizierungsmethoden verfügbar" angezeigt (Server hat öffentlichen Schlüssel gesendet).

Wenn ich sshd im Debug-Modus ausführe, sehe ich:

PAM: initializing for "username"
PAM: setting PAM_RHOST to "192.168.1.7"
PAM: setting PAM_TTY to "ssh"
userauth-request for user username service ssh-connection method publickey [preauth]
attempt 1 failures 0 [preauth]
test whether pkalg/pkblob are acceptable [preauth[
Checking blacklist file /usr/share/ssh/blacklist.RSA-1023
Checking blacklist file /etc/ssh/blacklist.RSA-1023
temporarily_use_uid: 1000/1000 (e=0/0)
trying public key file /etc/ssh/username/authorized_keys
fd4 clearing O_NONBLOCK
restore_uid: 0/0
Failed publickey for username from 192.168.1.7 port 14343 ssh2
Received disconnect from 192.168.1.7: 14: No supported authentication methods available [preauth]
do_cleanup [preauth]
monitor_read_log: child log fd closed
do_cleanup
PAM: cleanup

Warum passiert das und wie kann ich das beheben?

78
F21

Problem gelöst:

Anscheinend ist ein Problem mit meiner öffentlichen Schlüsseldatei aufgetreten. PuttyGen erstellt eine öffentliche Schlüsseldatei, die wie folgt aussieht:

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20121022"
AAAAB3NzaC1yc2EAAAABJQAAAIEAhGF6GIuMY8FJ1+CNApnSY1N2YSlkYz72Yvwu
a6N1nFpBklz1+dsIMg4rcTLcF34M/tW5Yz+NUDAw2AEbxQ32FPgw7sAOIXktkYOH
tr7mmimiTjkoSCrJh1kqalPSpi8rglT/Bp67Ql2SZwvUFfMzHISryR0EZC4rXP/u
vObrJe8=
---- END SSH2 PUBLIC KEY ----

Dies funktioniert jedoch nicht. Sie müssen also den Schlüssel in PuttyGen öffnen und von dort kopieren (dies führt dazu, dass der Schlüssel das richtige Format und eine Zeile aufweist):

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIEAhGF6GIuMY8FJ1+CNApnSY1N2YSlkYz72Yvwua6N1nFpBklz1+dsIMg4rcTLcF34M/tW5Yz+NUDAw2AEbxQ32FPgw7sAOIXktkYOHtr7mmimiTjkoSCrJh1kqalPSpi8rglT/Bp67Ql2SZwvUFfMzHISryR0EZC4rXP/uvObrJe8= rsa-key-20121022

Fügen Sie dies in authorized_keys ein, dann sollte es funktionieren.

70
F21
  1. Bearbeiten Sie die Datei /etc/ssh/sshd_config.
  2. Ändern Sie PasswordAuthentication und ChallengeResponseAuthentication in yes.

3a. Starten Sie ssh /etc/init.d/ssh restart neu.
ODER
3b. besser du verwendest service sshd restart

17
Hunter

Nur ein Tipp, von dem ich hoffe, dass er jemand anderem bei den Kopfschmerzen hilft, die ich hatte. F21 ist richtig, dass Sie den Schlüssel aus dem PuTTYGen-Fenster kopieren müssen, anstatt die Datei zu speichern. Nach dem Kopieren kann die Art des Einfügens jedoch erhebliche Auswirkungen darauf haben, ob Ihr Schlüssel funktioniert oder nicht. Einige Editoren ändern den Text beim Einfügen oder machen etwas mit Zeilenumbrüchen oder etwas, das die authorized_keys-Datei ungültig macht.

Was ich als am wenigsten anfällig empfunden habe, ist das Echo der gesamten Zeichenfolge und die Umleitung der Ausgabe in die Datei. Wenn Sie mit der rechten Maustaste auf PuTTY klicken, um die Schlüsselzeichenfolge in die Befehlszeile einzufügen, sieht dies folgendermaßen aus (im obigen Beispiel):

echo [right-click-to-paste-here] > /etc/ssh/username/authorized_keys

Sie werden am Ende mit diesem:

echo ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIEAhGF6GIuMY8FJ1+CNApnSY1N2YSlkYz72Yvwua6N1nFpBklz1+dsIMg4rcTLcF34M/tW5Yz+NUDAw2AEbxQ32FPgw7sAOIXktkYOHtr7mmimiTjkoSCrJh1kqalPSpi8rglT/Bp67Ql2SZwvUFfMzHISryR0EZC4rXP/uvObrJe8= rsa-key-20121022 > /etc/ssh/username/authorized_keys

Ein weiterer Vorteil dieser Methode ist, dass Sie auf diese Weise mehrere Schlüssel hinzufügen können, indem Sie >> zum Anhängen anstelle von> zum Überschreiben verwenden. Beispiel:

echo ssh-rsa AAAAB3<...snip...>rJe8= rsa-key-20121022 >> /etc/ssh/username

Hoffe das hilft jemandem.

9
Dave

Wir haben bereits den richtigen Schlüsseltyp verwendet (ppk statt pem).

In unserem Fall war es ein Problem mit den Dateiberechtigungen für authorized_keys im Serverbenutzerordner. Es muss -rw-r - r-- sein ... Es war -rw-rw-r--

ssh ist sehr pingelig in Bezug auf Datei-Perms.

8
Sharad

In meinem Fall lag der Grund darin, dass die private Schlüsseldatei (.ppk) im PuTTY-Authentifizierungsagenten, d. H. Pageant, entfernt wurde. Ich habe es gerade wieder auf Pageant aktualisiert und die Verbindung hat danach einwandfrei funktioniert.

5
Marko H

Gelöst:

  1. Sie müssen den puttyGEN herunterladen und einen öffentlichen und einen privaten Schlüssel generieren.
  2. Ich habe meinem privaten Schlüssel ein Passwort zugewiesen.
  3. konfigurieren Sie dann den privaten Schlüssel in PuTTY. PuTTY-> SSH-> Auth-> Navigieren Sie zu Ihrem privaten.
  4. Stellen Sie sicher, dass Sie für den privaten und den öffentlichen Schlüssel denselben Pfad verwenden.
  5. Sie müssen den öffentlichen Schlüssel auf dem Server konfigurieren. (In meinem Fall habe ich mit dem Server gesprochen und gefragt, ob er meinen öffentlichen Schlüssel zum Server hinzufügen kann.) Sie benötigen den öffentlichen Schlüssel auf der anderen Seite (Server) der Verbindung.
5
Matt.sinner