Ubuntu 16.04 ssh: sign_and_send_pubkey: signing failed: agent refused operation

133

Ho appena aggiornato il mio sistema Ubuntu dal 15.10 al 16.04 cancellando completamente la partizione di Ubuntu 15 dal mio sistema.

Dopo aver installato Ubuntu 16.04 ho ricreato le mie chiavi ssh mentre mi sono dimenticato di eseguirne il backup, ma ogni volta che tento di usare ssh ottengo sign_and_send_pubkey: signing failed: agent refused operation questo è leggermente fastidioso dato che mi permette di passare al mio server ssh, ma git si rifiuta di push codice usando ssh.

Ho già inviato le chiavi al server utilizzando ssh-copy-id .

Il server a cui mi sto connettendo è un server Ubuntu 16.04 aggiornato tramite il comando do-release-upgrade . Qualsiasi aiuto sarà molto apprezzato.

    
posta Gamerb 25.04.2016 - 18:31

15 risposte

252

Sembra che ssh-agent sia già in esecuzione ma non riesce a trovare alcuna chiave allegata. Per risolvere questo problema, aggiungi le identità della chiave privata all'agente di autenticazione in questo modo:

ssh-add

Quindi puoi ssh nel tuo server.

Inoltre, è possibile visualizzare l'elenco di impronte digitali di tutte le identità attualmente aggiunte da:

ssh-add -l
    
risposta data Ron 25.04.2016 - 18:52
36

Ho avuto lo stesso problema (stessi sintomi)

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

... ma la soluzione era diversa.

Il problema proveniva dall'uso di GNOME-KEYRING. Il post che fa riferimento alla soluzione può essere letto qui .

In breve:

  1. Rileva il problema aggiungendo SSH_AUTH_SOCK = 0 davanti al comando ssh. sam @ xxxxx: ~ / .ssh $ SSH_AUTH_SOCK = 0 ssh [email protected]
  2. Nel caso in cui riesca a connettersi. Apri l'applicazione StartUp dell'applicazione (utilizzando la funzione di ricerca del desktop per esempio) e disabilita l'uso di gnome-keyring.
  3. Reboot

La pagina fornisce altri dettagli in caso di problemi simili con soluzioni diverse.

    
risposta data sam 10.10.2016 - 08:59
15

Stavo ottenendo il sign_and_send_pubkey: signing failed: agent refused operation durante l'accesso a diversi server, leggi la risposta di VonC su Stack Overflow per ulteriori informazioni sui relativi bug, la soluzione per me era rimuovere gnome-keyring, eliminare le identità da ssh-agent e riavviare.

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

Poi tutte le mie chiavi hanno iniziato a funzionare perfettamente.

UPDATE:

Soluzione temporanea senza disinstallare il keyring

Se vuoi mantenere il gnome-keyring e hai l'errore agent refused operation , usa:

eval 'ssh-agent -s'
ssh-add

o usa SSH_AUTH_SOCK=0 ssh your-server

La soluzione permanente senza disinstallare il keyring

Se puoi, gnome-keyring è compatibile con la chiave RSA 4096 bit, quindi genera solo una nuova chiave con:

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

Carica la chiave pubblica sul server

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

Aggiungi la chiave ssh all'agente

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

Questo dovrebbe funzionare senza ulteriori hack e il gnome-keyring può rimanere installato.

(The -C [username] è facoltativo, ma richiesto da provider come Google Cloud)

    
risposta data Mike 26.04.2016 - 09:38
15

Soluzione semplice

Ho avuto lo stesso problema su Ubuntu 18.04. Tutto ciò riguarda le autorizzazioni della chiave privata lato client .

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

I permessi dei file erano troppo aperti (0644).

Il seguente comando lo risolse:

chmod 600 ~/.ssh/id_rsa
    
risposta data Antonio Feitosa 31.05.2018 - 16:56
9

Dopo l'aggiornamento a Ubuntu 18.04 ho ottenuto lo stesso errore sign_and_send_pubkey: signing failed: agent refused operation . Si scopre che è stato causato dai permessi della chiave ssh che sono troppo aperti. Il seguente comando ha risolto il problema per me % Co_de%

    
risposta data matthias 04.05.2018 - 17:44
8

Sul mio sistema (anche Ubuntu 16.04, cercando di connettermi a github), avevo un file id_ed25519 nella mia cartella .ssh che ha reso ssh-add in errore:

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

Dopo aver rimosso i file ~/.ssh/id_ed25519* (non ne avevano più bisogno, proveniva da un test precedente) tutto è andato di nuovo bene.

    
risposta data Daniel Alder 11.06.2016 - 17:56
6

Mi è successo perché la mia chiave privata aveva una passphrase. Doveva eseguire ssh-add e poi ha chiesto la passphrase e aggiunto correttamente. Tuttavia, ora non richiede la mia passphrase quando si esegue ssh su una macchina.

    
risposta data qwertzguy 16.02.2017 - 02:02
3

Dopo l'aggiornamento di Fedora 26 a 28 ho affrontato lo stesso problema. E nessun file di registro

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:

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

chmod 700 ~/.ssh
chmod 600 ~/.ssh/*
    
risposta data Anto P Joseph 09.06.2018 - 12:15
2

Aggiunta di commenti in quanto avevo lo stesso problema con le chiavi ed25519. Il problema è in effetti gnome-keyring. Per risolvere questo problema ho fatto quanto segue:

  • Ssh-key-agent non selezionato (gnome-keyring) in "startup applications"
  • Ucciso da ssh-agent e gnome agent: (killall ssh-agent; killall gnome-keyring-daemon)
  • Riavviato il daemon: (eval ssh-agent -s )
  • Aggiungi la tua chiave: $ ssh-add id_ed25519 Inserisci passphrase per id_ed25519: Identità aggiunta: id_ed25519
  • Profit !!
risposta data Matt 16.12.2016 - 16:03
1
% Bl0ck_qu0te%

funziona per me. Ma assicurati

% Bl0ck_qu0te%

è in esecuzione.

    
risposta data 20.10.2018 - 08:15
1

È tardi il 2018, e questo bug, o varianti di esso, continua ad affliggere Xubuntu 16.04 e più probabilmente ad altri sapori di Xenial. Non sarei sorpreso se esiste anche nel 18.04! E 'stato in giro in qualche forma dal 2009, e Karmic Koala. Ha colpito Redhat, Debian e Ubuntu. Non fidarti della mia parola, vedi i bugtrackers pubblici:

link

E a quel bug, trovi anche elenchi per gli altri 3:

References:

link

link

link

Nel mio caso, il sintomo più ovvio era l'incapacità di usare chiavi ssh con passphrase. Può influire su quelli senza, dal momento che il malfunzionamento impedisce il caricamento delle chiavi ssh! E non ho avuto problemi di permessi, era tutto gnome-keyring. Le mie chiavi (sì ha rifiutato diversi, per diversi server SSH!) Le autorizzazioni erano tutte 600 (rw per proprietario, niente per gruppo o altro) come indicato in molte risposte a riguardo. Quindi nulla potrei cambiare lì.

In Xubuntu, c'è un modo per disabilitare gli elementi di avvio. Di solito è possibile anche in Unity / Gnome / KDE, ma non ho quelli installati, quindi non posso dare passaggi specifici. Non sono sicuro di altri desktop. Invece di disabilitare l'agente SSH, l'agente GPG e altri elementi di Gnome che causano questo e altri bug correlati, ho disattivato tutti gli elementi di avvio di Gnome. Può essere eccessivo o non un'opzione per alcuni, ma SSH torna a funzionare perfettamente al prossimo riavvio!

  1. Apri il menu principale di Whisker - & gt; Impostazioni - & gt; Sessione e avvio.
  2. Fai clic sulla scheda Avanzate, l'ultima a destra.
  3. Deseleziona (disattiva) Avvia i servizi Gnome all'avvio.
  4. Chiudi e riavvia. La disconnessione potrebbe farlo anche tu, ma il riavvio dovrebbe essere sicuro.

Schermata della GUI descritta sopra:

Quindi,datochehodatolamiacorrezionesopra,sperochequalcunolarisolva.

Ubuntunonèriuscitoaschiacciarlodefinitivamente,dalmomentochecisonomoltibigliettiperdiverseversionichesostengonocheèstatocorretto,epiùchedicono"regressione", è tornato.

Probabilmente Debian vuole punt (lavarsi le mani) perché non sono loro, a monte c'è Gnome.

Redhat probabilmente ha una correzione disponibile solo per i clienti paganti. Perché, storicamente, Redhat è il singolo più grande datore di lavoro degli sviluppatori di Gnome a pagamento, che è generoso a prima vista. Fino a quando non ti rendi conto che significa che hanno incentivi finanziari a non inserire mai correzioni come questa nelle versioni gratuite, per continuare a vendere abbonamenti a Redhat.

Probabilmente Gnome è in grado di risolverlo a monte più facilmente, e poi gli altri possono testare e creare pacchetti, senza scrivere una riga di codice. Ma i biglietti che ho letto dicono che il pacchetto ha languito per anni senza un maintainer ufficiale! E le due persone che lo fanno volontariamente adesso (grazie) sono quasi impegnate a progettare un sostituto. Perché non aggiustare una gomma a terra anche se ci vuole un anno (è passato un decennio!) Invece di reinventare la ruota prima?!

    
risposta data Lubo Diakov 23.07.2018 - 16:19
0

Ho una nuova installazione di Ubuntu16.04 e ho riscontrato problemi simili. Quando ho provato a clonare il mio repository da Github dopo aver copiato la mia chiave pubblica su github (come per le istruzioni su github.com ) e dopo aver eseguito il seguente controllo ( consigliato su github.com ):

ssh -T [email protected]

Sono stato accolto da quanto segue:

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

Per risolvere il problema rapidamente, senza rimuovere nulla o modificare la configurazione di avvio, ho semplicemente inserito quanto segue nel terminale:

killall gnome-keyring-daemon

Quindi il clone ha funzionato. Ho quindi avviato nuovamente il daemon arrestato digitando:

gnome-keyring-daemon

In seguito, per cambiare le cose in modo più permanente, ho seguito il consiglio qui

    
risposta data 23.10.2018 - 12:31
0

Nel mio caso il problema è stato causato da GNOME Keyring. Per disabilitare le capacità SSH di gnome-keyring senza escludere rimuovendone (che rompe un sacco di cose), segui queste istruzioni :

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

e riavviare la sessione. Ora puoi eseguire ssh-agent senza interferire con gnome-keyring.

    
risposta data 18.11.2018 - 16:45
0

Ho provato un paio di cose, tra cui ssh-add, reimpostando SSH (cancellando .ssh / sul server e così via, ma senza fortuna. Quindi ho scoperto che dovevo dormirci sopra per una notte. perché? Suppongo che l'agente ssh in esecuzione sul server abbia qualcosa nella sua cache che è stato aggiornato più tardi quella notte con i valori ora corretti.Ad ogni modo, ora funziona come un incantesimo.Per concludere, questo ha fatto questo (Ubuntu 16.04 su localhost, 14.04 sul 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! :)
    
risposta data untill 11.08.2016 - 10:12
0

Ho finito per perdere il mio file hosts conosciuto e ha funzionato. Dovette inserire di nuovo una password, ma alla fine accettò la password giusta. È stato dopo una nuova installazione.

    
risposta data possumkeys 01.11.2016 - 08:46

Leggi altre domande sui tag