SSH-Schlüssel vom Host akzeptiert, Client jedoch getrennt

Helo,

Ich habe ein Problem mit SSH nach der Installation von Fedora 23.

Wenn ich keine Verbindung zu meinem Remote-Host mit privatem Schlüssel herstellen möchte, findet mein Host den Schlüssel:

debug1: matching key found: file /home/theo/.ssh/authorized_keys, line 1 RSA {REDACTED}
debug1: restore_uid: 0/0
Postponed publickey for theo from {REDACTED} port 60351 ssh2 [preauth]
Connection closed by {REDACTED} [preauth]
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed

Aber wie Sie sehen, trennt sich mein Client von selbst

debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tbouge/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 1047
debug2: input_userauth_pk_ok: fp SHA256:{REDACTED}
debug3: sign_and_send_pubkey: RSA SHA256:{REDACTED}
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

Ich kann mit Kitt unter Windows mit demselben privaten Schlüssel eine Verbindung zu meinem Host herstellen und mit einem anderen privaten Schlüssel eine Verbindung mit meinem Telefon herstellen.

Hast du irgendeine Idee ?

/ etc / ssh / ssh_conf

Host *
        GSSAPIAuthentication yes
# If this option is set to yes then remote X11 clients will have full access
# to the original X11 display. As virtually no X11 client supports the untrusted
# mode correctly we set this to yes.
        ForwardX11Trusted yes
# Send locale-related environment variables
        SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
        SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
        SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE
        SendEnv XMODIFIERS

Danke

Bearbeiten: Ich kann mich mit einem Passwort verbinden

Erstens gibt es zahlreiche, sehr gut geschriebene, detaillierte Dokumentationen zum Einrichten oder Konfigurieren der Authentifizierung auf Basis öffentlicher Schlüssel, die online verfügbar sind. Bitte schauen Sie sich einen an und sehen Sie, ob Sie alles richtig verfolgt haben. Hier ist einer. Also werde ich das nicht noch einmal wiederholen.

Das Grundkonzept ist (von hier kopiert ):

Die schlüsselbasierte Authentifizierung verwendet zwei Schlüssel, einen "öffentlichen" Schlüssel, den jeder sehen darf, und einen anderen "privaten" Schlüssel, den nur der Eigentümer sehen darf. Um sicher über die schlüsselbasierte Authentifizierung zu kommunizieren, muss ein Schlüsselpaar erstellt, der private Schlüssel sicher auf dem Computer gespeichert werden, von dem aus Sie sich anmelden möchten, und der öffentliche Schlüssel auf dem Computer gespeichert werden, bei dem Sie sich anmelden möchten.

Nun aus dem Debug-Protokoll, das Sie gepostet haben:

• Es scheint, dass zwei verschiedene Benutzer beteiligt sind. /home/theo/.ssh/authorized_keysund /home/tbouge/.ssh/id_rsa. Versuchen Sie, sich als ein Benutzer im Home-Verzeichnis eines anderen Benutzers anzumelden?
• Der Fehler Postponed publickey for theo..bedeutet, dass unerwünschte Authentifizierungsmethoden vor der Publick-Key-Methode ausprobiert wurden. SSH versucht nacheinander jede in config aktivierte Authentifizierungsmethode. In Ihrem Fall haben Sie GSSAPIAuthentication yesaktiviert, was Sie nicht verwenden. Sie können es sicher deaktivieren, indem Sie dies tun GSSAPIAuthentication no.
• debug2: we did not send a packet, disable methodist höchstwahrscheinlich, dass es die private Schlüsseldatei nicht verarbeiten kann (entweder Dateiberechtigung oder Namensproblem). SSH reagiert sehr empfindlich auf Verzeichnis- und Dateiberechtigungen auf lokalen und Remotecomputern. ( chown user_name:user_group -R /home/user, chmod 700 /home/.ssh, chmod 600 /home/.ssh/authorized_keys). Stellen Sie also sicher, dass Ihre richtig eingestellt sind. Siehe hierzu: /unix/131886/ssh-public-key-wont-send-to-server

• Was den dritten Fehler betrifft: Permission denied (public key).Es gibt einige Dinge zu überprüfen.

  • Falscher Benutzername
  • Falsches Schlüsselpaar

  • Falscher Zielhost

    • Hier sind weitere Details: /programming/18551556/permission-denied-publickey-when-ssh-access-to-amazon-ec2-instance .

Der folgende Teil ist etwas verwirrend:

debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 1047
debug2: input_userauth_pk_ok: fp SHA256:{REDACTED}
debug3: sign_and_send_pubkey: RSA SHA256:{REDACTED}
debug2: we did not send a packet, disable method

Um es besser zu verstehen, führen wir den Authentifizierungsprozess Schritt für Schritt durch, wie hier bei digitalocean beschrieben :

1. Der Client sendet zunächst eine ID für das Schlüsselpaar, mit dem er sich authentifizieren möchte, an den Server.
2. Der Server überprüft die Datei "authorized_keys" des Kontos, bei dem der Client versucht, sich für die Schlüssel-ID anzumelden.
3. Wenn in der Datei ein öffentlicher Schlüssel mit übereinstimmender ID gefunden wird, generiert der Server eine Zufallszahl und verwendet den öffentlichen Schlüssel zum Verschlüsseln der Nummer.
4. Der Server sendet dem Client diese verschlüsselte Nachricht.
5. Wenn dem Client tatsächlich der zugeordnete private Schlüssel zugeordnet ist, kann er die Nachricht mit diesem Schlüssel entschlüsseln und die ursprüngliche Nummer anzeigen.
6. Der Client kombiniert die entschlüsselte Nummer mit dem gemeinsam genutzten Sitzungsschlüssel, der zum Verschlüsseln der Kommunikation verwendet wird, und berechnet den MD5-Hash dieses Werts.
7. Der Client sendet diesen MD5-Hash dann als Antwort auf die Nachricht mit der verschlüsselten Nummer an den Server zurück.
8. Der Server verwendet denselben gemeinsam genutzten Sitzungsschlüssel und die ursprüngliche Nummer, die er an den Client gesendet hat, um den MD5-Wert selbst zu berechnen. Es vergleicht seine eigene Berechnung mit der, die der Client zurückgeschickt hat. Wenn diese beiden Werte übereinstimmen, wird nachgewiesen, dass der Client im Besitz des privaten Schlüssels war und der Client authentifiziert ist.

Wie Sie sehen, hat der Remotecomputer in Ihrem Fall nur Ihr public keyPaket akzeptiert , das Paket mit diesem Schlüssel verschlüsselt und an den Clientcomputer zurückgesendet. Jetzt muss der Client-Computer beweisen, dass er das Recht hat private key. Mit nur dem richtigen private_key kann es die empfangene Nachricht entschlüsseln und eine Antwort zurücksenden. In diesem Fall tut der Client dies nicht und der Authentifizierungsprozess wird ohne Erfolg beendet.

Ich hoffe, dies hilft Ihnen, die Probleme zu verstehen und zu lösen.

Sind die Berechtigungen für Ihre SSH-Dateien korrekt?

.ssh Ordner -> 700

öffentlicher Schlüssel -> 644

privater Schlüssel -> 600

Überprüfen Sie auch Benutzer und Gruppe

Sie sagen, Sie haben denselben Schlüssel auf einem Windows-Computer. Sind Sie sicher, dass die private Schlüsseldatei, die Sie auf Ihrem Linux-Computer haben, korrekt ist? Möglicherweise liegt der private Schlüssel in einem Kittformat vor, das ssh nicht leicht versteht. In jedem Fall erhalte ich genau den Fehler, den Sie haben, wenn ich eine falsche oder ungültige private Schlüsseldatei eingefügt habe.

Um das Problem zu beheben, ist es besser, einen neuen Schlüssel auf dem Linux-Computer zu generieren, als einen Schlüssel von einem anderen Computer wiederzuverwenden. Sie können einfach den neuen öffentlichen Schlüssel zur Datei authorized_keys auf dem Host hinzufügen und dann sowohl den Windows-Schlüssel von Windows als auch den neuen Linux-Schlüssel von Fedora verwenden.

Ihr Problem scheint ziemlich häufig und auch klar zu sein, habe ich gesagt.

 Permission denied (publickey).

bedeutet dir das etwas Für mich bedeutet es mir sehr viel.

Können Sie auf der Serverseite überprüfen, ob Selinux im erzwungenen Modus ausgeführt wird? Wenn nicht, sag mir, in welchen Modus Selinux läuft.

Wenn Sie einen weiteren Versuch ausführen und die Überwachungsprotokolle dieses Versuchs erfassen und hier veröffentlichen können, erfahren Sie auf jeden Fall, warum:

  tail -f /var/log/audit/audit.log  (and try to attempt)

Es ist ein Berechtigungsproblem, das klar ist, aber keine Dateiberechtigung :-)

Es scheint, dass das Problem (in meinem Fall ...) durch die Art des Schlüssels verursacht wurde.

Ich habe es gerade gelöst und der lokalen ~/.ssh/configDatei (dem Fedora 23-Clientcomputer) Folgendes hinzugefügt :

PubkeyAcceptedKeyTypes=+ssh-dss

Obwohl ich diese Zeile sowohl zur Server- als auch zur Client-Konfigurationsdatei hinzugefügt habe, hat nur die Client-Seite den Unterschied gemacht. Beachten Sie, dass die Berechtigungen 600für das Lesen der Konfigurationsdatei erforderlich sind .

Ich weiß nicht, ob noch jemand dieses Problem hat, aber ich habe es schließlich für meinen einen Computer (einen Laptop) gelöst, auf dem das Problem aufgetreten ist. Ich glaube, ich weiß, was es letztendlich geklärt hat, und ich werde die Informationen hier in der Hoffnung belassen, dass sie allen anderen helfen, die möglicherweise noch darauf stoßen - und auch, damit jemand hoffentlich meine Lösung überprüfen und bestätigen kann, dass es tatsächlich was ist Problem gelöst.

Wie sich herausstellte, war das Problem (für mich) überhaupt nicht bei SSH, sondern bei der Konfiguration meiner Schlüssel durch PAM. Die Konfiguration in /etc/pam.dwar veraltet (obwohl sie über Fedora 22 ordnungsgemäß funktionierte), und als Ergebnis wurden beim Anmelden [mehr] nicht die richtigen Dinge getan, um meine Schlüssel abzuholen $HOME/.ssh/. Ausführen dieses Befehls:

# sudo authconfig --updateall

Die Konfiguration /etc/pam.d wurde ordnungsgemäß neu erstellt. Beim nächsten Neustart, nachdem ich mich angemeldet hatte, als ich das erste Mal versuchte, mich auf meinem Server abzusenden, wurde ich in einem Dialogfeld aufgefordert, meine Passphrase für meinen SSH-Schlüssel ( $HOME/.ssh/id_rsa) einzugeben . Ich habe das Kontrollkästchen "Beim Anmelden automatisch entsperren" aktiviert und voila! Meine Fähigkeit, vom Laptop aus zu sshen, wurde wiederhergestellt.

Hintergrund

Der Hinweis, der mich zur Lösung dieses Problems führte, kam, als ich einen RSA-Schlüssel von einer externen Quelle importierte. (Ein USB - Schlüssel , den ich herumtragen, mit meinen „Remote - Zugriff“ Schlüsseln für mein Heimnetzwerk. Ich ausgeschaltet PasswordAuth meine nach außen gerichteten Server vor Jahren nach einem Einbruch.) Nach ssh-add-ing , DASS RSA - Schlüssel, im Gegensatz zu dem einen sitzt in $HOME/.ssh/id_rsa, es wurde vom Remote-Server ohne Probleme akzeptiert.

Dann tat ich, was eigentlich überflüssig sein ssh-addsollte, um es aufzunehmen $HOME/.ssh/id_rsa. Ich bemerkte, dass ich danach zwei Einträge für denselben Schlüssel ssh-add -lenthielt :

% ssh-add -l
2048 SHA256:XXXXXXXXXXXXXXXXXXXXXX id_rsa (RSA)
2048 SHA256:XXXXXXXXXXXXXXXXXXXXXX me@host (RSA)
2048 SHA256:YYYYYYYYYYYYYYYYYYYYYY imported@usbkey (RSA)

Beachten Sie, dass in einem der beiden Einträge nicht die Schlüsselkennung angezeigt wird, sondern nur der Dateiname des privaten Schlüssels, der mit der öffentlichen Signatur übereinstimmt. Als ob der private Schlüssel vom Schlüsselringmanager nicht wirklich entsperrt worden wäre.

Ich glaube, genau das geschah, und PAM gab "schlechte Schlüssel" an den SSH-Agenten weiter, der nicht mit der Passphrase entsperrt worden war. Als ssh versuchte, sich mit dem Schlüssel zu authentifizieren, verfügte es nicht über die (entsperrte) private Hälfte des Schlüsselpaars, sodass die Authentifizierung fehlschlug.

Das letzte Bit ist eine Vermutung, aber unabhängig davon, ob jemand Probleme mit SSH-Schlüsseln hat, die von Remote-Hosts (wo sie früher waren) nach dem Upgrade auf F23 nicht akzeptiert werden, lohnt es sich , das /etc/pam.d/Verzeichnis mithilfe von neu zu erstellen authconfig.

Überprüfen Sie die Berechtigungen des Benutzer-Ausgangsverzeichnisses. Es ist wichtig. Muss 755 sein. 700 oder 770 funktionieren nicht.

In Ihrem ssh_configversuchen uncommenting und / oder das Hinzufügen / Entfernen / Anhänge entweder an der Cipher, Ciphersoder MACsLinie (n).

Es scheint mir, dass sshdnach einer bestimmten Chiffre gesucht wird, die nicht in der Anfrage enthalten ist und die durch Konfigurieren in Ihrer Anfrage hinzugefügt werden kann ssh_config.

... und ich nehme an, Sie tun nicht zufällig haben PubkeyAuthenticationauf noauf dem Remote - Server, weil das auf jeden Fall nicht , dies verursachen würde.