How to get pinentry-curses to start on the correct tty?
I use gpg-agent for managing both PGP e SSH identities. The agent is started with a script like this
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
which is sourced whenever I run an interactive shell.
Everything works fine with this setup but there is an issue. Let's say I:
- open a terminal (launching the agent in background) and start working
- after a while open a second terminal
- do an action that requires entering a passphrase in the second terminal
At this point gpg-agent will start pinentry-curses prompting a passphrase but it will do this in the first terminal which results in its output mixed with whatever was running (usually a text editor) with no way to resume the program or stop pinentry (it starts using 100% cpu and I have to kill it).
I must be doing something wrong here. Anyone has experienced this?
Update:
I figured out this happens only for a prompt to unlock an SSH key, which looks like this,
while prompts for PGP keys always open on the correct (i.e. current) tty.
tty gpg pinentry
asked May 3 '16 at 18:57
RnhmjojRnhmjoj
17818
add a comment |
I use gpg-agent for managing both PGP e SSH identities. The agent is started with a script like this
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
which is sourced whenever I run an interactive shell.
Everything works fine with this setup but there is an issue. Let's say I:
- open a terminal (launching the agent in background) and start working
- after a while open a second terminal
- do an action that requires entering a passphrase in the second terminal
At this point gpg-agent will start pinentry-curses prompting a passphrase but it will do this in the first terminal which results in its output mixed with whatever was running (usually a text editor) with no way to resume the program or stop pinentry (it starts using 100% cpu and I have to kill it).
I must be doing something wrong here. Anyone has experienced this?
Update:
I figured out this happens only for a prompt to unlock an SSH key, which looks like this,
while prompts for PGP keys always open on the correct (i.e. current) tty.
tty gpg pinentry
asked May 3 '16 at 18:57
RnhmjojRnhmjoj
17818
Have you tried starting the agent from your login shell, so you only have the one running?
– jasonwryan
May 3 '16 at 19:09
@jasonwryan I've just tried: It's the same thing for linux virtual terminals (agetty). By the way in the question with terminal I meant a terminal emulator window.
– Rnhmjoj
May 3 '16 at 19:53
1
It wasexport GPG_TTY="$(tty)"that fixed it for me
– naisanza
May 8 '18 at 21:00
add a comment |
I use gpg-agent for managing both PGP e SSH identities. The agent is started with a script like this
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
which is sourced whenever I run an interactive shell.
Everything works fine with this setup but there is an issue. Let's say I:
- open a terminal (launching the agent in background) and start working
- after a while open a second terminal
- do an action that requires entering a passphrase in the second terminal
At this point gpg-agent will start pinentry-curses prompting a passphrase but it will do this in the first terminal which results in its output mixed with whatever was running (usually a text editor) with no way to resume the program or stop pinentry (it starts using 100% cpu and I have to kill it).
I must be doing something wrong here. Anyone has experienced this?
Update:
I figured out this happens only for a prompt to unlock an SSH key, which looks like this,
while prompts for PGP keys always open on the correct (i.e. current) tty.
tty gpg pinentry
asked May 3 '16 at 18:57
RnhmjojRnhmjoj
17818
I use gpg-agent for managing both PGP e SSH identities. The agent is started with a script like this
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
which is sourced whenever I run an interactive shell.
Everything works fine with this setup but there is an issue. Let's say I:
- open a terminal (launching the agent in background) and start working
- after a while open a second terminal
- do an action that requires entering a passphrase in the second terminal
At this point gpg-agent will start pinentry-curses prompting a passphrase but it will do this in the first terminal which results in its output mixed with whatever was running (usually a text editor) with no way to resume the program or stop pinentry (it starts using 100% cpu and I have to kill it).
I must be doing something wrong here. Anyone has experienced this?
Update:
I figured out this happens only for a prompt to unlock an SSH key, which looks like this,
while prompts for PGP keys always open on the correct (i.e. current) tty.
tty gpg pinentry
tty gpg pinentry
asked May 3 '16 at 18:57
RnhmjojRnhmjoj
17818
asked May 3 '16 at 18:57
RnhmjojRnhmjoj
17818
edited May 3 '16 at 20:14
Rnhmjoj
asked May 3 '16 at 18:57
RnhmjojRnhmjoj
17818
asked May 3 '16 at 18:57
RnhmjojRnhmjoj
17818
asked May 3 '16 at 18:57
RnhmjojRnhmjoj
17818
17818
Have you tried starting the agent from your login shell, so you only have the one running?
– jasonwryan
May 3 '16 at 19:09
@jasonwryan I've just tried: It's the same thing for linux virtual terminals (agetty). By the way in the question with terminal I meant a terminal emulator window.
– Rnhmjoj
May 3 '16 at 19:53
1
It wasexport GPG_TTY="$(tty)"that fixed it for me
– naisanza
May 8 '18 at 21:00
add a comment |
Have you tried starting the agent from your login shell, so you only have the one running?
– jasonwryan
May 3 '16 at 19:09
@jasonwryan I've just tried: It's the same thing for linux virtual terminals (agetty). By the way in the question with terminal I meant a terminal emulator window.
– Rnhmjoj
May 3 '16 at 19:53
1
It wasexport GPG_TTY="$(tty)"that fixed it for me
– naisanza
May 8 '18 at 21:00
Have you tried starting the agent from your login shell, so you only have the one running?
– jasonwryan
May 3 '16 at 19:09
Have you tried starting the agent from your login shell, so you only have the one running?
– jasonwryan
May 3 '16 at 19:09
@jasonwryan I've just tried: It's the same thing for linux virtual terminals (agetty). By the way in the question with terminal I meant a terminal emulator window.
– Rnhmjoj
May 3 '16 at 19:53
@jasonwryan I've just tried: It's the same thing for linux virtual terminals (agetty). By the way in the question with terminal I meant a terminal emulator window.
– Rnhmjoj
May 3 '16 at 19:53
1
1
It was
export GPG_TTY="$(tty)" that fixed it for me– naisanza
May 8 '18 at 21:00
It was
export GPG_TTY="$(tty)" that fixed it for me– naisanza
May 8 '18 at 21:00
add a comment |
2 Answers
2
active
oldest
votes
The gpg-agent man page explains under the option --enable-ssh-support that the ssh agent protocol is not able to provide the name of the tty to the agent, so it defaults to using the original terminal it was started in. Before running the ssh command that requires a passphrase in a new terminal you need to type
gpg-connect-agent updatestartuptty /bye
in the new terminal to update the agent's view of which tty or display to use.
answered May 4 '16 at 6:29
meuhmeuh
32.2k11954
I must have missed that part. Thank you.
– Rnhmjoj
May 4 '16 at 16:26
This answer helped me fully congeal this realization: the people responsible forgpg2have no concept of what it's like to have a command-line-centric workflow/lifestyle. Somehow people whose fundamental concept of a a typical computer user experience starts and ends within the boundaries of GUI windows got to make decisions that effect a tool that previously had been comfortably usable on the command-line.
– mtraceur
Dec 15 '17 at 7:02
1
@mtraceur Not really, it's ssh-agent at fault here: in fact gpg2 will display the prompt on the right tty when unlocking a PGP key. It's those responsible of ssh-agent that possibly never thought of the switching to a different tty.
– Rnhmjoj
Mar 14 '18 at 0:40
1
@Rnhmjoj Should the SSH guys have supported a TTY-switching usecase that no command-line tool for most of Unix/Linux history wanted? Do you know how the design thought process and decisions for exactly which part of the workflow was handled by the command and which was handled by the agent was done? If you are, maybe you can help me see something I'm missing, because I just can't see a clear path to how the very need for the agent to "switch" TTYs would even arise unless the architecture was decided on without considering typical command-line use and workflows.
– mtraceur
Mar 14 '18 at 1:10
@mtraceur where’s the difference to gpg2?
– Arne Babenhauserheide
Dec 18 '18 at 7:18
|
show 3 more comments
As per the upstream bug against openssh, the proper way to this is adding the following to your ~/.ssh/config:
Match host * exec "gpg-connect-agent UPDATESTARTUPTTY /bye"
This has worked for me perfectly so far.
answered Feb 6 at 18:52
smaslennikovsmaslennikov
564
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f280879%2fhow-to-get-pinentry-curses-to-start-on-the-correct-tty%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
The gpg-agent man page explains under the option --enable-ssh-support that the ssh agent protocol is not able to provide the name of the tty to the agent, so it defaults to using the original terminal it was started in. Before running the ssh command that requires a passphrase in a new terminal you need to type
gpg-connect-agent updatestartuptty /bye
in the new terminal to update the agent's view of which tty or display to use.
answered May 4 '16 at 6:29
meuhmeuh
32.2k11954
I must have missed that part. Thank you.
– Rnhmjoj
May 4 '16 at 16:26
This answer helped me fully congeal this realization: the people responsible forgpg2have no concept of what it's like to have a command-line-centric workflow/lifestyle. Somehow people whose fundamental concept of a a typical computer user experience starts and ends within the boundaries of GUI windows got to make decisions that effect a tool that previously had been comfortably usable on the command-line.
– mtraceur
Dec 15 '17 at 7:02
1
@mtraceur Not really, it's ssh-agent at fault here: in fact gpg2 will display the prompt on the right tty when unlocking a PGP key. It's those responsible of ssh-agent that possibly never thought of the switching to a different tty.
– Rnhmjoj
Mar 14 '18 at 0:40
1
@Rnhmjoj Should the SSH guys have supported a TTY-switching usecase that no command-line tool for most of Unix/Linux history wanted? Do you know how the design thought process and decisions for exactly which part of the workflow was handled by the command and which was handled by the agent was done? If you are, maybe you can help me see something I'm missing, because I just can't see a clear path to how the very need for the agent to "switch" TTYs would even arise unless the architecture was decided on without considering typical command-line use and workflows.
– mtraceur
Mar 14 '18 at 1:10
@mtraceur where’s the difference to gpg2?
– Arne Babenhauserheide
Dec 18 '18 at 7:18
|
show 3 more comments
The gpg-agent man page explains under the option --enable-ssh-support that the ssh agent protocol is not able to provide the name of the tty to the agent, so it defaults to using the original terminal it was started in. Before running the ssh command that requires a passphrase in a new terminal you need to type
gpg-connect-agent updatestartuptty /bye
in the new terminal to update the agent's view of which tty or display to use.
answered May 4 '16 at 6:29
meuhmeuh
32.2k11954
I must have missed that part. Thank you.
– Rnhmjoj
May 4 '16 at 16:26
This answer helped me fully congeal this realization: the people responsible forgpg2have no concept of what it's like to have a command-line-centric workflow/lifestyle. Somehow people whose fundamental concept of a a typical computer user experience starts and ends within the boundaries of GUI windows got to make decisions that effect a tool that previously had been comfortably usable on the command-line.
– mtraceur
Dec 15 '17 at 7:02
1
@mtraceur Not really, it's ssh-agent at fault here: in fact gpg2 will display the prompt on the right tty when unlocking a PGP key. It's those responsible of ssh-agent that possibly never thought of the switching to a different tty.
– Rnhmjoj
Mar 14 '18 at 0:40
1
@Rnhmjoj Should the SSH guys have supported a TTY-switching usecase that no command-line tool for most of Unix/Linux history wanted? Do you know how the design thought process and decisions for exactly which part of the workflow was handled by the command and which was handled by the agent was done? If you are, maybe you can help me see something I'm missing, because I just can't see a clear path to how the very need for the agent to "switch" TTYs would even arise unless the architecture was decided on without considering typical command-line use and workflows.
– mtraceur
Mar 14 '18 at 1:10
@mtraceur where’s the difference to gpg2?
– Arne Babenhauserheide
Dec 18 '18 at 7:18
|
show 3 more comments
The gpg-agent man page explains under the option --enable-ssh-support that the ssh agent protocol is not able to provide the name of the tty to the agent, so it defaults to using the original terminal it was started in. Before running the ssh command that requires a passphrase in a new terminal you need to type
gpg-connect-agent updatestartuptty /bye
in the new terminal to update the agent's view of which tty or display to use.
answered May 4 '16 at 6:29
meuhmeuh
32.2k11954
The gpg-agent man page explains under the option --enable-ssh-support that the ssh agent protocol is not able to provide the name of the tty to the agent, so it defaults to using the original terminal it was started in. Before running the ssh command that requires a passphrase in a new terminal you need to type
gpg-connect-agent updatestartuptty /bye
in the new terminal to update the agent's view of which tty or display to use.
answered May 4 '16 at 6:29
meuhmeuh
32.2k11954
answered May 4 '16 at 6:29
meuhmeuh
32.2k11954
answered May 4 '16 at 6:29
meuhmeuh
32.2k11954
answered May 4 '16 at 6:29
meuhmeuh
32.2k11954
32.2k11954
I must have missed that part. Thank you.
– Rnhmjoj
May 4 '16 at 16:26
This answer helped me fully congeal this realization: the people responsible forgpg2have no concept of what it's like to have a command-line-centric workflow/lifestyle. Somehow people whose fundamental concept of a a typical computer user experience starts and ends within the boundaries of GUI windows got to make decisions that effect a tool that previously had been comfortably usable on the command-line.
– mtraceur
Dec 15 '17 at 7:02
1
@mtraceur Not really, it's ssh-agent at fault here: in fact gpg2 will display the prompt on the right tty when unlocking a PGP key. It's those responsible of ssh-agent that possibly never thought of the switching to a different tty.
– Rnhmjoj
Mar 14 '18 at 0:40
1
@Rnhmjoj Should the SSH guys have supported a TTY-switching usecase that no command-line tool for most of Unix/Linux history wanted? Do you know how the design thought process and decisions for exactly which part of the workflow was handled by the command and which was handled by the agent was done? If you are, maybe you can help me see something I'm missing, because I just can't see a clear path to how the very need for the agent to "switch" TTYs would even arise unless the architecture was decided on without considering typical command-line use and workflows.
– mtraceur
Mar 14 '18 at 1:10
@mtraceur where’s the difference to gpg2?
– Arne Babenhauserheide
Dec 18 '18 at 7:18
|
show 3 more comments
I must have missed that part. Thank you.
– Rnhmjoj
May 4 '16 at 16:26
This answer helped me fully congeal this realization: the people responsible forgpg2have no concept of what it's like to have a command-line-centric workflow/lifestyle. Somehow people whose fundamental concept of a a typical computer user experience starts and ends within the boundaries of GUI windows got to make decisions that effect a tool that previously had been comfortably usable on the command-line.
– mtraceur
Dec 15 '17 at 7:02
1
@mtraceur Not really, it's ssh-agent at fault here: in fact gpg2 will display the prompt on the right tty when unlocking a PGP key. It's those responsible of ssh-agent that possibly never thought of the switching to a different tty.
– Rnhmjoj
Mar 14 '18 at 0:40
1
@Rnhmjoj Should the SSH guys have supported a TTY-switching usecase that no command-line tool for most of Unix/Linux history wanted? Do you know how the design thought process and decisions for exactly which part of the workflow was handled by the command and which was handled by the agent was done? If you are, maybe you can help me see something I'm missing, because I just can't see a clear path to how the very need for the agent to "switch" TTYs would even arise unless the architecture was decided on without considering typical command-line use and workflows.
– mtraceur
Mar 14 '18 at 1:10
@mtraceur where’s the difference to gpg2?
– Arne Babenhauserheide
Dec 18 '18 at 7:18
I must have missed that part. Thank you.
– Rnhmjoj
May 4 '16 at 16:26
I must have missed that part. Thank you.
– Rnhmjoj
May 4 '16 at 16:26
This answer helped me fully congeal this realization: the people responsible for
gpg2 have no concept of what it's like to have a command-line-centric workflow/lifestyle. Somehow people whose fundamental concept of a a typical computer user experience starts and ends within the boundaries of GUI windows got to make decisions that effect a tool that previously had been comfortably usable on the command-line.– mtraceur
Dec 15 '17 at 7:02
This answer helped me fully congeal this realization: the people responsible for
gpg2 have no concept of what it's like to have a command-line-centric workflow/lifestyle. Somehow people whose fundamental concept of a a typical computer user experience starts and ends within the boundaries of GUI windows got to make decisions that effect a tool that previously had been comfortably usable on the command-line.– mtraceur
Dec 15 '17 at 7:02
1
1
@mtraceur Not really, it's ssh-agent at fault here: in fact gpg2 will display the prompt on the right tty when unlocking a PGP key. It's those responsible of ssh-agent that possibly never thought of the switching to a different tty.
– Rnhmjoj
Mar 14 '18 at 0:40
@mtraceur Not really, it's ssh-agent at fault here: in fact gpg2 will display the prompt on the right tty when unlocking a PGP key. It's those responsible of ssh-agent that possibly never thought of the switching to a different tty.
– Rnhmjoj
Mar 14 '18 at 0:40
1
1
@Rnhmjoj Should the SSH guys have supported a TTY-switching usecase that no command-line tool for most of Unix/Linux history wanted? Do you know how the design thought process and decisions for exactly which part of the workflow was handled by the command and which was handled by the agent was done? If you are, maybe you can help me see something I'm missing, because I just can't see a clear path to how the very need for the agent to "switch" TTYs would even arise unless the architecture was decided on without considering typical command-line use and workflows.
– mtraceur
Mar 14 '18 at 1:10
@Rnhmjoj Should the SSH guys have supported a TTY-switching usecase that no command-line tool for most of Unix/Linux history wanted? Do you know how the design thought process and decisions for exactly which part of the workflow was handled by the command and which was handled by the agent was done? If you are, maybe you can help me see something I'm missing, because I just can't see a clear path to how the very need for the agent to "switch" TTYs would even arise unless the architecture was decided on without considering typical command-line use and workflows.
– mtraceur
Mar 14 '18 at 1:10
@mtraceur where’s the difference to gpg2?
– Arne Babenhauserheide
Dec 18 '18 at 7:18
@mtraceur where’s the difference to gpg2?
– Arne Babenhauserheide
Dec 18 '18 at 7:18
|
show 3 more comments
As per the upstream bug against openssh, the proper way to this is adding the following to your ~/.ssh/config:
Match host * exec "gpg-connect-agent UPDATESTARTUPTTY /bye"
This has worked for me perfectly so far.
answered Feb 6 at 18:52
smaslennikovsmaslennikov
564
add a comment |
As per the upstream bug against openssh, the proper way to this is adding the following to your ~/.ssh/config:
Match host * exec "gpg-connect-agent UPDATESTARTUPTTY /bye"
This has worked for me perfectly so far.
answered Feb 6 at 18:52
smaslennikovsmaslennikov
564
add a comment |
As per the upstream bug against openssh, the proper way to this is adding the following to your ~/.ssh/config:
Match host * exec "gpg-connect-agent UPDATESTARTUPTTY /bye"
This has worked for me perfectly so far.
answered Feb 6 at 18:52
smaslennikovsmaslennikov
564
As per the upstream bug against openssh, the proper way to this is adding the following to your ~/.ssh/config:
Match host * exec "gpg-connect-agent UPDATESTARTUPTTY /bye"
This has worked for me perfectly so far.
answered Feb 6 at 18:52
smaslennikovsmaslennikov
564
answered Feb 6 at 18:52
smaslennikovsmaslennikov
564
answered Feb 6 at 18:52
smaslennikovsmaslennikov
564
answered Feb 6 at 18:52
smaslennikovsmaslennikov
564
564
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f280879%2fhow-to-get-pinentry-curses-to-start-on-the-correct-tty%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Have you tried starting the agent from your login shell, so you only have the one running?
– jasonwryan
May 3 '16 at 19:09
@jasonwryan I've just tried: It's the same thing for linux virtual terminals (agetty). By the way in the question with terminal I meant a terminal emulator window.
– Rnhmjoj
May 3 '16 at 19:53
1
It was
export GPG_TTY="$(tty)"that fixed it for me– naisanza
May 8 '18 at 21:00