Reputation: 315
I have created SSH key on Yubikey 5 Nano using FIDO2:
ssh-keygen -t ed25519-sk -f ~/.ssh/id_ed25519-sk
The Yubikey has user and admin PIN set.
When using the key for establishing a SSH connection however, there is no message about requiring to touch the key like on the Github blog Security keys are now supported for SSH Git operations:
Confirm user presence for key ...
In verbose mode the SSH client displays:
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /.../.ssh/id_ed25519-sk ED25519-SK SHA256:... explicit authenticator agent
debug1: Server accepts key: /.../.ssh/id_ed25519-sk ED25519-SK SHA256:... explicit authenticator agent
at which point the Yubikey starts flashing. Once I touch it, the SSH login succeeds with that key and the subsequent messages will be:
debug1: Authentication succeeded (publickey).
Authenticated to github.com (via proxy).
When using the key for Git operations like git clone
or git pull
, it just silently waits for the key tap. The issue I have with this behavior is I don't know whether the SSH client is waiting for the network/server/proxy or for me to touch the key.
This is on Ubuntu 20.04.4 LTS with OpenSSH 8.2p1 (and Git 2.28.0). I am using the default ssh-agent and I can see the key listed in the 'Passwords and keys' application in Gnome under 'OpenSSH keys'.
Using ssh-keygen
compiled from the OpenSSH 9.0p1 portable source, I can see that the public key has the flags set to 0x1 (user presence required):
$ ./ssh-keygen -vvv -y -f ~/.ssh/id_ed25519-sk
[email protected] AAAAGnNrLX...mAAAABHNzaDo= foo@bar
debug1: sk_application: "ssh:", sk_flags 0x01
This flag should in theory trigger the message however it does not. The OpenSSH 9.0p1 SSH client has the same behavior so I assume this lack of the message is caused by something in my setup.
Adding some debug debug code to identity_sign()
in sshconnect2.c
, I can see it calls ssh_agent_sign()
and returns. Checking the source code of process_sign_request2()
in ssh-agent.c
, it contains the code to emit the message for "sk" keys.
When the SSH client is waiting for the key touch, the relevant process tree looks like this:
gnome-keyring-d(57868)-+-ssh-agent(58517)---ssh-sk-helper(79174)
|-{gnome-keyring-d}(57869)
|-{gnome-keyring-d}(57870)
|-{gnome-keyring-d}(57982)
`-{gnome-keyring-d}(79173)
Once the key touch happens, the ssh-sk-helper
process goes away.
So it seems like if ssh-agent
emitted the message, it did not get to the ssh
process.
Upvotes: 1
Views: 2364
Reputation: 315
This is more of a workaround than proper answer, however it provides a way to fix the behavior. There are multiple factors (sic!) to this:
Firstly, there is something in Ubuntu which is automatically adding the keys in ~/.ssh
directory to the ssh-agent
started on login - once I create a key using ssh-keygen
, the key appears automatically in the output of ssh-add -l
. It is probably not ssh itself, because I do not have AddKeysToAgent
set in my ~/.ssh/config
(or the global config) and the default value of this directive is no
.
To overcome this behavior, I generated the key files in different location (~/altssh
).
Next, ssh prefers the keys stored in ssh-agent so this needs to be changed as well, using the IdentitiesOnly
directive set to yes
.
The ssh configuration snippet that makes the 'Confirm user presence' message to be emitted:
Host *github.com
User git
# ssh will prefer the keys stored in ssh-agent to the one from
# the identity file so this behavior needs to be changed.
IdentitiesOnly yes
# for a good measure
IdentityAgent none
# The keys from ~/.ssh will be added to the ssh-agent automatically
# which I want to avoid because then the 'Confirm user presence'
# message will not be displayed.
IdentityFile ~/altssh/id_ed25519-sk
With this in place, it works:
$ ssh-add -l | grep 25519 | wc -l
0
$ ssh -T github.com
Confirm user presence for key ED25519-SK SHA256:...
Hi ...! You've successfully authenticated, but GitHub does not provide shell access.
Still, I think this is a limitation of how the ssh-agent communication works in OpenSSH. Also, perhaps Ubuntu should not be adding the sk
keys to the ssh-agent as a second level workaround.
Upvotes: 3