"Right now opkssh login writes the extracted private key file to ~/.ssh/id_ecdsa or ~/.ssh/id_dsa with the comment openpubkey such that it can be picked up by the OpenSSH client.

You cannot rely on the id_dsa filename being read by the client in newer version. The id_dsa filename is normally used for DSA signature algorithms. The code to recognize this filename could optionally be disabled since OpenSSH 9.7p1 (2024-03-11) via openssh/openssh-portable@4e83812. It was removed by default since OpenSSH 9.8p1 (2024-07-01), and will be completely removed "early 2025".

Key files eventually expire and are presumably specific to a specific OpenID Provider, so if you are logging into two different servers using different policies, the file will be continously overwritten by two competing opkssh login invocations.

Potential solutions:

• Rely on the IdentityFile OpenSSH client option in ~/.ssh/config to configure a custom location of the file. Users can also use ssh -i /path/to/private-key to pass an extra key. While you could set the option in /etc/ssh/ssh_config or /etc/ssh/ssh_config.d/*.conf (Debian (2020), Arch Linux (2023), etc.), that file is only in use when ~/.ssh/config does not exist. So you might have to patch ~/.ssh/config too.
• Add private keys to an SSH agent. Advantages:
  • SSH agent forwarding (ssh -A) makes it possible to SSH to a trusted server, and continue authenticating to other SSH servers. Useful if you trust the first server and want to use Git over SSH for example.
  • No private key material is written to the filesystem, so there is nothing to clean up.
  • An expiry time ensures that stale keys are automatically removed from the agent. See ssh-add -t 86400
  • Applications using libssh (like Wireshark's sshdump) can also use the agent.
  • Sandboxed applications using Flatpak can also use SSH agent forwarding without exposing all of their private key files in ~/.ssh/ to an application."

originally reported here:

openpubkey/openpubkey#275