Come risolvere "sign_and_send_pubkey: firma non riuscita: operazione rifiutata dall'agente"?

Configurazione di un nuovo droplet Digital Ocean con chiavi SSH. Quando corro ssh-copy-idquesto è ciò che ottengo:

ssh-copy-id user@012.345.67.89
/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
user@012.345.67.89's password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'user@012.345.67.89'"
and check to make sure that only the key(s) you wanted were added.

Tuttavia, quando provo a eseguire ssh in, questo accade:

ssh user@012.345.67.89
sign_and_send_pubkey: signing failed: agent refused operation
user@012.345.67.89's password: 

Dopo aver inserito la password, ho effettuato l'accesso correttamente, ma questo ovviamente vanifica lo scopo di creare la chiave SSH in primo luogo. Ho deciso di dare un'occhiata al lato server di ssh-agent ed ecco cosa ottengo:

user@012.345.67.89:~# eval `ssh-agent -s`
Agent pid 5715
user@012.345.67.89:~# ssh-add -l
The agent has no identities.

anche user / .ssh / authorized_keys contiene una voce di chiave ssh-rsa, ma find -name "keynamehere"non restituisce nulla.

Esegui ssh-addsulla macchina client, che aggiungerà la chiave SSH all'agente.

Confermare con ssh-add -l(sempre sul client) che sia stato effettivamente aggiunto.

Dopo aver aggiornato Fedora 26 a 28 ho riscontrato lo stesso problema. E mancavano i seguenti registri

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

PROBLEMA:

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

il messaggio di errore non indica il problema effettivo. Problema risolto da

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

Avevo lo stesso problema in Linux Ubuntu 18 . Dopo l'aggiornamento da Ubuntu 17.10 , ogni comando git mostrerebbe quel messaggio.

Il modo per risolverlo è assicurarsi di disporre dell'autorizzazione corretta per id_rsae id_rsa.pub.

Verificare il numero di chmod corrente utilizzando stat --format '%a' <file>. Dovrebbe essere 600 per id_rsa e 644 per id_rsa.pub.

Per modificare l'autorizzazione sui file utilizzare

chmod 600 id_rsa
chmod 644 id_rsa.pub

Questo ha risolto il mio problema con l'aggiornamento.

Esegui il comando seguente per risolvere questo problema.

Ha funzionato per me.

chmod 600 ~/.ssh/id_rsa

Ho riscontrato l'errore durante l'utilizzo di gpg-agent come ssh-agent e una sottochiave gpg come chiave ssh https://wiki.archlinux.org/index.php/GnuPG#gpg-agent .

Sospetto che il problema sia stato causato da una voce di pin non valida tty per gpg causata dal mio comando sleep + lock utilizzato nella mia configurazione sway

bindsym $mod+Shift+l exec "sh -c 'gpg-connect-agent reloadagent /bye>/dev/null; systemctl suspend; swaylock'"

o solo il sonno / sospensione

Reimposta il pin di immissione tty per risolvere il problema

gpg-connect-agent updatestartuptty /bye > /dev/null

e la correzione per il mio comando sway sleep + lock:

bindsym $mod+Shift+l exec "sh -c 'gpg-connect-agent reloadagent /bye>/dev/null; systemctl suspend; swaylock; gpg-connect-agent updatestartuptty /bye > /dev/null'"

A questo errore:

# git pull
sign_and_send_pubkey: signing failed: agent refused operation
git@github.com: Permission denied (publickey).    
fatal: Could not read from remote repository.

Please make sure you have the correct access rights and the repository exists.

Verifica o aggiungi di nuovo la chiave pubblica in account Github> profilo> ssh.

Ho risolto in questo modo:

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

Grazie.

Potrebbero esserci vari motivi per ottenere l'errore SSH:

sign_and_send_pubkey: firma non riuscita: operazione rifiutata dall'agente

Alcuni di essi potrebbero essere legati alle problematiche evidenziate dalle altre risposte (vedi questo thread risposte), alcuni potrebbero essere nascosti e quindi richiederebbero un'indagine più approfondita.

Nel mio caso ho ricevuto il seguente messaggio di errore:

sign_and_send_pubkey: firma non riuscita: operazione rifiutata dall'agente

utente@website.domain.com: autorizzazione negata (publickey, gssapi-keyex, gssapi-with-mic)

L'unico modo per trovare il vero problema era invocare l' opzione -v verbose che ha portato alla stampa di molte informazioni di debug:

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

Si noti che la riga che dice key_load_public: No such file or directorysi riferisce alla riga successiva e non alla riga precedente.

Quindi ciò che SSH dice davvero è che non è stato possibile trovare il file della chiave pubblica denominato id_rsa.website.domain.com-certe questo sembrava essere il problema nel mio caso poiché il mio file della chiave pubblica non conteneva il -certsuffisso.

Per farla breve: la soluzione nel mio caso era solo di assicurarmi che il file della chiave pubblica fosse denominato come previsto. Non avrei mai potuto sospettarlo senza eseguire il debug della connessione.

La linea di fondo è USARE LA MODALITÀ VERBOSE SSH (opzione -v) per capire cosa c'è che non va, potrebbero esserci vari motivi, nessuno che potrebbe essere trovato su questo / un altro thread.

Questa dovrebbe essere piuttosto una domanda da SuperUser.

Esatto, ho lo stesso identico errore all'interno di MacOSX SourceTree, tuttavia, all'interno di un terminale iTerm2, le cose funzionano alla grande.

Tuttavia, il problema sembrava essere che ho due ssh-agent s in esecuzione; (

Il primo è /usr/bin/ssh-agent(aka MacOSX) e poi anche l'HomeBrew installato in /usr/local/bin/ssh-agentesecuzione.

L'accensione di un terminale da SourceTree mi ha permesso di vedere le differenze in SSH_AUTH_SOCK, usando lsofho trovato i due diversi se ssh-agentpoi sono stato in grado di caricare le chiavi (usando ssh-add) nel sistema predefinito ssh-agent(cioè /usr/bin/ssh-agent), SourceTree stava funzionando di nuovo.

Sì. Esegui ssh-add sulla macchina client. Quindi ripetere il comando ssh-copy-id userserver@012.345.67.89

Per me il problema era un copia / incolla errato della chiave pubblica in Gitlab. La copia ha generato un ritorno extra. Assicurati che ciò che incolli sia una chiave di una riga.

Anch'io ho ricevuto un sign_and_send_pubkey: signing failed: agent refused operationerrore. Ma nel mio caso il problema era un pinentrypercorso sbagliato .

Nel mio ${HOME}/.gnupg/gpg-agent.confla pinentry-programproprietà indicava un vecchio sentiero di ingresso. Correggendo il percorso lì e riavviando il gpg-agentrisolto per me.

L'ho scoperto seguendo i log con journalctl -f. Là dove righe di registro come le seguenti contenenti il ​​percorso sbagliato:

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

Ho bisogno di condividere, perché ho passato troppo tempo a cercare una soluzione

Ecco la soluzione: https://unix.stackexchange.com/a/351742/215375

Stavo usando questo comando:

ssh-keygen -o -t rsa -b 4096 -C "email@example.com"

gnome-keyring non supporta la chiave generata.

Rimuovere l' -oargomento ha risolto il problema.

Nel mio caso il problema era che il portachiavi GNOME conteneva una passphrase non valida per la chiave ssh da utilizzare. Dopo aver trascorso una quantità indecente di tempo per risolvere questo problema, ho eseguito seahorsee ho trovato la voce per contenere una stringa vuota. Posso solo immaginare che sia stato causato da una digitazione errata della passphrase utilizzata all'inizio un po 'di tempo prima, e quindi probabilmente dall'annullamento del richiedente o giù di lì per tornare alla riga di comando. L'aggiornamento della voce con la passphrase corretta ha immediatamente risolto il problema. Eliminando quella voce (dal portachiavi "login") e reinserendo la passphrase al primo prompt (e selezionando la casella di controllo appropriata) si risolve anche questo. Ora l'agente ottiene la passphrase corretta dal portachiavi sbloccato all'accesso denominato "login" e non chiede più la passphrase né "rifiuta l'operazione". Ovviamente YMMV.

Cosa ha funzionato qui: sul client

1) ssh-add

2) ssh-copy-id utente @ server

Le chiavi sono state create qualche tempo fa con il semplice "ssh-keygen -t rsa" Ho scambiato il messaggio di errore perché ho copiato la mia chiave pubblica ssh da client a server (con ssh-id-copy) senza eseguire prima ssh-add, poiché ho erroneamente presunto di averli aggiunti qualche tempo prima.

nota rapida per coloro che hanno recentemente aggiornato alla versione "moderna" ssh [OpenSSH_8.1p1, OpenSSL 1.1.1d FIPS 10 set 2019] - fornito con fedora 31, sembra non accettare più le vecchie chiavi DSA SHA256 (le mie sono datate 2006!) - creato una nuova chiave rsa, pubblica aggiunta a autorizzata, privata sul client e tutto funziona perfettamente.

grazie per i suggerimenti precedenti, in particolare ssh -v è stato molto utile