2 min read

keychain issues after distro upgrade — workaround

keychain issues after distro upgrade — workaround
Photo by Towfiqu barbhuiya / Unsplash

Lately I decided to upgrade my Ubuntu distro in WSL under Windows 11 from 20.04 to 24.04. The operation itself wasn't that long and I had very little issues with it, just the occasional need for a restart and decision which config file to use moving forward.

Unfortunately this upgrade (or something that happened in the meantime) left keychain in a broken state. Almost every attempt to add SSH key was failing. Almost — because passwordless keys were fine. I can recall reading somewhere that ssh-add was opening a direct tty for password input, so perhaps something happened with that, but it's only my wild guess.

Picture depicts a screenshot from a Linux command line interface showing the problem.
This is how the issue displayed.

Starting keychain without adding any SSH keys or only with passwordless ones worked fine, but as soon as there was a key secured with a password it rejected to work, even if it was already running. On the other hand ssh-add could use any SSH key just fine, and keychain could make use of it.

Looking into journalctl gave me no clues on what is going on wrong. Paths to SSH keys were correct, file access rights were also fine. I have tried reinstalling, uninstalling then installing of keychain, restarting it, and other solutions I have found on the Internet, but to no avail.

Knowing what was working though, I decided to craft myself a workaround for the issue — not the most elegant one, but it's working, and that's what matters at the end of the day. So I ended up removing an old call to keychain from .profile file:

eval `keychain --eval <LIST_OF_KEYS>`

I replaced it with a call to start keychain with a check if it has all my SSH keys. If not all SSH keys are loaded, then I call ssh-add with all my keys. The result looks like that:

eval `keychain --eval`
[ `keychain -l 2> /dev/null | wc -l` -lt <NUMBER_OF_SSH_KEYS> ] && ssh-add <LIST_OF_KEYS>

If you prefer, you can as well use -lt <NUMBER_OF_SSH_KEYS> with -eq 0 to get similar results, but checking if there are any keys added.