Mailing List Archive

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

On 22/03/2021 09:58, Jochen Bern wrote:
> Umh, *does* every privKey that ssh "offers" (as the debug output calls
> it) qualify as an actual authentication attempt, and thus count against
> MaxAuthTries?

Yes, in my experience it does, and with a large keyring collection in
the agent, or with a lot of keys located at default paths, a server with
a low MaxAuthTries limit will boot me out, before I can even attempt
auth, unless I specify an explicit IdentityFile= and also specify
IdentitiesOnly=yes (so that it doesn't try any others, even those
located at default paths).

Regards,
Aaron Jones

On 3/22/21 1:09 PM, Aaron Jones wrote:
> On 22/03/2021 09:58, Jochen Bern wrote:
>> Umh, *does* every privKey that ssh "offers" (as the debug output calls
>> it) qualify as an actual authentication attempt, and thus count against
>> MaxAuthTries?
>
> Yes, in my experience it does, and with a large keyring collection in
> the agent, or with a lot of keys located at default paths, a server with
> a low MaxAuthTries limit will boot me out, before I can even attempt
> auth, unless I specify an explicit IdentityFile= and also specify
> IdentitiesOnly=yes (so that it doesn't try any others, even those
> located at default paths).

Below is how it looks from the client if there are seven keys in the
agent and the server is set for MaxAuthTries of 6 and the seventh key is
the one that is needed. For this example, there are no keys in ~/.ssh/
on the client, the extra keys were loaded from another location and the
resident key was loaded into the agent directly from the hardware token.

/Lars

OpenSSH_8.5, LibreSSL 3.3.2
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to xx.yy.zz.1 [xx.yy.zz.1] port 22.
debug1: Connection established.
debug1: identity file /home/foo/.ssh/id_rsa type -1
debug1: identity file /home/foo/.ssh/id_rsa-cert type -1
debug1: identity file /home/foo/.ssh/id_dsa type -1
debug1: identity file /home/foo/.ssh/id_dsa-cert type -1
debug1: identity file /home/foo/.ssh/id_ecdsa type -1
debug1: identity file /home/foo/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/foo/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/foo/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/foo/.ssh/id_ed25519 type -1
debug1: identity file /home/foo/.ssh/id_ed25519-cert type -1
debug1: identity file /home/foo/.ssh/id_ed25519_sk type -1
debug1: identity file /home/foo/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/foo/.ssh/id_xmss type -1
debug1: identity file /home/foo/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.5
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.5
debug1: compat_banner: match: OpenSSH_8.5 pat OpenSSH* compat 0x04000000
debug1: Authenticating to xx.yy.zz.1:22 as 'foo'
debug1: load_hostkeys: fopen /home/foo/.ssh/known_hosts2: No such file
or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or
directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC:
<implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC:
<implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ecdsa-sha2-nistp256
SHA256:t9pNvmtPBL1aF1KSwCWPhKDvHWjuc+JRADd+Lwo6a8I
debug1: load_hostkeys: fopen /home/foo/.ssh/known_hosts2: No such file
or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or
directory
debug1: Host 'xx.yy.zz.1' is known and matches the ECDSA host key.
debug1: Found key in /home/foo/.ssh/known_hosts:1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: foo@notebook.localnet.lan ECDSA
SHA256:3bv7t8Enatq/FlViX7TMjfzn8E4mnmrB4iVLqeftSSo agent
debug1: Will attempt key: foo@notebook.localnet.lan ECDSA
SHA256:uZYDGVKzk/Casnz3epqqLS0uEEvn6vpvg+6/J6YjD/I agent
debug1: Will attempt key: foo@notebook.localnet.lan ECDSA
SHA256:viucCIEHXF2nE3k0GvB1acIasHFCoFEBvgLuCgDEJ7s agent
debug1: Will attempt key: foo@notebook.localnet.lan ECDSA
SHA256:vIb1cYSHBXMp5BEe2Kr8go+k/DQf9JcXCCwLpV70E5c agent
debug1: Will attempt key: foo@notebook.localnet.lan ECDSA
SHA256:ZTmrbytuzGBE/GK8YBkj41AkS9JacZxoyuFZWwpF5Zg agent
debug1: Will attempt key: foo@notebook.localnet.lan ECDSA
SHA256:ORYKRU3jyGhkk6zfu84Pew0cBLb+K4DLHNZvjeflxOk agent
debug1: Will attempt key: ED25519-SK
SHA256:pTouVKi3dKmAINwkY04Be3YKnIpUF/FoIIM0VxPTBJg authenticator agent
debug1: Will attempt key: /home/foo/.ssh/id_rsa
debug1: Will attempt key: /home/foo/.ssh/id_dsa
debug1: Will attempt key: /home/foo/.ssh/id_ecdsa
debug1: Will attempt key: /home/foo/.ssh/id_ecdsa_sk
debug1: Will attempt key: /home/foo/.ssh/id_ed25519
debug1: Will attempt key: /home/foo/.ssh/id_ed25519_sk
debug1: Will attempt key: /home/foo/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info:
server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,webauthn-sk-ecdsa-sha2-nistp256@openssh.com>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: foo@notebook.localnet.lan ECDSA
SHA256:3bv7t8Enatq/FlViX7TMjfzn8E4mnmrB4iVLqeftSSo agent
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Offering public key: foo@notebook.localnet.lan ECDSA
SHA256:uZYDGVKzk/Casnz3epqqLS0uEEvn6vpvg+6/J6YjD/I agent
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Offering public key: foo@notebook.localnet.lan ECDSA
SHA256:viucCIEHXF2nE3k0GvB1acIasHFCoFEBvgLuCgDEJ7s agent
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Offering public key: foo@notebook.localnet.lan ECDSA
SHA256:vIb1cYSHBXMp5BEe2Kr8go+k/DQf9JcXCCwLpV70E5c agent
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Offering public key: foo@notebook.localnet.lan ECDSA
SHA256:ZTmrbytuzGBE/GK8YBkj41AkS9JacZxoyuFZWwpF5Zg agent
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Offering public key: foo@notebook.localnet.lan ECDSA
SHA256:ORYKRU3jyGhkk6zfu84Pew0cBLb+K4DLHNZvjeflxOk agent
Received disconnect from xx.yy.zz.1 port 22:2: Too many authentication
failures
Disconnected from xx.yy.zz.1 port 22
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Mar 22, 2021, at 10:17 PM, Damien Miller <djm@mindrot.org> wrote:
> 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.


This is definitely possible. I have it implemented in AsyncSSH using the standard FIDO2 library. For what it’s worth, the AsyncSSH function for this currently looks like the following:

def load_resident_keys(pin, *, application='ssh:', user=None,
touch_required=True):
"""Load keys resident on attached FIDO2 security keys

This function loads keys resident on any FIDO2 security keys
currently attached to the system. The user name associated
with each key is returned in the key's comment field.

:param pin:
The PIN to use to access the security keys, defaulting to `None`.
:param application: (optional)
The application name associated with the keys to load,
defaulting to `'ssh:'`.
:param user: (optional)
The user name associated with the keys to load. By default,
keys for all users are loaded.
:param touch_required: (optional)
Whether or not to require the user to touch the security key
when authenticating with it, defaulting to `True`.
:type application: `str`
:type user: `str`
:type pin: `str`
:type touch_required: `bool`

“""

Given a PIN, this will load the subset of keys matching the requested application and user (if specified), with the application defaulting to ’ssh:’ and the user defaulting to loading keys for all user names with the user name being added to the key’s comment.

Once loaded, you can specify the resulting key objects as a “client_keys” argument in whatever calls you like that require private keys, instead of specifying raw key data or a filename containing a key.

This call also lets you specify whether to require touch on the key when it is used. Of course, the server needs to also specify ’no-touch-required’ for that to be allowed.
--
Ron Frederick
ronf@timeheart.net



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

On 3/23/21 7:17 AM, Damien Miller wrote:
> 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.
[snip]
> A slightly-terrible workaround might be to download all the keys to the
> agent and delete the "wrong" ones.

Thanks. Here are two more work-arounds.

One work-around is to use a one-off agent for just the one key.

$ ssh-agent zsh

% ssh-add -K
Enter PIN for authenticator:
Resident identity added: ED25519-SK
SHA256:Arx/LPnXEhOvBQBQXpGc3J/ToyjQ7VA5IFcabx6GMcQ

% ssh -o IdentitiesOnly=no 10.10.10.100

Another option, looking at it some more, is to identify the key using
just the public key even if the private key is absent from the file
system. So that's sort of a another work-around.

$ ssh -i ~/.ssh/id_ed25519_sk.pub 10.10.10.100

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