ssh-agent hides sk "confirm user presence" message

[ope...@tr.id.au]

Hey there,

I've noticed some unexpected behavior when I occasionally need to forward an ed25519-sk key with ssh-agent. When using the key without an agent, it prompts with a reminder to touch the key:

$ ssh user@remote
Confirm user presence for key ED25519-SK MD5:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
User presence confirmed

But as soon as I add the key to an agent, it now hides that reminder:

$ ssh-agent /bin/bash
$ ssh-add /path/to/key
Identity added: /path/to/key (ssh:keyname)
$ ssh user@remote
<key starts blinking but no reminder to touch it>

I first noticed it when forwarding the agent, but it's reproducible locally without forwarding required.

Some people might prefer to keep the message hidden, which would be okay by me if I could choose to toggle it on. I don't see any options in the various openssh manpages to allow that though. It also seems inconsistent with the expectations set when I use the key without an agent.

Could you consider adding an option which would allow forcing the message to appear when used with an agent? I think an argument could be made this should be the default behavior, but I'm not going to die on that hill, I'd be content with a configurable toggle.

Cheers,

Tim

_______________________________________________
openssh-unix-dev mailing list
openssh-...@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

[Damien Miller]

On Mon, 16 Oct 2023, ope...@tr.id.au wrote:

> Hey there,
>
> I've noticed some unexpected behavior when I occasionally need to forward an ed25519-sk key with ssh-agent. When using the key without an agent, it prompts with a reminder to touch the key:
>
> $ ssh user@remote
> Confirm user presence for key ED25519-SK MD5:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
> User presence confirmed
>
> But as soon as I add the key to an agent, it now hides that reminder:
>
> $ ssh-agent /bin/bash
> $ ssh-add /path/to/key
> Identity added: /path/to/key (ssh:keyname)
> $ ssh user@remote
> <key starts blinking but no reminder to touch it>
>
> I first noticed it when forwarding the agent, but it's reproducible locally without forwarding required.
>
> Some people might prefer to keep the message hidden, which would be okay by me if I could choose to toggle it on. I don't see any options in the various openssh manpages to allow that though. It also seems inconsistent with the expectations set when I use the key without an agent.
>
> Could you consider adding an option which would allow forcing the message to appear when used with an agent? I think an argument could be made this should be the default behavior, but I'm not going to die on that hill, I'd be content with a configurable toggle.

Generally we prefer to use ssh-askpass for agent notifications. Are you able to use that?

-d

[ope...@tr.id.au]

Hey Damien,

> Generally we prefer to use ssh-askpass for agent notifications. Are you able to use that?

Hmm, okay, but it's not clear to me how to make that work. Is what you have in mind documented somewhere? I don't see this specific situation covered in the manpages and a web search doesn't turn up much.

I thought ssh-askpass was only invoked when the key is first added to the agent. To be clear, my ed25519-sk key does add to the agent successfully with no presence required at that time. It is only later, when the client goes to use the key, that a presence challenge is issued.

If ssh-add issued an immediate challenge and then "cached" the user presence, I might see how ssh-askpass could get involved. And maybe that would even be preferable, if I only had to touch once at the start of a session and then not have to demonstrate user presence again until the key is removed. But that isn't the situation I'm describing. The situation is that no user presence is required when adding the key, but it is required later when ssh-askpass isn't involved (iiuc.)

Is there something I've overlooked or misunderstanding?

~ Tim

[ope...@tr.id.au]

> Is there something I've overlooked or misunderstanding?

Okay, digging into it a bit more, I think I can see why you'd balk at my request :)

When I run the agent in debug mode (ssh-agent -d) I can see the request for user presence now appears:

```
$ ssh-agent -d
SSH_AUTH_SOCK=/tmp/ssh-XXXXXXXXXXXX/agent.XXXXX; export SSH_AUTH_SOCK;
...
debug2: process_extension: entering
debug2: process_ext_session_bind: entering
debug1: process_ext_session_bind: recorded ED25519 SHA256:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX (slot 0 of 16)
debug1: process_message: socket 1 (fd=4) type 11
debug2: process_request_identities: entering
debug3: identity_permitted: entering: key ED25519-SK comment "ssh:keyname", 1 socket bindings, 0 constraints
debug2: process_request_identities: replying with 1 allowed of 1 available keys
debug1: process_message: socket 1 (fd=4) type 13
debug1: process_sign_request2: entering
Confirm user presence for key ED25519-SK SHA256:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
```

So I guess the problem is, no good way exists for the agent to pass that request back to the same terminal where I am invoking the ssh client?

In that case, do any examples exist of how to get the agent to detect when "Confirm user presence" is being requested, and I suppose use SSH_ASKPASS to expose the message?

[Jochen Bern]

On 16.10.23 04:59, Damien Miller wrote:
> On Mon, 16 Oct 2023, ope...@tr.id.au wrote:
>> When using the key without an agent, it prompts with a reminder to touch the key:
>>
>> $ ssh user@remote
>> Confirm user presence for key ED25519-SK MD5:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX

[...]

>> But as soon as I add the key to an agent, it now hides that reminder
>

> Generally we prefer to use ssh-askpass for agent notifications.

*Which* ssh-askpass, OpenBSD's (with the "LEDs" underneath and "only"
the usual range of X11 options), GNOME's (which doesn't react to
"--help", "-h", or "-?", and doesn't seem to have a manpage, either), or
KDE's (with a selection of possible options, including "--help",
"--author", "--license", and Qt-specific ones)?

As far as I know, they would all require a (in the OP's use case,
*second*) user interaction to close them again, and are pretty much
unusable for any *multiline* notifications (say, something similar to
"VisualHostKey=yes") ...

However, IIUC the real problem with the OP's request is that it is
indeed the *agent* asking (or not ...) the user to complete the
authentication, whereas in the empty-agent version, it's the *ssh*
command - which *is* connected to a terminal - doing so. Hence, the
prompt is not exactly "hidden", but doesn't readily *have* a place to
show up in.

Kind regards,
--
Jochen Bern
Systemingenieur

Binect GmbH

[Christian Weisgerber]

ope...@tr.id.au:

> Hmm, okay, but it's not clear to me how to make that work.

You only need to have ssh-askpass installed. It will be automatically
invoked by ssh-agent.

> I thought ssh-askpass was only invoked when the key is first added to the agent.

No, ssh-askpass is called every time ssh-agent needs some user
interaction. For instance, you can use "ssh-add -c" to load a key
that requires confirmation for each use. Each time you authenticate
with that key, ssh-askpass will pop up and require a key press.

> If ssh-add issued an immediate challenge and then "cached" the user presence, I might see how ssh-askpass could get involved. And maybe that would even be preferable, if I only had to touch once at the start of a session and then not have to demonstrate user presence again until the key is removed.

Well, that's not how "user presence" is understood as a security
concept. User presence is required at the time of authentication.
Note that user presence is part of the FIDO/U2F specification and
is included in the signature generated by the FIDO/U2F hardware and
verified by the remote sshd. ssh-agent cannot fake this.

--
Christian "naddy" Weisgerber na...@mips.inka.de

[Christian Weisgerber]

Jochen Bern:

> *Which* ssh-askpass, OpenBSD's (with the "LEDs" underneath and "only" the
> usual range of X11 options), GNOME's (which doesn't react to "--help", "-h",
> or "-?", and doesn't seem to have a manpage, either), or KDE's (with a
> selection of possible options, including "--help", "--author", "--license",
> and Qt-specific ones)?
>
> As far as I know, they would all require a (in the OP's use case, *second*)
> user interaction to close them again,

No, ssh-askpass closes automatically when you touch the authenticator.
This should be independent of the ssh-askpass implementation: After
reading the signature from the authenticator, ssh-agent sends a
SIGTERM to the ssh-askpass process.

--
Christian "naddy" Weisgerber na...@mips.inka.de

[ope...@tr.id.au]

Thanks everyone for the patience and the tips. I installed x11-ssh-askpass; ssh-agent found it automatically and everything works as expected.

It would be nice to know how it is implemented, i.e. how the askpass dialog knows that user presence is being requested. Ideally I'd rather have notifications like this appear via dunst, i.e. have an SSH_ASKPASS script that detects whether user presence is being detected and in that case use notify-send before falling back to x11-ssh-askpass. I guess I may have to poke at some x11-ssh-askpass and ssh-agent sources some time to see what the interaction looks like under the hood.

Cheers,

Tim

[Jim Knoble]

Greetings, Programs!

> On Oct 17, 2023, at 15:47, ope...@tr.id.au wrote:
>
> [...] I installed x11-ssh-askpass; ssh-agent found it automatically and everything works as expected.

Wow. Scary to know that's still around and still works. Profuse apologies for that.

> It would be nice to know how [...] the askpass dialog knows that user presence is being requested.

ssh-askpass doesn't have any idea what's bein requested; if I recall correctly, it displays whatever message it was called with, and it prints on Syd out whatever I put it received, exiting with status zero for OK or nonzero for Cancel.

It's ssh-agent or ssh-add that "know" about user presence, insofar as that can be known.

That is to say, the source code you probably want to look at is in ssh-agent, rather than x11-ssh-askpass.

--
jim knoble

[Jim Knoble]

> On Oct 17, 2023, at 16:22, Jim Knoble <jmkn...@pobox.com> wrote:
>
> [...] prints on Syd out whatever I put it received [...].

"prints on _stdout_ whatever _input_ it received"

Thanks, auto-incorrect.

[ope...@tr.id.au]

> Wow. Scary to know that's still around and still works. Profuse apologies for that.

lol. There is a niche for it for people like me who don't want to pull in all the baggage of a fullblown desktop environment. Like, I'm sure lxqt-ssh-askpass (which I considered using because it's in my package manager) *looks* prettier, but I don't want to install the rest of lxqt just to get it.

> ssh-askpass doesn't have any idea what's bein requested; if I recall correctly, it displays whatever message it was called with, and it prints on Syd out whatever I put it received, exiting with status zero for OK or nonzero for Cancel.
>
> It's ssh-agent or ssh-add that "know" about user presence, insofar as that can be known.
>
> That is to say, the source code you probably want to look at is in ssh-agent, rather than x11-ssh-askpass.

Thanks for the tip, that's useful to know.

~ Tim

[Thorsten Glaser]

On Wed, 18 Oct 2023, ope...@tr.id.au wrote:

>> Wow. Scary to know that's still around and still works. Profuse apologies for that.
>
>lol. There is a niche for it for people like me who don't want to pull
>in all the baggage of a fullblown desktop environment.

Definitely!

On my work system, though, I use kwalletaskpass, which I wrote myself,
to put some of the answers, mostly these for the SSH and PGP key, into
the KDE wallet, and uses pinentry for the rest.

http://www.mirbsd.org/cvs.cgi/contrib/hosted/tg/code/kwalletcli/kwalletaskpass?rev=HEAD

It is selected by setting SSH_ASKPASS to the path of it in the
environment of the ssh-add(1) process.

Good luck,
//mirabilos
--
Infrastrukturexperte • Qvest Digital AG
Am Dickobskreuz 10, D-53121 Bonn • https://www.qvest-digital.com/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 18196 • USt-ID (VAT): DE274355441
Vorstand: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Vorsitzender Aufsichtsrat: Peter Nöthen