Keychain on Wayland

[ldpercy]

FYI if anyone needs it:

Keychain recently stopped working for me on a KDE Neon machine that's just been updated to plasma6+wayland.

Previously I'd been using something like this in my .bashrc:

eval 'keychain --agents ssh --eval ~/.ssh/authentication-key ~/.ssh/signing-key'

That works fine on x11, but after a bit of trial and error I found I needed to change the inherit behaviour - this works for wayland sessions:

eval 'keychain --inherit any-once --agents ssh --eval ~/.ssh/authentication-key ~/.ssh/signing-key'

I'm not too clear on ssh forwarding so if anyone can explain I'd appreciate it.

Cheers

[nekromoff]

This does not seem to work for me on KDE Neon+Wayland. GUI apps always ask for a password, while ssh works in terminal seamlessly.

[ldpercy]

Hi, sorry should have updated.

The fix above did work for me initially while Neon was still based on 22.04 LTS.
But it broke again after the 24.04 rebase and I've been trying to fix it ever since.

Interestingly the original bashrc line continued working on a Kubuntu machine for a while longer, but then also broke with the 24.10 upgrade.

I'm mainly using it for VSCodium & Github if that helps give context.

I tried the source fix mentioned in keychain/issues/141 and with that I can get one VSCodium window to work normally, but any others force me me to type in my passphrase (for those I use the terminal).

[danielrobbins]

Hey @ldpercy -- thanks for the bug report. Please give keychain-2.9.0_beta3 a try. I have overhauled the code significantly, and the --inherit option has been deprecated. I have also fully documented the algorithm that keychain uses internally to find and/or launch an agent, and you should also find the script much easier to understand if you study it. On top of that, I have a new --debug option which will display internal logic related to keychain decision-making regarding what agent is being used.

Let me know if the new keychain gives you better results, and if it still fails, if the new additions allow you to determine the root cause of the issue. Thanks.

[ldpercy]

Hi, thanks for looking at this.
I've started testing this by using aliases in my .bashrc to point to different script versions - hope this is sufficient.

I've just tried beta3, beta4 and latest head (e837b3d) from github.
They all initially report something like:

* keychain ##VERSION## ~ http://www.funtoo.org/Funtoo:Keychain
debug> Ignoring SSH_AUTH_SOCK -- this is the GnuPG-supplied socket
 * Starting ssh-agent...
SSH_AUTH_SOCK=/tmp/ssh-Mbaoy69Iv7fm/agent.2725; export SSH_AUTH_SOCK;
SSH_AGENT_PID=2726; export SSH_AGENT_PID;

 * Adding 3 ssh key(s): /home/ldpercy/.ssh/signing-key
/home/ldpercy/.ssh/authentication-key-1
/home/ldpercy/.ssh/authentication-key-2
 * ssh-add: Identities added: /home/ldpercy/.ssh/signing-key
/home/ldpercy/.ssh/authentication-key-1
/home/ldpercy/.ssh/authentication-key-2

But then running a git fetch re-asks for my passphrase, so something isn't working right.
Can you give some pointers as to what I should be looking for?

[danielrobbins]

Thanks to the new debug output, I can see that SSH_AUTH_SOCK in your environment is pointing to gpg-agent, which was likely spawned earlier by your desktop environment, and its SSH_AUTH_SOCK was injected into your environment, so you need to find a better place to call "eval $(keychain --eval ..)" so that when your shell starts, SSH_AUTH_SOCK is pointing to the ssh-agent that was spawned by keychain, and to which your cached keys were added by keychain. Alternatively, you can source the pidfile ~/.keychain/localhost-sh which contains this information, if it is getting wiped.

You could also potentially play with the new --ssh-use-gpg which will allow keychain find and use the existing gpg-agent, and populate it with your SSH keys. But I would consider this side-stepping the problem which should be solvable based on the information you provided.

[nekromoff]

My setup is this (env):

SSH_AUTH_SOCK=/tmp/ssh-dyq0H1tXU7hW/agent.4543
SSH_ASKPASS=/usr/bin/ksshaskpass
SSH_ASKPASS_REQUIRE=prefer
GSM_SKIP_SSH_AGENT_WORKAROUND=true

I am still getting either immediate rejection or asking for passwords in GUI. Everthing works in CLI.

[danielrobbins]

@nekromoff if it is working in CLI, this means from a keychain perspective, it is working. There is likely something that needs to be found related to the way Wayland or your DE starts up, so that environment variables can be set and inherited into your session. There should be documentation on this somewhere which you can find. I do not use Wayland so I cannot help you there at the moment.

[nekromoff]

Sure, likely yes, but I am unable to pinpoint it as it used to work on my previous system and it doesn't now (and the setup looks the same). Thanks for your support.

[danielrobbins]

@nekromoff some things to try, which maybe you didn't due to gaps in our current documentation:

In ~/.bash_profile, call "eval "$(keychain --eval ..)"" as previously, but use the --systemd option. This may inject the settings for keychain into the systemd user session, which could allow them to persist when Wayland starts.

Play with using ~/.bashrc instead of ~/.bash_profile and see if that produces better results.

[danielrobbins]

There is also another option, @nekromoff -- though this is side-stepping the problem, but could be considered acceptable.

Keychain 2.9.0_beta4 supports the --ssh-allow-gpg option, which will tell keychain to use gpg-agent instead of ssh-agent for storing SSH keys, and --ssh-spawn-gpg, which implies the former, which will even have keychain spawn a gpg-agent for this purpose if one is not already running.

The idea is this -- try to use the existing gpg-agent, or try to have keychain spawn the gpg-agent first. gpg-agent is set up to only one have one daemon running per user, so it's more likely that your desktop environment will "inherit" a gpg-agent started by keychain.

This feature is new, and somewhat experimental, but I thought you might find it useful so worth mentioning.

[ldpercy]

Out of curiosity I fired up a Kubuntu 22.04 vm to have a look, and it seems to use ssh-agent by default.
So it was changed over to gpg-agent around the Wayland changeover, but the reasons are beyond my pay grade.