it-swarm.com.de

Ubuntu 16.04 ssh: sign_and_send_pubkey: signieren fehlgeschlagen: Der Agent hat die Operation abgelehnt

Ich habe gerade mein Ubuntu-System von 15.10 auf 16.04 aktualisiert, indem ich die Ubuntu 15-Partition vollständig von meinem System gelöscht habe.

Nach der Installation von Ubuntu 16.04 habe ich meine ssh-Schlüssel neu erstellt, da ich vergessen habe, sie zu sichern. Wenn ich jedoch versuche, ssh zu verwenden, erhalte ich sign_and_send_pubkey: signing failed: agent refused operation Code mit ssh.

Ich habe die Schlüssel bereits mit ssh-copy-id an den Server gesendet.

Der Server, mit dem ich mich verbinde, ist ein Ubuntu 16.04-Server, der mit dem Befehl do-release-upgrade aktualisiert wurde. Jede Hilfe wird sehr geschätzt.

168
Gamerb

Es sieht so aus, als ob ein ssh-agent bereits ausgeführt wird, es können jedoch keine Schlüssel angehängt werden. Um dies zu lösen, fügen Sie dem Authentifizierungsagenten die Identitäten des privaten Schlüssels wie folgt hinzu:

ssh-add

Dann können Sie ssh in Ihren Server.

außerdem können Sie die Liste der Fingerabdrücke aller derzeit hinzugefügten Identitäten anzeigen:

ssh-add -l
311
Ron

Einfache Lösung

Ich hatte das gleiche Problem bei Ubuntu 18.04. Das ist alles über Client-Seite Privater Schlüssel Berechtigungen.

$ ssh [email protected]
sign_and_send_pubkey: signing failed: agent refused operation

Die Dateiberechtigungen waren zu offen (0644).

Der folgende Befehl löste es:

chmod 600 ~/.ssh/id_rsa
53
Antonio Feitosa

Ich hatte das gleiche Problem (gleiche Symptome)

[email protected]:~/.ssh$ ssh [email protected]
sign_and_send_pubkey: signing failed: agent refused operation
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

... aber die Lösung war anders.

Das Problem ergab sich aus der Verwendung von GNOME-KEYRING. Der Beitrag, der sich auf die Lösung bezieht, kann gelesen werden hier .

Zusamenfassend:

  1. Ermitteln Sie das Problem, indem Sie SSH_AUTH_SOCK = 0 vor dem Befehl ssh einfügen. sam @ xxxxx: ~/.ssh $ SSH_AUTH_SOCK = 0 ssh [email protected]
  2. Falls es gelingt, eine Verbindung herzustellen. Öffnen Sie die Anwendung StartUp Application (z. B. über die Suchfunktion des Desktops) und deaktivieren Sie die Verwendung des Gnome-Schlüsselbunds.
  3. Starten Sie neu

Die Seite bietet weitere Details für den Fall eines ähnlichen Problems mit einer anderen Lösung.

52
sam

Ich bekam den sign_and_send_pubkey: signing failed: agent refused operation, als ich mich bei mehreren Servern anmeldete. Lesen Sie VonCs Antwort auf Stack Overflow für weitere Informationen zu verwandten Fehlern. Die Lösung bestand für mich darin, den Gnom-Schlüsselring zu entfernen und Identitäten von ssh- zu löschen. Agent und Neustart.

Sudo apt-get autoremove gnome-keyring
ssh-add -D

Dann begannen alle meine Schlüssel perfekt zu funktionieren.

UPDATE:

Temporäre Lösung ohne Deinstallation von Keyring

Wenn Sie den Gnomschlüsselbund behalten möchten und den Fehler agent refused operation haben, verwenden Sie:

eval `ssh-agent -s`
ssh-add

oder benutze SSH_AUTH_SOCK=0 ssh your-server

Die dauerhafte Lösung ohne Deinstallation von keyring

Wenn Sie können, ist der Gnome-Schlüsselbund mit dem 4096-Bit-RSA-Schlüssel kompatibel. Erstellen Sie also einfach einen neuen Schlüssel mit:

ssh-keygen -t rsa -f ~/.ssh/your-key-name -b 4096 -v -C root

Laden Sie den öffentlichen Schlüssel auf den Server hoch

$ ssh-copy-id -i ~/.ssh/your-key-name.pub [email protected]

Fügen Sie dem Agenten den SSH-Schlüssel hinzu

ssh-add ~/.ssh/your-key-name

Dies sollte ohne zusätzliche Hacks funktionieren und der Gnome-Schlüsselbund kann installiert bleiben.

(Der -C [Nutzername] ist optional, wird jedoch von Anbietern wie Google Cloud benötigt.)

18
Mike

Nach dem Upgrade auf Ubuntu 18.04 erhalte ich den gleichen Fehler sign_and_send_pubkey: signing failed: agent refused operation. Es stellte sich heraus, dass die Berechtigungen des SSH-Schlüssels zu offen waren. Der folgende Befehl hat das Problem für mich behoben chmod 600 .ssh/id_rsa

14
matthias

Auf meinem System (auch Ubuntu 16.04, das versucht, eine Verbindung zu github herzustellen) hatte ich eine Datei id_ed25519 in meinem .ssh-Ordner, die dazu führte, dass ssh-add fehlschlug:

$ ssh-add
Identity added: ~/.ssh/id_rsa (~/.ssh/id_rsa)
Could not add identity "~/.ssh/id_ed25519": communication with agent failed

Nachdem die Dateien ~/.ssh/id_ed25519* entfernt wurden (sie wurden nicht mehr benötigt, sie stammten aus einem früheren Test), lief alles wieder einwandfrei.

8
Daniel Alder

Ist mir passiert, weil mein privater Schlüssel eine Passphrase hatte. Musste ssh-add ausführen und dann fragte es nach der Passphrase und fügte sie korrekt hinzu. Jetzt wird jedoch nicht mehr nach meiner Passphrase gefragt, wenn auf eine Maschine gesendet wird.

7
qwertzguy

Nach dem Upgrade von Fedora 26 auf 28 hatte ich das gleiche Problem. Und keine Protokolldateien

no /var/log/secure
no /var/log/messages

[email protected]  ~  ssh [email protected]
sign_and_send_pubkey: signing failed: agent refused operation
[email protected]'s password:

fehlermeldung zeigt nicht auf aktuelles Problem. Problem behoben durch

chmod 700 ~/.ssh
chmod 600 ~/.ssh/*
4
Anto

Ich habe eine Neuinstallation von Ubuntu16.04 und ähnliche Probleme. Als ich versuchte, mein Repository von Github zu klonen, nachdem ich meinen öffentlichen Schlüssel nach github kopiert hatte (gemäß den Anweisungen auf github.com ) und nachdem ich die folgende Prüfung durchgeführt hatte ( empfohlen für github) .com ):

ssh -T [email protected]

Folgendes hat mich begrüßt:

sign_and_send_pubkey: signing failed: agent refused operation
Permission denied (publickey).

Um das Problem schnell zu beheben, ohne etwas zu entfernen oder meine Startkonfiguration zu ändern, habe ich im Terminal Folgendes eingegeben:

killall gnome-keyring-daemon

Dann hat der Klon funktioniert. Ich habe dann den gestoppten Daemon erneut gestartet, indem ich Folgendes eingegeben habe:

gnome-keyring-daemon

Um die Dinge später dauerhafter zu ändern, folgte ich dem Rat hier

4
neiltheory

Kommentar hinzufügen, da ich das gleiche Problem mit ed25519-Schlüsseln hatte. Das Problem ist in der Tat der Gnomschlüsselbund. Um dies zu beheben, habe ich Folgendes getan:

  • Deaktivierter ssh-key-agent (gnome-keyring) in "Startanwendungen"
  • Ssh-agent und gnome-agent ausgeschaltet: (killall ssh-agent; killall gnome-keyring-daemon)
  • Daemon neu gestartet: (eval ssh-agent -s)
  • Fügen Sie Ihren Schlüssel hinzu: $ ssh-add id_ed25519 Geben Sie die Passphrase für id_ed25519 ein: Identität hinzugefügt: id_ed25519
  • Profitieren!!
2
Matt

ssh-add

funktioniert bei mir. Aber sei sicher

sSH-Agent

läuft.

1
kst

Es ist Ende 2018, und dieser Bug oder Variationen davon plagen immer noch Xubuntu 16.04 und mehr als wahrscheinlich andere Versionen von Xenial. Es würde mich nicht wundern, wenn es das auch im 18.04 gibt! Es gibt es in irgendeiner Form seit 2009 und Karmic Koala. Hat Redhat, Debian und Ubuntu betroffen. Nimm nicht mein Wort dafür, sieh dir die öffentlichen Bugtracker an:

https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/470456

Und bei diesem Fehler finden Sie auch Auflistungen für die anderen 3:

Verweise:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=523322

https://bugzilla.redhat.com/show_bug.cgi?id=508286

https://bugzilla.gnome.org/show_bug.cgi?id=5767

In meinem Fall war das offensichtlichste Symptom die Unfähigkeit, SSH-Schlüssel mit Passphrasen zu verwenden. Dies kann auch andere betreffen, da die Fehlfunktion das Laden von SSH-Schlüsseln überhaupt verhindert! Und ich hatte keine Berechtigungsprobleme, es war alles ein Gnomenschlüsselbund. Meine Schlüssel (ja, es wurden mehrere verweigert, für verschiedene SSH-Server!) Hatten alle 600 Berechtigungen (rw für Eigentümer, nichts für Gruppen oder andere), wie in vielen Antworten dazu angegeben. Also nichts was ich dort ändern könnte.

In Xubuntu gibt es eine Möglichkeit, Startelemente zu deaktivieren. Normalerweise auch in Unity/Gnome/KDE möglich, aber ich habe keine installiert, kann also keine spezifischen Schritte angeben. Ich bin mir anderer Desktops nicht sicher. Anstatt den SSH-Agenten, den GPG-Agenten und andere Elemente von Gnome zu deaktivieren, die dies und andere verwandte Fehler verursachen, habe ich alle Gnome-Startelemente deaktiviert. Vielleicht übertrieben oder für manche keine Option, aber SSH funktioniert beim nächsten Neustart wieder einwandfrei!

  1. Öffnen Sie das Whisker-Hauptmenü -> Einstellungen -> Sitzung und Start.
  2. Klicken Sie auf die Registerkarte Erweitert, die letzte rechts.
  3. Deaktivieren Sie das Kontrollkästchen (Deaktivieren). Starten Sie Gnome Services beim Start.
  4. Schließen Sie und starten Sie neu. Abmelden kann es auch tun, aber Neustart sollte auf jeden Fall.

Screenshot der oben beschriebenen GUI:

Image

Da ich mein Update oben angegeben habe, hoffe ich, dass jemand es beheben wird.

Ubuntu hat es nachweislich nicht geschafft, es endgültig zu beseitigen, da es viele Tickets für mehrere Releases gibt, die behaupten, es sei behoben, und mehr, die "Regression" sagen, ist es zurück.

Debian möchte wahrscheinlich stochern (sich die Hände waschen), weil es nicht sie sind, stromaufwärts ist Gnome.

Redhat hat wahrscheinlich einen Fix, der nur zahlenden Kunden zur Verfügung steht. Denn historisch gesehen ist Redhat der größte Arbeitgeber für bezahlte Gnome-Entwickler, was auf den ersten Blick großzügig ist. Bis Sie erkennen, dass dies bedeutet, dass sie einen finanziellen Anreiz haben, niemals Korrekturen wie diese in die kostenlosen Versionen aufzunehmen, um weiterhin Redhat-Abonnements zu verkaufen.

Gnome ist wahrscheinlich derjenige, der das Problem am einfachsten beheben kann, und die anderen können es testen und packen, ohne selbst eine Codezeile zu schreiben. Aber die Karten, die ich lese, sagen, dass das Paket seit Jahren ohne einen offiziellen Betreuer geschmachtet ist! Und die beiden, die dies jetzt freiwillig tun (danke), sind fast genauso damit beschäftigt, einen Ersatz zu entwerfen. Warum nicht einen platten Reifen reparieren, auch wenn es ein Jahr dauert (es ist ein Jahrzehnt her!), Anstatt zuerst das Rad neu zu erfinden ?!

1
Lubo Diakov

Am Ende habe ich meine bekannte Hosts-Datei gelöscht und es hat funktioniert. Musste ein Passwort erneut eingeben, aber es akzeptierte schließlich das richtige Passwort. Es war nach einer Neuinstallation.

0
possumkeys

Wenn Sie SSH_AUTH_SOCK = 0 hinzufügen, bevor der Befehl ssh hilft, liegt ein Fehler im Schlüsselbund vor. Mit Ausnahme der bereitgestellten Lösungen und Probleme hängt das Problem möglicherweise mit der Passphrase zusammen. Wenn Sie eine Passphrase für den Schlüssel haben, werden Sie vom Gnome-Schlüsselbund beim ersten Anmelden gefragt. Wenn Sie aus Versehen eine leere Passphrase eingeben oder das Fenster unerwartet schließen, wird diese von Gnome als leere Passphrase angenommen und für immer gespeichert. Es hilft nichts, wenn Sie erneut zur Eingabe einer Passphrase aufgefordert werden. Um das Problem zu lösen, öffnen Sie die SSH-Schlüsselring-App und gehen Sie in den Login-Bereich unter der Kategorie Passwörter. Suchen Sie den Datensatz, der dem problematischen Schlüssel entspricht, und rufen Sie Eigenschaften auf, und geben Sie die richtige Passphrase ein.

0

In meinem Fall wurde das Problem durch GNOME Keyring verursacht. Zum Deaktivieren der SSH-Funktionen von Gnome-Keyring, ohne sie direkt zu entfernen (was kaputt geht) eine Menge Dinge), folgen diese Anweisungen :

cp /etc/xdg/autostart/gnome-keyring-ssh.desktop ~/.config/autostart
echo Hidden=true >> ~/.config/autostart/gnome-keyring-ssh.desktop

und starten Sie die Sitzung neu. Jetzt können Sie ssh-agent ausführen, ohne dass der Gnome-Schlüsselbund stört.

0
Norrius

Ich habe ein paar Dinge ausprobiert, unter anderem ssh-add, das Zurücksetzen von SSH (Löschen von .ssh/auf dem Server und so weiter, aber kein Glück. Es stellte sich heraus, dass ich nur eine Nacht darüber schlafen musste. Es hat geholfen! Warum Ich vermute, der auf dem Server laufende ssh-agent hatte etwas in seinem Cache, das später in dieser Nacht mit den jetzt korrekten Werten aktualisiert wurde. Wie auch immer, es funktioniert jetzt wie ein Zauber. Zum Abschluss hat er dies getan (Ubuntu 16.04 auf localhost, 14.04 auf dem Server).

# on local Host:
$ ssh-keygen
# (yes, overwrite the default file, and let the passphrase be empty)
$ ssh-copy-id ***.***.*.**
# (insert proper server IP address)
# now test
$ ssh ***.***.*.**
# this should have erected in .ssh/ on the server:
# -rw------- 1 *** *** 2000 aug.  11 09:55 authorized_keys
# no other magic going on! :)
0
untill

Es gibt eine weitere Ursache, auf die noch keine Antwort vorliegt: Das PEM-Format für die Schlüsseldatei war nicht mehr das Standardformat für ssh-keygen, bevor Ubuntu auf ein gnome-keyring-daemon umstellte, das das neue RFC4716-Format unterstützt.

Wenn Sie einen neuen Schlüssel generieren oder eine Passphrase zu Ihrem Schlüssel hinzufügen/daraus entfernen, kann dies zu Problemen führen. Der Schlüssel verwendet ssh-keygen -m PEM vor allen anderen Operationen, die Sie ausführen müssen. Sie können beispielsweise mit ssh-keygen -m PEM -p in das alte Format zurückkonvertieren und die alte Passphrase als neue Passphrase eingeben (die für keine Passphrase leer wäre).

0
Sam Brightman