I came across this question at the same time as this similar question on Ask Ubuntu, and the fix I posted there may be applicable here, as well. (I got the answer from here.)
The main thing is that this fix is only applicable if you are using Seahorse, AKA Passwords and Keys, the GUI frontend for GNOME Keyring. Seahorse is enabled by default on Ubuntu, among other Linux distros. If you're using Seahorse, you can call the command-line executable ssh-askpass
, which will prompt you for the passphrase for a given SSH key and then save that passphrase in GNOME Keyring. (There is a similar process for macOS, which I will describe below the process for Seahorse.)
EDIT: it seems like maybe the more important thing was going into the Seahorse GUI, clicking OpenSSH Keys, right-clicking on the key in question, selecting "Configure Key for Secure Shell...", and adding each of the servers and usernames to use the key with. I had done this earlier today (before running ssh-askpass
) but completely forgotten. Strangely, this part of the process doesn't seem to prompt for a password.
To save the passphrase for an SSH key in Seahorse, use the following command:
$ <seahorse_ssh-askpass> <key_path>
You want to make sure you use the ssh-askpass
associated with Seahorse, and it might not be in the same place on every system, but in my case (Ubuntu 20.10) it was the following:
$ /usr/libexec/seahorse/ssh-askpass <key_path>
If this executable location doesn't work on your system, you can try the following:
$ locate ssh-askpass | grep seahorse
Which will list all files and directories containing ssh-askpass
in the name and seahorse
in the path. (You may need to install and set up mlocate
on your system before you can run this command.)
The most common path for an SSH key is ~/.ssh/id_rsa
, but you can check in the Seahorse GUI to see if it's something else. In my case, I used the following command:
$ /usr/libexec/seahorse/ssh-askpass ~/.ssh/alpha_rsa
If you execute the command successfully, it will pop up a dialogue box listing the name of the SSH key and asking for your password. In my case I got a Vala error saying it couldn't grab the keyboard, and the password I entered got printed to the terminal, but this command seems to have succeeded in making that particular SSH key unlock automatically when my GNOME Keyring is unlocked.
As an aside, if you don't want this to be a glaring security hole,
it's worth making sure that your GNOME Keyring doesn't automatically
unlock without a passphrase when you turn on your computer. In my
case, I have a YubiKey with a passphrase that I have to enter before
Linux can even boot. You will also want to make sure that your
computer locks automatically when you're not using it. But assuming
you have to enter a passphrase to boot up or log in and to unlock your
computer (i.e. wake it from sleep), any SSH passphrase saved in your
GNOME Keyring should be as secure as anything else in your GNOME
Keyring.
If you are on macOS, you can use a similar process to save SSH-key passphrases in the macOS Keychain, which is encrypted with a user's login password.
Assuming you already have your SSH keys set up in ~/.ssh
, you can edit the SSH config
file by entering the following into Terminal:
% nano ~/.ssh/config
At the top of the file, paste the following:
Host *
AddKeysToAgent yes
UseKeychain yes
There is a lot more you can do with the SSH config
file, but I got this particular configuration from this blog post by Derik Ramirez. (Note that while AddKeysToAgent
is applicable to platforms other than macOS, UseKeyChain
is not.)
Type control-o to save your SSH config
, then type control-x to exit nano
and return to the shell prompt. You should be able to use your new SSH config
immediately, and the next time you enter an SSH-key passphrase, it should save to your Login keychain (so you won't have to enter it again after that).
ssh-agent
and have the passphrase cached over multiple logins. That would still have the benefit of keeping the key encrypted on-disk. To have the passphrase cached over reboots, would require saving it on disk, and then you might as well keep the key unencrypted (like terdon said).