How to get pinentry-curses to start on the correct tty?












9















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:




  1. open a terminal (launching the agent in background) and start working

  2. after a while open a second terminal

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










share|improve this question

























  • 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
















9















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:




  1. open a terminal (launching the agent in background) and start working

  2. after a while open a second terminal

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










share|improve this question

























  • 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














9












9








9


3






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:




  1. open a terminal (launching the agent in background) and start working

  2. after a while open a second terminal

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










share|improve this question
















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:




  1. open a terminal (launching the agent in background) and start working

  2. after a while open a second terminal

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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited May 3 '16 at 20:14







Rnhmjoj

















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 was export 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











  • @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

















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










2 Answers
2






active

oldest

votes


















7














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.






share|improve this answer
























  • 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








  • 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



















1














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.






share|improve this answer























    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
    });


    }
    });














    draft saved

    draft discarded


















    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









    7














    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.






    share|improve this answer
























    • 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








    • 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
















    7














    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.






    share|improve this answer
























    • 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








    • 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














    7












    7








    7







    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.






    share|improve this answer













    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.







    share|improve this answer












    share|improve this answer



    share|improve this answer










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





      @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











    • 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





      @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













    1














    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.






    share|improve this answer




























      1














      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.






      share|improve this answer


























        1












        1








        1







        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.






        share|improve this answer













        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.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Feb 6 at 18:52









        smaslennikovsmaslennikov

        564




        564






























            draft saved

            draft discarded




















































            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            How to make a Squid Proxy server?

            Is this a new Fibonacci Identity?

            Touch on Surface Book