12

Since I updated to Ubuntu 17.10 a while ago, my private keys – the which I use for example to access my server via ssh – are not unlocked programmatically after login anymore.

enter image description here

My understanding is, that usually the seahorse client should take care of this, by asking you whether or not to store the key's password when typing them in for the first time.

My first guess was, that seahorse-daemon wasn't running for some reason, but it is:

user@Zeus:~$ ps aux | grep seahorse
user    19170  0.0  0.1 432636 26564 ?        Ss   00:07   0:00 seahorse-daemon

My second guess was, that for some reason I have to delete all related passwords stored in seahorse under »Passwords->login«: enter image description here

I was hoping to force the client to ask me again and then storing them again. But this didn't help either. The client does not pop up to ask me...

Then I found this question, which could be related, but did not help me: Unlock all private keys on Ubuntu, entering password only once at login

As the management of other passwords work as expected (for example passwords for nautilus, Chromium, Nextcloud etc.) I assume the problem has to do something with ssh-agent...

Can anybody hint me in the right directions, how to solve this problem? Has anything changed in the way how GNOME handles passwords? Maybe some new fancy program failed being installed during the upgrade process?

UPDATE When I add the private key to the authentication agent again with:

ssh-add ~/.ssh/id_rsa

and try to log in, I will be asked to unlock the key only once, after that the key gets unlocked programmatically. But this works only until the next reboot. After a fresh start, I have to add the key again...

  • I also all of a sudden started being asked for a password to unlock ssh keys while using Ubuntu 17.10. The accepted answer didn't help me (works only until reboot). Here is an apparently duplicate question. – Alexey Mar 28 '18 at 13:02
  • Seahorse encrypts its data with, you guessed it, your password (typically). Password-less logins, like ssh with a key, fingerprint reader,... leave the decryption until needed, then you are asked. Did you switch ssh logins from password to key when the problem started? – ubfan1 Dec 7 '18 at 16:45
7

Yes, ssh-agent is the answer. To save the passphrase, all you have to do is:

ssh-add ~/.ssh/id_rsa

Then put in your password, and log back in.

  • This helps only until next reboot. – Alexey Mar 28 '18 at 12:45
  • @Alexey Yes, I can confirm that it works only till the next reboot. Didn't find a solution yet. – user5950 Mar 28 '18 at 23:20
  • ssh-agent runs during a login session and terminates when you end it for your own security. If it was persistent across reboots and your account password gets compromised, suddenly an attacker has access to your RSA identity and hence every machine you can access. This would be a nasty security hole. There are, however, some workarounds, at the cost of making your account less secure. See unix.stackexchange.com/questions/90853/… – darksky Apr 3 '18 at 5:26
6

Adding SSH Key Agent (GNOME Keyring: SSH Agent) to Startup Applications solved the problem for me:

enter image description here

3

First Option

Start ssh agent :

ssh-agent

Add the ssh-key :

ssh-add ~/.ssh/id_rsa

To make it persist after reboot, auto start ssh-agent, add the following line to your .bash_profile :

if [ -z "$SSH_AUTH_SOCK" ] ; then
  eval `ssh-agent -s`
  ssh-add
fi

Second Option

Add this to your .bashrc or .zshrc :

if [ ! -S ~/.ssh/ssh_auth_sock ]; then
  eval `ssh-agent`
  ln -sf "$SSH_AUTH_SOCK" ~/.ssh/ssh_auth_sock
fi
export SSH_AUTH_SOCK=~/.ssh/ssh_auth_sock
ssh-add -l > /dev/null || ssh-add

This should only prompt for a password the first time you login after each reboot. It will keep reusing the same ssh-agent as long as it stays running.

  • Thanks, this workaround looks as if it works, but I am wandering, what happened to make it stop working in the first place? It used to work for the last decade... I would like to find the cause before I go for a workaround... – user5950 Apr 12 '18 at 21:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.