openssh unix dev - Mar 2021 - Finding a resident key stored in an agent without a corresponding file?

I have a question about SK keys when there are more than 6 keys in the
agent.

If I have added an SK key as resident to a hardware token, using the -O
resident option with ssh-keygen(1), then the -K option with ssh-add(1)
will get the resident key later from the token and store it in the agent.

$ ssh-add -K

With six or fewer keys in the agent, assuming default MaxAuthTries in
the server, it is then only a matter of having the SSH client use the
agent and the right key will be found.  However, with many keys already
in the agent, the key has to be specified explicitly or the 'wrong' keys
will get tried first.

I'd like to point the client directly to the resident key without first
extracting the resident key and saving it to the file system.  How may I
tell the SSH client which key to use without a file on disk?

$ ssh-add -l | awk '{print $1, $NF}'
256 (ED25519)
256 (ED25519)
2048 (RSA)
256 (ED25519)
256 (ED25519)
256 (ED25519)
4096 (RSA)
4096 (RSA)
4096 (RSA)
256 (ED25519)
256 (ECDSA-SK)
256 (ECDSA-SK)
256 (ECDSA-SK)
256 (ECDSA-SK)
256 (ECDSA-SK)
256 (ECDSA-SK)
256 (ED25519)
256 (ECDSA-SK)
256 (ED25519-SK)

/Lars

On 21.03.21 15:36, Lars Nood?n wrote:
> With six or fewer keys in the agent, assuming default MaxAuthTries in
> the server, it is then only a matter of having the SSH client use the
> agent and the right key will be found.  However, with many keys already
> in the agent, the key has to be specified explicitly or the 'wrong'
keys
> will get tried first.
Umh, *does* every privKey that ssh "offers" (as the debug output calls
it) qualify as an actual authentication attempt, and thus count against
MaxAuthTries? If I may trust my everyday experience with ssh-agent and
"ssh-add -c", there's no *signature* being generated with ones
that were
"offered" but refused.

Otherwise, your request would be quite clearly in the "provide a by-use
filter capability for the privKeys an ssh-agent holds" territory that
was discussed - with a focus on agent *forwarding*, though - on this
list a little while ago ...

Regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20210322/ad9ae509/attachment.p7s>

On Sun, 21 Mar 2021, Lars Nood?n wrote:
> I have a question about SK keys when there are more than 6 keys in the
> agent.
> 
> If I have added an SK key as resident to a hardware token, using the -O
> resident option with ssh-keygen(1), then the -K option with ssh-add(1)
> will get the resident key later from the token and store it in the agent.
> 
> $ ssh-add -K
> 
> With six or fewer keys in the agent, assuming default MaxAuthTries in
> the server, it is then only a matter of having the SSH client use the
> agent and the right key will be found.  However, with many keys already
> in the agent, the key has to be specified explicitly or the 'wrong'
keys
> will get tried first.
> 
> I'd like to point the client directly to the resident key without first
> extracting the resident key and saving it to the file system.  How may I
> tell the SSH client which key to use without a file on disk?
no such facility exists at present.

It wouldn't be hard to add such a capability to ssh, but we'd need to
figure out a good UI for it. FIDO2 AFAIK stores resident keys by 
{ user, application } name, so adding some way to download resident
keys and match/filter on these attributes would be the place to start.

This will probably require a change to the sk-api.h interface between
ssh and the FIDO hardware.

A slightly-terrible workaround might be to download all the keys to the
agent and delete the "wrong" ones.

-d