Come ottenere maledizioni pinentry iniziare sulla tty corretta?

Uso gpg-agentper la gestione di entrambe le identità PGP e SSH. L'agente viene avviato con uno script come questo

gpg_agent_env="$XDG_CACHE_HOME/gpg-agent.env"

export GPG_TTY="$(tty)"

if ! ps -U "$USER" -o ucomm | grep -q gpg-agent; then
    eval "$({gpg-agent --daemon | tee $gpg_agent_env} 2> /dev/null)"
else
    source "$gpg_agent_env" 2> /dev/null
fi

che proviene ogni volta che eseguo una shell interattiva. Tutto funziona bene con questa configurazione ma c'è un problema. Diciamo che io:

aprire un terminale (avviare l'agente in background) e iniziare a lavorare
dopo un po 'aprire un secondo terminale
eseguire un'azione che richiede l'immissione di una passphrase nel secondo terminale

A questo punto gpg-agentinizierà a pinentry-cursesrichiedere una passphrase ma lo farà nel primo terminale che si traduce in un suo output mischiato a tutto ciò che era in esecuzione (di solito un editor di testo) senza alcun modo per riprendere il programma o interrompere la pinentry (inizia a usare il 100% della CPU e devo ucciderlo).

Devo fare qualcosa di sbagliato qui. Qualcuno l'ha sperimentato?

Aggiornare:

Ho capito che questo accade solo per un prompt per sbloccare una chiave SSH, che assomiglia a questo , mentre le richieste per le chiavi PGP si aprono sempre sul tty corretto (cioè corrente).

tty gpg pinentry

— Rnhmjoj
fonte

Hai provato ad avviare l'agente dalla shell di accesso, quindi hai solo quello in esecuzione?

— Jasonwryan,

@jasonwryan Ho appena provato: è la stessa cosa per i terminali virtuali di Linux (agetty). A proposito nella domanda con terminale intendevo una finestra dell'emulatore di terminale.

— Rnhmjoj,

È stato export GPG_TTY="$(tty)"questo a

— risolverlo

Risposte:

La pagina man di gpg-agent spiega sotto l'opzione --enable-ssh-supportche il protocollo dell'agente ssh non è in grado di fornire il nome del tty all'agente, quindi per impostazione predefinita usa il terminale originale in cui è stato avviato. Prima di eseguire il comando ssh che richiede un passphrase in un nuovo terminale che è necessario digitare

gpg-connect-agent updatestartuptty /bye

nel nuovo terminale per aggiornare la vista dell'agente di quale tty o display usare.

— meuh
fonte

Questa risposta mi ha aiutato a colmare pienamente questa consapevolezza: le persone responsabili gpg2non hanno idea di cosa significhi avere un flusso di lavoro / stile di vita incentrato sulla riga di comando. In qualche modo le persone il cui concetto fondamentale di una tipica esperienza utente di computer inizia e finisce all'interno dei confini delle finestre della GUI hanno preso decisioni che hanno effetto su uno strumento che in precedenza era stato comodamente utilizzabile dalla riga di comando.

— mtraceur,

@mtraceur Non proprio, è ssh-agent in errore qui: in effetti gpg2 mostrerà il prompt sulla destra tty quando si sblocca una chiave PGP. Sono i responsabili di ssh-agent che probabilmente non hanno mai pensato al passaggio a un diverso tty.

— Rnhmjoj,

@Rnhmjoj I ragazzi SSH avrebbero dovuto supportare un caso d'uso di commutazione TTY che nessuno strumento da riga di comando voleva per la maggior parte della storia di Unix / Linux? Sai come il processo di pensiero progettuale e le decisioni per quale parte del flusso di lavoro sono state gestite dal comando e quali sono state gestite dall'agente? Se lo sei, forse puoi aiutarmi a vedere qualcosa che mi manca, perché non riesco a vedere un percorso chiaro su come potrebbe sorgere la necessità stessa dell'agente di "cambiare" i TTY a meno che l'architettura non sia stata decisa senza considerare utilizzo tipico della riga di comando e flussi di lavoro.

— mtraceur,

@ArneBabenhauserheide La differenza è che gpgnon si può mai chiedere la passphrase sul terminale sbagliato, mentre gpg2facilmente può. Il gpgcomando sarà sempre chiedere la passphrase sul terminale si eseguito il comando dalla perché in realtà la creazione della passphrase è stato fatto da quel albero dei processi. Ma gpg2è codificato in modo tale da non poterlo garantire, poiché deve chiedere a un processo di agente di lunga durata separato di richiedere la passphrase e tale agente potrebbe essere stato originariamente avviato su un terminale diverso. gpg2e l'agente poteva, ma non era, codificato per aggirare il problema.

— mtraceur,

@ArneBabenhauserheide A meno che non ti stia chiedendo la differenza tra l'agente SSH e gpg2? Perché se è così, allora la differenza è che SSH mai richiesto questa perversione di altri utensili dover dire in modo proattivo suo agente specificamente per i terminali degli interruttori sullo sfondo (per quanto ne so - e se lo ha fatto poi ho le stesse critiche per esso troppo ). Il gpg2design ha senso solo se implementato da persone che non conoscono gli aspetti rilevanti della CLI su come funziona Linux / Unix e non hanno un buon senso di ciò che rende le interfacce e gli strumenti utili per comporre combinazioni arbitrarie.

— mtraceur,

Come per il bug upstream contro openssh, il modo corretto per farlo è aggiungere quanto segue al tuo ~/.ssh/config:

Match host * exec "gpg-connect-agent UPDATESTARTUPTTY /bye"

Questo ha funzionato perfettamente per me finora.

— smaslennikov
fonte

Si noti che GPG_TTYdeve essere impostato su $(tty)per farlo funzionare.

— Peter,