3

Client:

  • Arch based distro
  • OpenSSH package version: 9.3p1-2
  • SSH-Agent started with ssh-agent -c in fish shell
  • Key generated with: ssh-keygen -t ed25519-sk -f ~/.ssh/servers_ed25519_sk -O verify-required

Server:

  • Server as VM spun up with vagrant
  • Debian 11
  • openssh-server version: 1:8.4p1-5+deb11u1

Initial client command:

ssh vagrant@127.0.0.1 -p22150 -i ~/.ssh/servers_ed25519_sk -vvv -o IdentitiesOnly=yes

Explanation:

  • ssh vagrant@127.0.0.1 -p22150: vagrant related.
  • -vvv: verbose output
  • -o IdentitiesOnly=yes: To avoid using other keys (vagrant generates a private key that is stored in the ssh-agent and used if not forbidden).

When running the command, everything is requested: Passphrase, PIN and Touch. Initial connection works.

The key is automatically added to the ssh-agent during the first run.

Same command run again. Output:

debug1: Offering public key: ~/.ssh/servers_ed25519_sk ED25519-SK SHA256:XXX explicit authenticator agent
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: ~/.ssh/servers_ed25519_sk ED25519-SK SHA256:XXX explicit authenticator agent
debug3: sign_and_send_pubkey: using publickey with ED25519-SK SHA256:XXX
debug3: sign_and_send_pubkey: signing using sk-ssh-ed25519@openssh.com SHA256:XXX
sign_and_send_pubkey: signing failed for ED25519-SK "~/.ssh/servers_ed25519_sk" from agent: agent refused operation

There is no prompt or anything alike to re-enter the PIN. So I guess that is the problem, because the key is generated with verify-required option.

It is my understanding, that since version 8.9 openssh client should be capable of deadling with ed25519-sk keys in the agents. It seems no to be a server problem, since the initial connection works. So why is this not working?

func0der
  • 171

2 Answers2

2

Add IdentityAgent none to your ~/.ssh/config or pass the option -o IdentityAgent=none to the ssh command.

IdentityAgent none disables external ssh-agent's.

According to Arch Wiki there is a bug for keys that were created with -O verify-required.

Giacomo1968
  • 58,727
telephone
  • 121
  • 3
0

I found a solution myself.

When you initially connect to the server everything is in the foreground of the active terminal session, so you can be prompted for stuff right there an then. After the initial connection and with an ssh agent running, the "opened" key is saved in the agent.

What is not saved is the PIN for the second factor. Is has to be requested every time you want to use the second factor. For this question to work you have to have the environment variable SSH_ASKPASS set to a binary that ssh password requests.

For KDE you could for example /usr/bin/ksshaskpass. What you use and where you configure environment variables for your shell depends 100% on your setup, desktop environment etc.

(i) Following now are assumptions WHY things are this way.

Here is why I think you have to set it up like this.

As mentioned above ssh asks for the PIN on the terminal on first connection, only after that it does not anymore. I figure this is because ssh does handle the access to the key on first connection itself. After opening the key with the correct passphrase, it then hands over this responsibility to the ssh-agent. The ssh-agent is also the actor that on subsequent connections realizes what kind of key we are dealing with and that a second factor is needed. Since the ssh-agent is a background process that is potentially shared between multiple terminals/shell instances, it does not know WHERE where to attach to ask for the password. That is why it needs the environment variable SSH_ASKPASS pointing to a binary that can handle those inputs for it. It just spawns the program, waits for it to return the user input and the proceeds. If the variable is not set, it just fails.

As annoying as this is, there is probably no way around it and since 2fa for ssh keys is still not that common for most users, it will probably take some time until it changes behavior. If that is at all possible.

func0der
  • 171