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, ist sign_and_send_pubkey: signing failed: agent refused operationdies etwas ärgerlich, da es mich zu meinem ssh-Server durchlässt, aber git weigert sich, den Code mit ssh zu übertragen.

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

Der Server, zu dem ich eine Verbindung herstelle, ist ein Ubuntu 16.04-Server, der über den do-release-upgradeBefehl aktualisiert wurde . Jede Hilfe wird sehr geschätzt.

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

ssh-add

Dann kannst du sshin deinen Server.

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

ssh-add -l

Einfache Lösung

Ich hatte das gleiche Problem bei Ubuntu 18.04. Hier geht es ausschließlich um clientseitige Berechtigungen für private Schlüssel .

$ ssh root@192.168.1.1
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

Ich hatte das gleiche Problem (gleiche Symptome)

sam@xxxxx:~/.ssh$ ssh centos@123.123.123.123
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 hier gelesen werden .

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 centos@123.123.123.123
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.

Als ich mich sign_and_send_pubkey: signing failed: agent refused operationauf mehreren Servern anmeldete , las ich VonCs Antwort auf Stack Overflow, um weitere Informationen zu verwandten Fehlern zu erhalten. Für mich bestand die Lösung darin, den Gnome-Schlüsselbund zu entfernen, Identitäten von ssh-agent zu löschen und neu zu starten.

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

Dann begannen alle meine Schlüssel perfekt zu funktionieren.

AKTUALISIEREN:

Temporäre Lösung ohne Deinstallation des Schlüsselbunds

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

eval `ssh-agent -s`
ssh-add

oder verwenden SSH_AUTH_SOCK=0 ssh your-server

Die dauerhafte Lösung ohne Deinstallation des Schlüsselbunds

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 root@12.34.56.78

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.)

Nach dem Upgrade auf Ubuntu 18.04 habe ich den gleichen Fehler erhalten 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

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 einen Fehler verursachte ssh-add:

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

Nach dem Entfernen der Dateien ~/.ssh/id_ed25519*(brauchte sie nicht mehr, es war von einem früheren Test) ging alles wieder gut.

Ist mir passiert, weil mein privater Schlüssel eine Passphrase hatte. Musste laufen ssh-addund dann hat es nach der Passphrase gefragt und richtig hinzugefügt. Jetzt wird jedoch nicht mehr nach meiner Passphrase gefragt, wenn auf eine Maschine gesendet wird.

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 Überprüfung durchgeführt hatte ( empfohlen auf github.com ):

ssh -T git@github.com

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

Später, um die Dinge dauerhafter zu ändern, folgte ich den Ratschlägen hier

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

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

antop@localmachine  ~  ssh root@ocp1.example.com
sign_and_send_pubkey: signing failed: agent refused operation
root@ocp1.example.com's password:

Fehlermeldung zeigt nicht auf aktuelles Problem. Problem behoben durch

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

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!!

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=576700

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:

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 ?!

ssh-add

funktioniert bei mir. Aber sei sicher

SSH-Agent

läuft.

In meinem Fall wurde das Problem durch GNOME Keyring verursacht. Befolgen Sie diese Anweisungen , um die SSH-Funktionen von gnome-keyring zu deaktivieren, ohne sie endgültig zu entfernen (was viele Probleme verursacht) :

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.

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. 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! :)

Am Ende habe ich meine bekannte Hosts-Datei gelöscht und es hat funktioniert. Musste nochmal ein Passwort eingeben, aber es hat endlich das richtige Passwort akzeptiert. Es war nach einer Neuinstallation.

Wenn Sie SSH_AUTH_SOCK = 0 hinzufügen, bevor der Befehl ssh hilft, ist dies ein Schlüsselringfehler. 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.

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

Wenn Sie einen neuen Schlüssel generieren oder eine Passphrase zu Ihrem Schlüssel hinzufügen oder daraus entfernen, kann dies zu Problemen führen. Der Schlüssel wird ssh-keygen -m PEMvor allen anderen Vorgängen verwendet, die Sie ausführen müssen. Sie können beispielsweise das alte Format wiederherstellen, ssh-keygen -m PEM -pindem Sie die alte Passphrase als neue Passphrase verwenden und eingeben (die ohne Passphrase leer wäre).