sign_and_send_pubkey: Signatur fehlgeschlagen: Agent hat Vorgang abgelehnt
Konfigurieren eines neuen Digital Ocean-Droplets mit SSH-Schlüsseln. Wenn ich ssh-copy-id starte, bekomme ich Folgendes:
ssh-copy-id [email protected]
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
sign_and_send_pubkey: signing failed: agent refused operation
[email protected]'s password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh '[email protected]'"
and check to make sure that only the key(s) you wanted were added.
Wenn ich dann jedoch versuche, ssh rein zu gehen, passiert Folgendes:
ssh [email protected]
sign_and_send_pubkey: signing failed: agent refused operation
[email protected]'s password:
Bei der Eingabe des Passworts bin ich ganz gut eingeloggt, was aber natürlich den Zweck der Erstellung des SSH-Schlüssels missachtet. Ich entschied mich für einen Blick auf die Server-Seite des ssh-agent und Folgendes bekomme ich:
[email protected]:~# eval `ssh-agent -s`
Agent pid 5715
[email protected]:~# ssh-add -l
The agent has no identities.
benutzer/.ssh/authorised_keys enthält ebenfalls einen ssh-rsa-Schlüsseleintrag, aber find -name "keynamehere" gibt nichts zurück.
Führen Sie ssh-add auf dem Client-Computer aus. Dadurch wird der SSH-Schlüssel zum Agenten hinzugefügt.
Bestätigen Sie mit ssh-add -l (wieder auf dem Client), dass es tatsächlich hinzugefügt wurde.
Nach dem Upgrade von Fedora 26 auf 28 stand ich vor dem gleichen Problem ... und folgende Protokolle fehlten
/var/log/secure
/var/log/messages
PROBLEM:
[email protected] ~ ssh [email protected]
sign_and_send_pubkey: signing failed: agent refused operation
[email protected]'s password:
Fehlermeldung zeigt kein aktuelles Problem an. Problem gelöst durch
chmod 700 ~/.ssh
chmod 600 ~/.ssh/*
Ich hatte das gleiche Problem inLinux Ubuntu 18. Nach dem Update vonUbuntu 17.10würde jeder git-Befehl diese Nachricht anzeigen.
Um das Problem zu lösen, müssen Sie sicherstellen, dass Sie die richtige Berechtigung für id_rsa und id_rsa.pub haben.
Überprüfen Sie die aktuelle chmod-Nummer mit stat --format '%a' <file>. Es sollte 600 für id_rsa und 644 für id_rsa.pub sein.
Um die Berechtigung für die Dateien zu ändern, verwenden Sie
chmod 600 id_rsa
chmod 644 id_rsa.pub
Das Problem mit dem Update wurde behoben.
Ich hatte den Fehler, als ich gpg-agent als SSH-Agent und einen gpg-Unterschlüssel als SSH-Schlüssel verwendete https://wiki.archlinux.org/index.php/GnuPG#gpg-agent .
Ich vermute, dass das Problem durch einen ungültigen PIN-Eintrag für gpg verursacht wurde, der durch meinen in meiner Sway-Konfiguration verwendeten Befehl sleep + lock verursacht wurde
bindsym $mod+Shift+l exec "sh -c 'gpg-connect-agent reloadagent /bye>/dev/null; systemctl suspend; swaylock'"
oder einfach nur schlafen/aussetzen
Setzen Sie die PIN-Nummer zurück, um das Problem zu beheben
gpg-connect-agent updatestartuptty /bye > /dev/null
und das Update für meinen Sway Sleep + Lock Befehl:
bindsym $mod+Shift+l exec "sh -c 'gpg-connect-agent reloadagent /bye>/dev/null; systemctl suspend; swaylock; gpg-connect-agent updatestartuptty /bye > /dev/null'"
Zu diesem Fehler:
# git pull
sign_and_send_pubkey: signing failed: agent refused operation
[email protected]: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.
Überprüfen oder fügen Sie den öffentlichen Schlüssel erneut in Github-Konto> Profil> ssh hinzu.
Ich habe so gelöst:
# chmod 400 ~/.ssh/id_rsa
# ls ~/.ssh/id_rsa -ls
4 -r--------. 1 reinaldo reinaldo 1679 Jul 26 2017 /home/reinaldo/.ssh/id_rsa
# git pull
remote: Counting objects: 35, done.
remote: Compressing objects: 100% (19/19), done.
remote: Total 35 (delta 9), reused 34 (delta 9), pack-reused 0
Unpacking objects: 100% (35/35), done.
Vielen Dank.
Dies sollte eher eine SuperUser-Frage sein.
Richtig, ich habe genau den gleichen Fehler in MacOSX SourceTree, aber in einem iTerm2-Terminal funktionieren die Dinge einfach nur gut.
Das Problem schien jedoch zu sein, dass ich zweissh-agents laufen habe; (
Das erste ist /usr/bin/ssh-agent (auch bekannt als MacOSX) und dann läuft auch das von HomeBrew installierte /usr/local/bin/ssh-agent.
Beim Starten eines Terminals aus SourceTree konnte ich die Unterschiede in SSH_AUTH_SOCK mithilfe von lsof erkennen. Ich habe die beiden unterschiedlichen ssh-agents gefunden und konnte dann die Schlüssel (mithilfe von ssh-add) in den Standard-ssh-agent des Systems (dh /usr/bin/ssh-agent) laden. ), SourceTree funktionierte wieder.
Es kann verschiedene Gründe dafür geben, den SSH-Fehler zu erhalten:
sign_and_send_pubkey: Signatur fehlgeschlagen: Agent hat Vorgang abgelehnt
Einige von ihnen könnten sich auf die Probleme beziehen, die von den anderen Antworten hervorgehoben wurden (siehe Antworten zu diesem Thread), einige von ihnen könnten ausgeblendet werden und würden daher einer genaueren Untersuchung bedürfen.
In meinem Fall habe ich folgende Fehlermeldung:
sign_and_send_pubkey: Signatur fehlgeschlagen: Agent hat Vorgang abgelehnt
[email protected]: Erlaubnis verweigert (publickey, gssapi-keyex, gssapi-with-mic)
Der einzige Weg, das eigentliche Problem zu finden, war das Aufrufen der Option -v verbose, was dazu führte, dass viele Debugging-Informationen gedruckt wurden:
debug1: Connecting to website.domain.com [xxx.xxx.xxx.xxx] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa.website.domain.com type 0
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa.website.domain.com-cert type -1
Bitte beachten Sie, dass die Zeile key_load_public: No such file or directory auf die nächste und nicht auf die vorherige Zeile verweist.
Was SSH wirklich sagt, ist, dass es die öffentliche Schlüsseldatei mit dem Namen id_rsa.website.domain.com-cert nicht finden konnte. Dies schien in meinem Fall das Problem zu sein, da meine öffentliche Schlüsseldatei nicht das Suffix -cert enthielt.
Um es kurz zu machen: Die Lösung in meinem Fall bestand nur darin, sicherzustellen, dass die öffentliche Schlüsseldatei wie erwartet benannt wurde. Ich konnte das niemals vermuten, ohne die Verbindung zu debuggen.
Das Fazit lautet USE THE SSH VERBOSE-MODUS (Option -v), um herauszufinden, was falsch ist. Es kann verschiedene Gründe geben. Es gibt keine Gründe, die in diesem/einem anderen Thread gefunden werden könnten.
Ich habe auch einen sign_and_send_pubkey: signing failed: agent refused operation -Fehler. Aber in meinem Fall war das Problem ein falscher pinentry Pfad.
In meinem ${HOME}/.gnupg/gpg-agent.conf zeigte die Eigenschaft pinentry-program auf einen alten Pinentry-Pfad. Den Pfad dort zu korrigieren und den gpg-agent neu zu starten, hat das für mich behoben.
Ich habe es entdeckt, indem ich die Protokolle mit journalctl -f verfolgte. Dort wo Protokollzeilen wie die folgenden den falschen Pfad enthalten:
Jul 02 08:37:50 my-Host gpg-agent[12677]: ssh sign request failed: No pinentry <GPG Agent>
Jul 02 08:37:57 my-Host gpg-agent[12677]: can't connect to the PIN entry module '/usr/local/bin/pinentry': IPC connect call failed
Für mich war das Problem eine falsche Kopie/Einfügen des öffentlichen Schlüssels in Gitlab. Die Kopie erzeugte eine zusätzliche Rückgabe. Vergewissern Sie sich, dass Sie einen einzeiligen Schlüssel verwenden.
Ja. Führen Sie ssh-add auf dem Client-Computer aus . Wiederholen Sie dann den Befehl ssh-copy-id [email protected]