Come posso risolvere questo problema con ssh-agent?

17

Sto usando Linux Mint e, a quanto pare, non sono riuscito a far sì che gnome-keyring si sblocchi automaticamente al login.

Un sintomo del mio problema è il seguente:

$ ssh-add
Identity added: /home/me/.ssh/id_rsa (/home/me/.ssh/id_rsa)

$ git pull
WARNING: gnome-keyring:: couldn't connect to: /tmp/keyring-Nmf3J3/pkcs11: No such file or directory

Come posso fare in modo che git possa spingere / tirare senza alcun input passphrase da parte mia?

Mi rendo conto che ci sono molte cose qui con gnome-keyring e ssh-agent, ma non sono stato in grado di risolverlo.

L'esecuzione ssh-adddurante una sessione significa che non mi viene più richiesto il passphrase per SSH / git.

Il problema è che dovrei correre ssh-adddurante ogni sessione - devo mancare come sbloccare il portachiavi di Gnome all'accesso.

$ export | grep GNOME          
GNOME_KEYRING_CONTROL=/tmp/keyring-hjMM4V
GNOME_KEYRING_PID=1961

È successo di nuovo durante la stessa sessione della prima modifica. L'ho fatto git pulle ottenuto WARNING: gnome-keyring:: couldn't connect to: /tmp/keyring-hjMM4V/pkcs11: No such file or directory.

$ env | grep SSH
SSH_AGENT_PID=2116
SSH_AUTH_SOCK=/tmp/ssh-OACxJMBY2038/agent.2038

$ ps -fp $SSH_AGENT_PID
UID        PID  PPID  C STIME TTY          TIME CMD
eoin      2116  2038  0 09:47 ?        00:00:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session x-session-manager

— eoinoc
fonte

1

Puoi eseguire export | grep GNOMEe pubblicare i risultati. Hai visto questo bug?

— didster,

Sembra un bug rilevante. Dal momento che non vedo sempre l'avvertimento, non sono sicuro di avere un problema più semplice semplicemente gnome-keyringsbloccare automaticamente all'accesso.

— eoinoc,

forse hai un altro agente che gnome-keyring è in esecuzione. Che dire env | grep SSHeps -fp $SSH_AGENT_PID

— Stéphane Chazelas,

@StephaneChazelas Ho aggiunto quello che mi hai suggerito, grazie. Sì, ho reso la vita complessa con zshe in tmuxesecuzione (solo per menzionarlo).

— eoinoc,

2

Quello che dovrebbe succedere è:

Si avvia una sessione di gnome, parte di quella che inizia un demone gnome-keyring (che funge anche da agente ssh) e l'ambiente di qualsiasi cosa iniziata durante quella sessione di gnome viene aggiornato con informazioni su come contattare quell'agente ssh. La password emessa al momento dell'accesso grafico viene utilizzata per sbloccare il portachiavi predefinito.

Quando usi gnome-keyring come agente ssh, non vuoi usare un altro agente come ssh-agent.

Quando la tua sessione X termina, lo stesso fa gnome-keyring. Ma la tua sessione tmux rimane. Quindi, anche se avvii un altro gnome-keyring o ssh-agent, l'ambiente dei processi già avviati tmuxnon sarà in grado di parlargli a meno che non aggiorni il loro ambiente con il percorso del nuovo socket.

Quello che potresti fare è:

gnome-keyring-daemon -r > ~/.gkr

E fai . ~/.gkrin tutte le shell che vuoi usare il nuovo portachiavi gnome

Fai attenzione a quale DISPLAY a cui gnome-keyring-daemon si connetterà.

— Stéphane Chazelas
fonte

Vuoi dire che questo è solo per quando termina la mia sessione X, in altre parole ogni volta che esco e riconnetto? Non ho .gkr, dovrei? Come posso fare attenzione a quale display gnome-keyring-daemonsi connetterà?

— eoinoc,

2

La prima cosa che proverei è apt-get install ssh-askpass-gnomealtrimenti se non hai installato quel pacchetto (o qualche altro programma askpass alternativo), quindi gnome non può richiederti la password quando devi sbloccare la chiave.

Dovrai anche DISPLAYimpostare correttamente la tua variabile:

$ echo $DISPLAY
:0.0

Inoltre, come stai avviando il tuo terminale? Potrebbe esserci un problema con il modo in cui si avvia la sessione del terminale e se eredita o meno gnome-session. Questo può accadere quando usi un programma gnon-gnome per impostare i tuoi tasti.

Presumendo che si utilizza gnome-terminalè possibile verificare utilizzando pstree. Qui puoi vedere l'eredità corretta in corso:

$ pgrep gnome-terminal | xargs -l1 pstree -s 
init(1)───lightdm(1643)───lightdm(26912)───gnome-session(27049)───xmonad-x86_64-l(27139)───gnome-terminal(26036)─┬─bash(26041)
                                                                                                                 ├─gnome-pty-helpe(+
                                                                                                                 ├─{gnome-terminal}+
                                                                                                                 ├─{gnome-terminal}+
                                                                                                                 └─{gnome-terminal}+

Mentre in questa sessione NON eredita da gnome-session:

$ pgrep gnome-terminal | xargs -l1 pstree -s 
init(1)───sh(25919)───gnome-terminal(25920)─┬─bash(25927)
                                            ├─gnome-pty-helpe(25926)
                                            ├─{gnome-terminal}(25921)
                                            ├─{gnome-terminal}(25924)
                                            └─{gnome-terminal}(25928)

Inoltre, controlla che ssh-agentvenga avviato da gnome-session:

$ pgrep ssh-agent | xargs -l1 pstree -s
init(1)───lightdm(1643)───lightdm(26912)───gnome-session(27049)───ssh-agent(27091)

— aculich
fonte

È un po 'complicato sapere quale terminale sto usando (colpa mia!). Il mio comando di avvio del terminale è mate-terminal --maximize -e tmux(che presumo sia gnome-terminal). Inoltre, zshviene quindi caricato all'interno tmux. ssh-askpass-gnomeè stato installato. $DISPLAYha previsto il risultato. Per l'eredità, tmuxè seduto sotto mate-terminalsenza alcuna tensione di gnome-session. Su un ramo separato, lo è tmux───zsh───xargs───pstree. Per rispondere alla tua ultima domanda, l'output è: init───mdm───mdm───x-session-manag───ssh-agent. Cosa pensi? Grazie.

— eoinoc,

beh, supponendo che tu usi gnome (e penso che Mint lo faccia di default, quindi a meno che tu non l'abbia cambiato dal default?) allora penso che non avere il tuo mate-terminalereditario gnome-sessionsia il problema. due domande: 1) qual è l'output di pgrep -fl gnome-sessione; 2) quale azione intraprendi per invocare effettivamente il tuo terminale? da un menu? da un'associazione di tasti di scelta rapida? o ????

— aculich,

Sì, sono su Gnome. 1) L'output è vuoto. 2) Molto interessante. Di solito lo faccio Ctrl+Alt+t. È una scorciatoia che ho impostato usando l'applicazione Linux Mint Keyboard Shortcutsusando il comando che ho menzionato in precedenza. Tuttavia , all'avvio Terminaltramite il menu principale "Start", SSH ha funzionato diversamente . La GUI di Gnome mi ha richiesto la password per il mio portachiavi. L'opzione per salvare questa passphrase per le sessioni successive è stata disattivata, non sono riuscito a selezionarla. (Anche il comando menu launcher è mate-terminal --maximize -e tmux.) Ci avvicina? Grazie, Aculich.

— eoinoc,

Se vedi il comportamento strano con quello Ctrl+Alt+tche hai impostato nelle scorciatoie da tastiera, penso che probabilmente stai riscontrando un bug in mdm / MATE. Quale versione di Mint stai usando?

— aculich,

Sono una versione in ritardo, su Linux Mint 13. Ma per il terminale a cui si accede dal menu, perché non dovrebbe ancora lasciarmi selezionare "salva questa passphrase per ogni accesso"?

— eoinoc,

1

Penso che il problema sia l'archiviazione permanente della chiave SSH protetta da password.

Dai un'occhiata alle seguenti risorse:

— Md Mahbubur Rahman
fonte

Commenterò mentre vado. Con il primo collegamento, ho aggiunto `IdentityFile ~ / .ssh / id_rsa` ~/.ssh/configma questo non ha risolto il problema.

— eoinoc,

Il terzo link mostra la configurazione di base che non sembra andare oltre ciò che ho già fatto. Grazie comunque.

— eoinoc,

-1

Aggiungi questo al tuo .bash_profile

if [ -n "$SSH_AUTH_SOCK" \
    -a "${SSH_AUTH_SOCK::13}" = "/tmp/keyring-" \
    -a ! -L "$SSH_AUTH_SOCK" ]
then
    OLD_AUTH_SOCK="$SSH_AUTH_SOCK"
    eval `ssh-agent`
    mv "$OLD_AUTH_SOCK" "$OLD_AUTH_SOCK"~
    ln -sfn "$SSH_AUTH_SOCK" "$OLD_AUTH_SOCK"
    SSH_AUTH_SOCK="$OLD_AUTH_SOCK"
fi

— Mark Cohen
fonte

Grazie Marco. Con questo, $SSH_AUTH_SOCKha un valore di /tmp/ssh-QCndYkdq2025/agent.2025. Mi sto perdendo qualcosa? $git pullvisualizza ancora il prompt della passphrase SSH.

— eoinoc,

Controlla le tue autorizzazioni sul tuo file .ssh / authorized_keys sul server. Dovrebbe essere 0600.

— Mark Cohen,

Sul server? GitHub è il server esterno e la mia chiave SSH è registrata lì. Non è più un problema locale, no?

— eoinoc,

Spiacenti, non avevo capito che stavi usando Github. Sì, non hai alcun controllo su quell'host. Puoi aggiungere più chiavi al tuo ssh-agent e sperimentare lo sshing su localhost per assicurarti di poter eseguire correttamente l'autenticazione. Inoltre, puoi provare ssh -vvv user @ host e vedere cosa sta funzionando.

— Mark Cohen,

La maggior parte dei sistemi desktop Linux (menta inclusa) si gestiscono ssh-agentcorrettamente al momento dell'accesso e sono di solito cose come questa che la rompono. Se per qualche motivo il tuo sistema non lo gestisce ssh-agent, non farlo manualmente. Usa invece il portachiavi che è ben progettato per gestire questo e i relativi problemi. Funziona anche con BSD (Mac) e altri sistemi non Linux.

— aculich,