[HELP] pinentry-curses breaks SSH auth, but pinentry-mac works fine?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[HELP] pinentry-curses breaks SSH auth, but pinentry-mac works fine?

Ryan Lue
Hello,

I have struggled with getting GPG keys to work for SSH authentication
for the better part of two days. I'm almost completely there, and would
like to ask gnupg-users' help in understanding this one last quirk.

To be brief, I have gpg-agent set up with ssh support enabled. I'm using an authentication-only subkey for SSH authentication.

If I _don't_ set a password on this subkey, I can log into my SSH
servers no problem. This is what I'm doing right now, because my
security needs are not very strict. It's when I _do_ set a password that
I run into problems.

Basically, there are two ways that I have figured out to get it to work:
I can use the `pinentry-mac` GUI pinentry program, and everything works
fine. Or, I can set `allow-preset-passphrase` and then manually cache
the passphrase up front with `gpg-preset-passphrase`. (Only, that's
problematic because it can't be automated without storing the passphrase
in cleartext.)

But for some reason, it just doesn't work with `pinentry-curses`: SSH
(GPG) key authentication fails silently, and the server falls back to
password authentication. (I have made sure to set `$GPG_TTY`, so
`pinentry-curses` works just fine for everything else, just not SSH
authentication. For instance, I can `echo hello | gpg -s` and I'll get
the pinentry password prompt in the terminal.)

So, why can't I use `pinentry-curses` for SSH authentication? Does it
have something to do with the `$GPG_TTY` environment variable not being
set on the SSH server? Any insight or clues on how to troubleshoot this
problem would be deeply appreciated.

(FWIW, I'm on Mac OS 10.11 El Capitan with GnuPG 2.1.21 and pinentry
1.0.0, both installed via Homebrew. And yes, I'm making the necessary
changes to the `pinentry-program` setting in `~/.gnupg/gpg-agent.conf`
when testing these alternatives.)

—Ryan

P.S. I've posted a guide on my blog with a comprehensive rundown of the
steps I took to get it all set up — that might be able to clarify any
questions you might have about my configuration:

http://ryanlue.com/posts/2017-06-29-gpg-for-ssh-auth

If Werner is interested, I think the official website could really use
some friendlier Getting Started guides, and I'd be happy to contribute.
I posted my guide on /r/linux, and you'd be surprised at how many people
thought ssh authentication via gpg was an “unconventional hack”.


_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [HELP] pinentry-curses breaks SSH auth, but pinentry-mac works fine?

Peter Lebbing
On 30/06/17 05:54, Ryan Lue wrote:
> Does it have something to do with the `$GPG_TTY` environment variable
> not being set on the SSH server?

Almost; it has to do with the GPG_TTY variable not being communicated to
the agent.  The agent does not know on which tty the request for a
pinentry is made. To use a text mode pinentry with SSH, you need to invoke:

$ gpg-connect-agent updatestartuptty /bye

on the tty where you'll be SSH'ing (or some variation, this one is
pretty succinct). Otherwise the pinentry will pop up on the tty where
you did that last, or the tty that started the agent if you never did
it. That tty might not exist, not exist anymore, or be in a surprising
location.

It would be really good if the SSH agent protocol would be extended to
communicate on which tty a request comes in. Without updates to the SSH
protocol, there is simply no way to know where it comes from.

However, I think many people work around this problem by a) using a
graphical pinentry and b) using a single graphical session. As long as
one also refrains from SSH'ing from a remote terminal, with the
combination, you've circumvented the problem by just using the
effectively singleton graphical session :-).

> I posted my guide on /r/linux, and you'd be surprised at how many
> people thought ssh authentication via gpg was an “unconventional
> hack”.

That is a surprising characterization. Do they also think this of the
GNOME and KDE SSH agents, to name two? I suspect those two are much more
widely used, which might eliminate the qualification "unconventional",
but that still begs, why "hack"?

I'd wager that this problem also occurs with the GNOME and KDE SSH
agents, if you for instance share a "screen" session with a Linux
virtual terminal (which would take care of sharing SSH_AGENT). My guess
is if you SSH from the virtual terminal, it'll freeze while your
"swapped out" graphical session invisibly prompts you to enter your
passphrase. But I haven't tried it.

HTH,

Peter.

--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [HELP] pinentry-curses breaks SSH auth, but pinentry-mac works fine?

Guilhem Moulin
On Fri, 30 Jun 2017 at 18:29:41 +0200, Peter Lebbing wrote:
> It would be really good if the SSH agent protocol would be extended to
> communicate on which tty a request comes in. Without updates to the SSH
> protocol, there is simply no way to know where it comes from.

I also hope some day this will happen :-)
 
> However, I think many people work around this problem by a) using a
> graphical pinentry and b) using a single graphical session. As long as
> one also refrains from SSH'ing from a remote terminal, with the
> combination, you've circumvented the problem by just using the
> effectively singleton graphical session :-).

Another other (somewhat ugly) hack is to define a ProxyCommand in your
ssh_config(5) file.

    ProxyCommand sh -c 'gpg-connect-agent updatestartuptty /bye >/dev/null && nc "$0" "$1"' %h %p

That one is particularly ugly as children are kept alive during the whole
time of the SSH session (and file descriptors are wasted for the pipe
and the socket):

    ssh example.net
      └─sh -c gpg-connect-agent updatestartuptty /bye >/dev/null && nc "$0" "$1" example.net 22
          └─nc odin.guilhem.org 22

With recent OpenSSH and OpenBSD's implementation of nc(1)
(netcat-openbsd package on Debian) it's possible to have the
ProxyCommand pass the connected socket back to ssh and exit, so there is
no wasted ressource during the session:

    ProxyCommand sh -c 'gpg-connect-agent updatestartuptty /bye >/dev/null && nc -F "$0" "$1"' %h %p
    ProxyUseFDpass yes

Still, it's unfortunate to have to fork a shell just for that.  I wrote
a little C wrapper (to call the Assuan command, connect to the remote
host, pass the descriptor, and exit) some time ago, but clearly the
proper fix is to extend the SSH agent protocol.

--
Guilhem.

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [HELP] pinentry-curses breaks SSH auth, but pinentry-mac works fine?

Daniel Kahn Gillmor-7
In reply to this post by Ryan Lue
Hi Ryan--

On Fri 2017-06-30 11:54:46 +0800, Ryan Lue wrote:
> But for some reason, it just doesn't work with `pinentry-curses`: SSH
> (GPG) key authentication fails silently, and the server falls back to
> password authentication. (I have made sure to set `$GPG_TTY`, so
> `pinentry-curses` works just fine for everything else, just not SSH
> authentication. For instance, I can `echo hello | gpg -s` and I'll get
> the pinentry password prompt in the terminal.)

setting GPG_TTY only works for clients that know to interpret it and to
pass its value along to gpg-agent.

when ssh is speaking to gpg-agent, it's using the ssh-agent protocol,
which has no mechanism for passing this info to the agent.

as a result, the agent (which *isn't* running attached to the current
tty) can't tell pinentry which tty to use.

have you tried doing this:

    GPG_TTY=$(tty) gpg-connect-agent updatestartuptty /bye

from the current terminal before trying to use ssh?

i consider this a workaround (which isn't satisfactory for easy everyday
use without better integration), but it's probably better than nothing.

please let the list know if that workarund works for you!

regards,

     --dkg

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [HELP] pinentry-curses breaks SSH auth, but pinentry-mac works fine?

Ryan Lue
Hi Daniel,

Yes, thanks, this absolutely did it! Sorry for not responding earlier —
I had intended to write a follow-up blog post that addressed this
question, along with that of forwarding the gpg-agent socket over SSH
with `ssh -R` (so that you can use your local machine's GPG private keys
in a remote session without having to manually copy them to another
machine), but figuring out how to do all that with pinentry-curses has
proven to be a real pickle.

So while I was originally going to wait until I'd finished that post and
send it back your way (as a weird kind of thank-you?), I'm just gonna
have to settle for actually saying “thank you” for the time being.

So, thanks.

—Ryan

On 2017 Jun 30, Daniel Kahn Gillmor wrote:

> Hi Ryan--
>
> On Fri 2017-06-30 11:54:46 +0800, Ryan Lue wrote:
> > But for some reason, it just doesn't work with `pinentry-curses`: SSH
> > (GPG) key authentication fails silently, and the server falls back to
> > password authentication. (I have made sure to set `$GPG_TTY`, so
> > `pinentry-curses` works just fine for everything else, just not SSH
> > authentication. For instance, I can `echo hello | gpg -s` and I'll get
> > the pinentry password prompt in the terminal.)
>
> setting GPG_TTY only works for clients that know to interpret it and to
> pass its value along to gpg-agent.
>
> when ssh is speaking to gpg-agent, it's using the ssh-agent protocol,
> which has no mechanism for passing this info to the agent.
>
> as a result, the agent (which *isn't* running attached to the current
> tty) can't tell pinentry which tty to use.
>
> have you tried doing this:
>
>     GPG_TTY=$(tty) gpg-connect-agent updatestartuptty /bye
>
> from the current terminal before trying to use ssh?
>
> i consider this a workaround (which isn't satisfactory for easy everyday
> use without better integration), but it's probably better than nothing.
>
> please let the list know if that workarund works for you!
>
> regards,
>
>      --dkg



_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [HELP] pinentry-curses breaks SSH auth, but pinentry-mac works fine?

Ryan Lue
In reply to this post by Peter Lebbing
> However, I think many people work around this problem by a) using a
> graphical pinentry and b) using a single graphical session. As long as
> one also refrains from SSH'ing from a remote terminal, with the
> combination, you've circumvented the problem by just using the
> effectively singleton graphical session :-).

That solution has certainly occurred to me. There were two reasons I was
really angling to get this working purely in the terminal:

1) I keep my dotfiles synced between multiple machines, and so try my
   best to keep them platform-agnostic when I can. There are definitely
   times when I can use conditionals to get different behavior on
   different machines (like `if [ "$(uname)" = Darwin ]` in `.profile`),
   but I don't even know if it's possible to set up `gpg-agent.conf` to
   use `pinentry-mac` on one machine but `pinentry-gtk` on another.

2) I chanced upon this presentation from a 2015 conference where the
   presenter describes a setup for being able to ssh into a machine and
   use its private keys locally by forwarding the remote machine's
   gpg-agent socket to a local socket (slides 57–61 of 62):

   https://2015.rmll.info/IMG/pdf/an-advanced-introduction-to-gnupg.pdf

   and I imagine that just wouldn't work if you had graphical pinentry
   on the remote machine. I did also find another tip about using
   `PINENTRY_USER_DATA` to force pinentry-curses for SSH sessions, but
   I'd already burned so much time on this that I haven't been able to
   justify getting around to it again:

   https://gpgtools.tenderapp.com/kb/faq/enter-passphrase-with-pinentry-in-terminal-via-ssh-connection

   None of this was crucial, mind you; I was just trying to see what I
   could do with a new toy. -_-'

> That is a surprising characterization. Do they also think this of the
> GNOME and KDE SSH agents, to name two? I suspect those two are much more
> widely used, which might eliminate the qualification "unconventional",
> but that still begs, why "hack"?

There were a lot of strong opinions being thrown around that thread. I
suspect that a lot of people believe that taking an unconventional
approach to security is tantamount to opposing best practices.

In any case, thanks for all the insight!

—Ryan

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [HELP] pinentry-curses breaks SSH auth, but pinentry-mac works fine?

Peter Lebbing
On 13/07/17 09:29, Ryan Lue wrote:
> 1) I keep my dotfiles synced between multiple machines, and so try my
>    best to keep them platform-agnostic when I can. There are definitely
>    times when I can use conditionals to get different behavior on
>    different machines (like `if [ "$(uname)" = Darwin ]` in `.profile`),
>    but I don't even know if it's possible to set up `gpg-agent.conf` to
>    use `pinentry-mac` on one machine but `pinentry-gtk` on another.

Note how Debian handles system-wide, system-specific pinentry alternatives:

/etc/alternatives/pinentry -> /usr/bin/pinentry-gtk-2
/etc/alternatives/pinentry-x11 -> /usr/bin/pinentry-gtk-2
/usr/bin/pinentry -> /etc/alternatives/pinentry
/usr/bin/pinentry-curses
/usr/bin/pinentry-gtk-2
/usr/bin/pinentry-x11 -> /etc/alternatives/pinentry-x11

If you use just "pinentry" or "pinentry-x11", you then use the
alternatives system to select a specific one:

--8<---------------cut here---------------start------------->8---
# update-alternatives --config pinentry
There are 2 choices for the alternative pinentry (providing
/usr/bin/pinentry).

  Selection    Path                      Priority   Status
------------------------------------------------------------
* 0            /usr/bin/pinentry-gtk-2    85        auto mode
  1            /usr/bin/pinentry-curses   50        manual mode
  2            /usr/bin/pinentry-gtk-2    85        manual mode

Press enter to keep the current choice[*], or type selection number:
--8<---------------cut here---------------end--------------->8---

It might give you an idea how to do it for you. I suspect it might even
work if you wrap your pinentry in a shell script using if [ "$(uname)"
but it lacks elegance.

> 2) I chanced upon this presentation from a 2015 conference where the
>    presenter describes a setup for being able to ssh into a machine and
>    use its private keys locally by forwarding the remote machine's
>    gpg-agent socket to a local socket (slides 57–61 of 62):
>
>    https://2015.rmll.info/IMG/pdf/an-advanced-introduction-to-gnupg.pdf
>
>    and I imagine that just wouldn't work if you had graphical pinentry
>    on the remote machine.

You could also use SSH's X forwarding. I haven't tried that, though.

> There were a lot of strong opinions being thrown around that thread. I
> suspect that a lot of people believe that taking an unconventional
> approach to security is tantamount to opposing best practices.

Hmmm, an understandable knee-jerk response. Knees don't always do your
best thinking, though.

HTH,

Peter.

--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

signature.asc (499 bytes) Download Attachment
Loading...