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

Dopo aver installato Ubuntu 16.04 ho ricreato le mie chiavi ssh quando mi sono dimenticato di eseguirne il backup, ma ogni volta che tento di usare ssh ottengo sign_and_send_pubkey: signing failed: agent refused operationquesto è leggermente fastidioso in quanto mi fa passare attraverso il mio server ssh, ma git rifiuta di inviare il codice usando ssh.

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

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

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

ssh-add

Quindi puoi accedere sshal tuo server.

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

ssh-add -l

Soluzione semplice

Ho avuto lo stesso problema su Ubuntu 18.04. Questo è tutto sulle autorizzazioni della chiave privata sul lato client .

$ ssh root@192.168.1.1
sign_and_send_pubkey: signing failed: agent refused operation

Le autorizzazioni per i file erano troppo aperte (0644).

Il seguente comando lo ha risolto:

chmod 600 ~/.ssh/id_rsa

Ho avuto lo stesso problema (stessi sintomi)

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

... ma la soluzione era diversa.

Il problema veniva dall'uso di GNOME-KEYRING. Il post relativo 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 centos@123.123.123.123
2. Nel caso riesca a connettersi. Apri l'applicazione StartUp Application (usando ad esempio la funzione di ricerca del desktop) e disabilita l'uso di gnome-keyring.
3. Reboot

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

Lo stavo ottenendo sign_and_send_pubkey: signing failed: agent refused operationquando accedevo a diversi server, leggevo la risposta di VonC su Stack Overflow per ulteriori informazioni sui bug correlati, la soluzione per me era quella di rimuovere il portachiavi gnome, eliminare le identità da ssh-agent e riavviare.

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

Quindi tutte le mie chiavi hanno iniziato a funzionare perfettamente.

AGGIORNARE:

Soluzione temporanea senza disinstallare il portachiavi

Se vuoi mantenere il portachiavi gnome e hai l' agent refused operationerrore, usa:

eval `ssh-agent -s`
ssh-add

o usare SSH_AUTH_SOCK=0 ssh your-server

La soluzione permanente senza disinstallare il portachiavi

Se puoi, gnome-keyring è compatibile con la chiave RSA a 4096 bit, quindi genera 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 root@12.34.56.78

Aggiungi la chiave ssh all'agente

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

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

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

Dopo l'aggiornamento a Ubuntu 18.04 ho avuto lo stesso errore sign_and_send_pubkey: signing failed: agent refused operation. Si scopre che è stato causato dalle autorizzazioni della chiave ssh troppo aperte. Il seguente comando ha risolto il problema per me chmod 600 .ssh/id_rsa

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

$ 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 erano più necessari, era da un test precedente) tutto è andato di nuovo bene.

Mi è successo perché la mia chiave privata aveva una passphrase. Ho dovuto eseguire ssh-adde poi ha chiesto la passphrase e aggiunto correttamente. Tuttavia, ora non richiede la mia passphrase quando si usa una macchina.

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 (secondo le istruzioni su github.com ) e dopo aver eseguito il seguente controllo ( consigliato su github.com ):

ssh -T git@github.com

Sono stato accolto da quanto segue:

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

Per risolverlo rapidamente, senza rimuovere nulla o modificare la mia configurazione di avvio ho appena digitato quanto segue nel terminale:

killall gnome-keyring-daemon

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

gnome-keyring-daemon

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

Dopo aver aggiornato Fedora dal 26 al 28 ho riscontrato lo stesso problema. E nessun file di registro

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:

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

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

Aggiunta di un commento in quanto ho avuto lo stesso problema con le chiavi ed25519. Il problema è davvero il portachiavi di gnome. Per risolvere questo problema ho fatto quanto segue:

• Deselezionato ssh-key-agent (gnome-keyring) in "applicazioni di avvio"
• Ucciso l'agente ssh e l'agente gnome: (killall ssh-agent; killall gnome-keyring-daemon)
• Riavviato il demone: (eval ssh-agent -s)
• Aggiungi la tua chiave: $ ssh-add id_ed25519 Inserisci la passphrase per id_ed25519: Identità aggiunta: id_ed25519
• Profitto!!

È la fine del 2018 e questo bug, o varianti di esso, affligge ancora Xubuntu 16.04 e molto probabilmente altre versioni di Xenial. Non sarei sorpreso se esistesse anche nel 18.04! È in giro in qualche forma dal 2009, e Karmic Koala. Ha interessato Redhat, Debian e Ubuntu. Non crederci sulla parola, vedi i bugtrackers pubblici:

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

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

Riferimenti:

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

Nel mio caso, il sintomo più evidente era l'incapacità di usare i tasti SSH con passphrase. Può influire anche su quelli senza, poiché il malfunzionamento impedisce il caricamento dei tasti ssh! E non ho avuto problemi di permessi, era tutto gnome-keyring. Le mie chiavi (sì, ne ho rifiutate diverse, per diversi server SSH!) Le autorizzazioni erano tutte 600 (rw per il proprietario, niente per il gruppo o altro), come indicato in molte risposte al riguardo. Quindi nulla che io possa cambiare lì.

In Xubuntu, c'è un modo per disabilitare gli elementi di avvio. Di solito è possibile anche in Unity / Gnome / KDE, ma non li ho installati, quindi non posso fornire 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. Potrebbe essere eccessivo o no un'opzione per alcuni, ma SSH è tornato a funzionare perfettamente al prossimo riavvio!

1. Apri il menu principale di Whisker -> Impostazioni -> Sessione e avvio.
2. Fai clic sulla scheda Avanzate, l'ultima a destra.
3. Deseleziona (disattiva) Avvia Gnome Services all'avvio.
4. Chiudi e riavvia. Anche la disconnessione può farlo, ma il riavvio dovrebbe essere sicuro.

Schermata della GUI sopra descritta:

Quindi, dal momento che ho dato la mia correzione sopra, spero che qualcuno lo risolva.

Ubuntu non è riuscito a schiacciarlo definitivamente, dal momento che ci sono molti biglietti per diverse versioni che sostengono che è stato risolto, e più che dicono "regressione", è tornato.

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

Redhat probabilmente ha una soluzione disponibile solo per i clienti paganti. Perché, storicamente, Redhat è il più grande datore di lavoro degli sviluppatori di Gnome pagati, che è generoso a prima vista. Finché non ti rendi conto che ciò significa che hanno un incentivo finanziario a non mettere mai soluzioni di questo tipo nelle versioni gratuite, per continuare a vendere abbonamenti Redhat.

Gnome è probabilmente quelli che possono risolverlo più facilmente a monte, e quindi gli altri possono testare e impacchettare, senza scrivere una riga di codice. Ma i biglietti che leggo dicono che il pacchetto è rimasto in sospeso per anni senza un manutentore ufficiale! E le due persone che lo fanno volontariamente ora (grazie) sono quasi impegnate nella progettazione di un sostituto. Perché non riparare una gomma a terra anche se ci è voluto un anno (è passato un decennio!) Invece di reinventare prima la ruota ?!

ssh-add

per me va bene. Ma assicurati

ssh-agent

è in esecuzione.

Nel mio caso il problema è stato causato dal portachiavi GNOME. Per disabilitare le funzionalità SSH di gnome-keyring senza rimuoverlo completamente (il che rompe molte cose), segui queste istruzioni :

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

e riavvia la sessione. Ora puoi eseguire ssh-agent senza interferire con il portachiavi di gnome.

Ho provato un paio di cose, tra cui ssh-add, ripristinando SSH (eliminando .ssh / sul server, e così, ma senza fortuna. Quindi ho scoperto che dovevo solo dormirci sopra per una notte. ? Immagino che l'agente ssh in esecuzione sul server avesse qualcosa nella sua cache che è stato aggiornato più tardi quella notte con i valori ora corretti. Comunque, ora funziona come un incantesimo. Per concludere, 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! :)

Ho finito per eliminare il mio file hosts noto e ha funzionato. Ho dovuto inserire nuovamente una password, ma alla fine ha accettato la password giusta. Era dopo una nuova installazione.

Se l'aggiunta di SSH_AUTH_SOCK = 0 prima che il comando ssh sia d'aiuto, allora si tratta di un errore del portachiavi di gnome. Ad eccezione delle soluzioni e dei problemi forniti, il problema potrebbe essere correlato alla passphrase. Se hai la passphrase per la chiave, il portachiavi di gnome ti chiede quando accedi per la prima volta e se inserisci vuoto per errore o chiudi inaspettatamente una finestra, gnome lo assume come passphrase vuoto e lo ricorda per sempre. Nulla aiuta a richiedere nuovamente la passphrase. Per risolvere l'app portachiavi ssh aperta e vai alla sezione Accesso nella categoria Password. Trova il record corrispondente per la chiave problematica e accedi a Proprietà e inserisci la passphrase corretta.

C'è un'altra causa che non ha ancora una risposta: il formato PEM per il file chiave ha smesso di essere il valore predefinito ssh-keygenprima che Ubuntu gnome-keyring-daemonpassasse a un formato che supporta il nuovo formato RFC4716.

Se si genera una nuova chiave o si aggiunge / rimuove una passphrase dalla chiave, potrebbe rompersi. La chiave sta usando ssh-keygen -m PEMprima di qualsiasi altra operazione che devi eseguire. Ad esempio, è possibile riconvertire nel vecchio formato utilizzando ssh-keygen -m PEM -pe inserendo la vecchia passphrase come nuova passphrase (che sarebbe vuota senza passphrase).