Come rimuovere una chiave ssh?


154

Al momento ho una vecchia chiave SSH caricata su un server. Il problema è che ho perso la mia ~/.sshdirectory (con l'originale id_rsae i id_rsa.pubfile).

Di conseguenza, desidero rimuovere la vecchia chiave SSH direttamente sul server e caricarne una nuova.

Ho provato il seguente comando senza successo:

$> ssh-add -D

inserisci qui la descrizione dell'immagine

C'è un modo per rimuovere completamente una chiave SSH?


Con cosa ssh-add -d?
user2196728

5
dannazione, è ssh-add -D, maiuscolo
Alexander Mills

Controlla i tuoi socket che vengono utilizzati dal tuo ssh-agent (1).
Dwight Spencer,

Risposte:


129

Si noti che esistono almeno due segnalazioni di bug per ssh-add -d/-D non rimuovere le chiavi:

Il problema esatto è:

ssh-add -d/-Delimina solo le chiavi aggiunte manualmente dal portachiavi gnome.
Non è possibile eliminare le chiavi aggiunte automaticamente.
Questo è il bug originale ed è ancora sicuramente presente.

Quindi, ad esempio, se hai due diverse identità ssh caricate automaticamente associate a due diversi account GitHub - diciamo per lavoro e per casa - non c'è modo di passare da una all'altra. GitHub Imposta il primo corrispondente, quindi appari sempre il tuo utente 'home' su GitHub, senza alcun modo di caricare cose su progetti di lavoro.

Consentire ssh-add -ddi applicare le chiavi caricate automaticamente (e ssh-add -t Xdi modificare la durata delle chiavi caricate automaticamente) ripristinerebbe il comportamento che la maggior parte degli utenti si aspetta.


Più precisamente, sul problema:

Il colpevole è gpg-keyring-daemon:

  • Sovverte il normale funzionamento di ssh-agent, principalmente solo per poter far apparire una bella scatola in cui è possibile digitare la passphrase per una chiave ssh crittografata.
  • E collega la tua .sshdirectory e aggiunge automaticamente tutte le chiavi che trova al tuo agente.
  • E non ti permetterà di eliminare quelle chiavi.

Come lo odiamo? Non contiamo i modi: la vita è troppo breve.

L'errore è aggravato dal fatto che i nuovi client SSH provano automaticamente tutte le chiavi nel proprio agente SSH quando si connettono a un host.
Se ce ne sono troppi, il server rifiuterà la connessione.
E dal momento che gnome-keyring-daemon ha deciso da sé quante chiavi vuoi che il tuo ssh-agent abbia, e le ha caricate automaticamente, E NON LASCIARLI ELIMINARLI, sei brindisi.

Questo errore è ancora confermato in Ubuntu 14.04.4, di recente due giorni fa (21 agosto 2014)


Una possibile soluzione alternativa:

  • Fare ssh-add -Dper eliminare tutte le chiavi aggiunte manualmente . Questo blocca anche le chiavi aggiunte automaticamente, ma non è molto utile poiché gnome-keyringti chiederà di sbloccarle comunque quando provi a fare una git push.
  • Passare alla ~/.sshcartella e spostare tutti i file delle chiavi tranne quello con cui si desidera identificarsi in una cartella separata chiamata backup. Se necessario, puoi anche aprire il cavalluccio marino ed eliminare le chiavi da lì.
  • Ora dovresti essere in grado di fare a git pushmeno di un problema.

Un'altra soluzione alternativa:

Quello che vuoi davvero fare è spegnere del gpg-keyring-daemontutto.
Vai a System --> Preferences --> Startup Applicationse deseleziona la SSH Key Agent (Gnome Keyring SSH Agent)casella " " - dovrai scorrere verso il basso per trovarlo.

Otterrai ancora un ssh-agent, solo ora si comporterà in modo sano: nessuna chiave viene caricata automaticamente, esegui ssh-add per aggiungerli e, se vuoi eliminare le chiavi, puoi farlo. Immaginalo.

Questo commento suggerisce in realtà:

La soluzione è impedire gnome-keyring-managerche si avvii mai, cosa che era stranamente difficile alla fine raggiunta rimuovendo il permesso di esecuzione del file di programma.


Ryan Lue aggiunge un altro interessante caso d'angolo nei commenti :

Nel caso questo aiuti chiunque: ho anche provato a eliminare del tutto i file id_rsae id_rsa.pube la chiave era ancora visualizzata.

Si scopre che gpg-agentli stava memorizzando nella cache in un ~/.gnupg/sshcontrolfile ; Ho dovuto eliminarli manualmente da lì.

Questo è il caso in cui lakeygrip si è aggiunto come qui .


1
Un'altra opzione in Ubuntu 14-16 è usare la gui 'Password e chiavi' (puoi trovarla per trovare ssh). Scegli quali chiavi OpenSS, ad esempio, fai clic con il pulsante destro del mouse sulla chiave e scegli Elimina. Potrebbe essere necessario riavviare il sistema per vedere che è stato rimosso.
user3257693

2
Perché queste informazioni sulla ssh-agente ssh-addla risposta selezionata? Il poster originale diceva che voleva remove the old SSH key directly on the server and upload a new one. Che suona come vuole modificare ~/.ssh/authorized_keyssulla macchina remota.
H2ONaCl

1
Questa risposta mi ha portato a risolvere un problema che si presenta con l'inoltro ssh abilitato. Passare da una macchina Ubuntu 16.04 a un sistema debian in cui tutte le credenziali ssh vengono inoltrate a git clonestava usando la prima chiave nella catena invece della versione nel file di configurazione sulla scatola di Ubuntu. La chiave errata veniva risucchiata automaticamente e inoltrata alla casella Debian.
Redfive,

1
Questo è un vero dolore nella parte posteriore. Sto lavorando a progetti aziendali e ho contratto un contratto con un'altra società. Questo non fa altro che sprecare tempo nella gestione di entrambi. Spero che una soluzione arrivi presto!
joshlsullivan,

1
Nel caso questo aiuti chiunque: ho persino provato a eliminare del tutto i file id_rsae id_rsa.pube la chiave era ancora visualizzata. Viene fuori che gpg-agent li stava memorizzando nella cache in un ~/.gnupg/sshcontrolfile; Ho dovuto eliminarli manualmente da lì.
Ryan Lue,

10

Se stai tentando di eseguire un'operazione relativa a ssh e ottieni il seguente errore:

$ git fetch
no such identity: <ssh key path>: No such file or directory

È possibile rimuovere la chiave ssh mancante dal proprio agente ssh con quanto segue:

$ eval `ssh-agent -s`  # start ssh agent
$ ssh-add -D <ssh key path>  # delete ssh key

9

A meno che non abbia frainteso, hai perso la tua .sshdirectory contenente la tua chiave privata sul tuo computer locale e quindi vuoi rimuovere la chiave pubblica che si trovava su un server e che consentiva l'accesso basato su chiave. In tal caso, verrà archiviato nel .ssh/authorized_keysfile nella directory home sul server. Puoi semplicemente modificare questo file con un editor di testo ed eliminare la riga pertinente se riesci a identificarlo (ancora più semplice se è l'unica voce!). Spero che la chiave non sia il tuo unico metodo di accesso al server e che tu abbia qualche altro modo di accedere e modificare il file. È possibile aggiungere manualmente una nuova chiave pubblica al authorised_keysfile o utilizzare ssh-copy-id. In entrambi i casi, per accedere al authorized_keysfile sul server è necessario impostare l'autenticazione della password per il tuo account sul server o qualche altro metodo di identità o accesso .

ssh-addaggiunge identità al tuo agente ssh che gestisce la gestione delle tue identità localmente e "la connessione all'agente viene inoltrata tramite accessi remoti SSH, e l'utente può quindi utilizzare i privilegi dati dalle identità in qualsiasi punto della rete in modo sicuro". (pagina man), quindi non credo sia quello che vuoi in questo caso. Non ho modo di ottenere la tua chiave pubblica su un server senza che tu abbia accesso a detto server tramite un accesso ssh per quanto ne so.


Ho eliminato questo file e posso ancora connettermi. Quindi sicuramente non era contenuto qui ... Era una chiave aggiunta automaticamente ma non esiste ancora da nessuna parte.
Larry,

5

Ho aperto l'applicazione "Password e chiavi" in Unity e ho rimosso le chiavi indesiderate da Chiavi sicure -> Chiavi OpenSSH E sono state automaticamente rimosse anche da ssh-agent -l .


2
Attenzione che questo li cancella anche dalla directory~/.ssh
Peter V. Mørch,

1

Posso confermare che questo bug è ancora presente in Ubuntu 19.04. La soluzione suggerita da @VonC ha funzionato perfettamente, riassumendo per la mia versione:

  • Fai clic sulla scheda Attività nell'angolo in alto a sinistra
  • Nella casella di ricerca che viene visualizzata, inizia a digitare "applicazioni di avvio"
  • Fai clic sull'icona "Applicazioni di avvio"
  • Nella casella che si apre, seleziona l'applicazione di gestione dei keyring gnome (non ricordo il nome esatto sulla GUI ma è abbastanza distintivo) e rimuovila.

Quello che ho fatto dopo è stato riprovare ssh-add -D, e dopo il riavvio ssh-add -lmi ha detto che l'agente non ha identità. Ho confermato che avevo ancora il ssh-agentdemone in esecuzione con ps aux | grep agent. Quindi ho aggiunto la chiave che uso più frequentemente con GitHub ( ssh-add ~/.ssh/id_ecdsa) e tutto va bene!

Ora posso fare le normali operazioni con il mio repository più frequentemente utilizzato e, se di tanto in tanto ho bisogno dell'accesso all'altro repository che utilizza la chiave RSA, dedico un solo terminale per esso export GIT_SSH_COMMAND="ssh -i /home/me/.ssh/id_rsa.pub". Risolto! Il merito va a @VonC per aver segnalato il bug e la soluzione.


1

Controlla la chiave .ssh o no nel tuo sistema

  1. Vai alla cartella -> /Users/administrator/.ssh/id_ed25519.pub

Se non di

  1. Terminale aperto.

Passato al terminal

  1. Controlla l'utente -> ssh -T git@gitlab.com

Rimuovi chiave .ssh esistente

  1. Rimuovi chiave .ssh esistente -> rm ~ / .ssh / github_rsa.pub

Creare nuovo

  1. Crea una nuova chiave .ssh -> ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

  2. La chiave pubblica è stata salvata in "/Users/administrator/.ssh/id_ed25519.pub."

  3. Apri percorso salvato chiave pubblica.
  4. Copia la chiave .ssh -> Account GitLab -> Impostazioni -> Chiave SSH -> Aggiungi chiave
  5. Provare di nuovo dal terminale -> ssh -T git@gitlab.com

0

La soluzione per me (OpenSuse Leap 42.3, KDE) è stata quella di rinominare la cartella ~/.gnupgche apparentemente conteneva le chiavi e i profili memorizzati nella cache. Dopo il logout / accesso di KDE, ssh-add / agent è di nuovo in esecuzione e la cartella viene creata da zero, ma le vecchie chiavi non sono più disponibili.

Non ho avuto successo con gli altri approcci.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.