After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 794368 - existing SSH passwords are not properly migrated
existing SSH passwords are not properly migrated
Status: RESOLVED FIXED
Product: gnome-keyring
Classification: Core
Component: ssh-agent
3.28.x
Other Linux
: Normal normal
: ---
Assigned To: GNOME keyring maintainer(s)
GNOME keyring maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2018-03-15 17:59 UTC by Michael Biebl
Modified: 2018-03-20 09:04 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
login: supply default secret schema to GkdLoginInteraction (3.69 KB, patch)
2018-03-16 15:45 UTC, Daiki Ueno
none Details | Review
ssh-agent: Don't supply xdg:schema to GkdLoginInteraction (927 bytes, patch)
2018-03-16 15:45 UTC, Daiki Ueno
none Details | Review
login: Allow different sets of secret attributes for lookup/storing (3.24 KB, patch)
2018-03-19 11:00 UTC, Daiki Ueno
committed Details | Review
ssh-agent: Use the same parameters for accessing login keyring (1.64 KB, patch)
2018-03-19 11:01 UTC, Daiki Ueno
committed Details | Review

Description Michael Biebl 2018-03-15 17:59:01 UTC
Version: 3.28.0

I've setup gnome-keyring to store the password of my SSH keys in the keyring and to unlock them automatically on login.

After the update from 3.26 to 3.28 this did no longer work, and I got a password prompt when I tried to use SSH.
I entered the password and check the box to unlock the key automatically. Unfortunately, after the next login, I had to re-enter the password again.
Only after deleting the existing passwords from gnome-keyring (using seahorse), and then storing the passwords anew, the automatic unlock worked.

I noticed, that the old passwords were stored as "Encryption key password", after deleting them and storing them again, the type as shown in seahorse is "Password or secret".

Maybe that is the reason why the existing passwords no longer worked with gnome-keyring 3.28?
Comment 1 Daiki Ueno 2018-03-16 14:02:45 UTC
(In reply to Michael Biebl from comment #0)

> I noticed, that the old passwords were stored as "Encryption key password",
> after deleting them and storing them again, the type as shown in seahorse is
> "Password or secret".

That means the old passwords are stored using the "org.gnome.keyring.EncryptionKey" schema, while the new passwords are stored using the "org.freedesktop.Secret.Generic".

However, interestingly, if I store a password with gnome-keying 3.20.1, it is stored using the latter schema:

$ secret-tool search --all xdg:schema org.freedesktop.Secret.Generic
[/org/freedesktop/secrets/collection/login/37]
label = Unlock password for: ...
secret = ...
created = 2018-03-16 13:51:15
modified = 2018-03-16 13:51:15
schema = org.freedesktop.Secret.Generic
attribute.unique = ssh-store:/home/dueno/.ssh/id_rsa
...

Perhaps the schema was changed in old days?
Would you be able to figure out the actual differences with secret-tool?
(Do not forget to scratch the "secret" field if you paste the result)
Comment 2 Daiki Ueno 2018-03-16 15:45:25 UTC
Created attachment 369790 [details] [review]
login: supply default secret schema to GkdLoginInteraction

This is to provide backward compatibility on the stored data, with
gnome-keyring 2.29 or earlier.  In that old versions, gnome-keyring
used "org.gnome.keyring.EncryptionKey" as schema, while it uses
"org.freedesktop.Secret.Generic".

To tolerate this difference, GkdLoginInteraction now uses two
different sets of attributes for lookup and storing.  The former may
not contain any schema set, and in that case, the latter is amended
with "org.freedesktop.Secret.Generic".
Comment 3 Daiki Ueno 2018-03-16 15:45:31 UTC
Created attachment 369791 [details] [review]
ssh-agent: Don't supply xdg:schema to GkdLoginInteraction
Comment 4 Michael Biebl 2018-03-16 15:53:14 UTC
This Debian installation dates back many years. I don't remember anymore when I initially created the keyring, but it very well might have been in the GNOME 2.x days.

Since the initial creation of the keyring, I added new SSH passwords, which are most likely post 2.29.

So far, those old keys didn't pose any problems and worked flawlessly.
I'm curious what changed in 3.28?
Comment 5 Michael Biebl 2018-03-17 16:49:10 UTC
I double checked and ran 
secret-tool search --all xdg:schema org.gnome.keyring.EncryptionKey
using the old keyring. Looking at the dates, those keys might indeed have been created using GNOME <= 2.29

[/org/freedesktop/secrets/collection/login/76]
label =
secret =
created = 2010-02-04 08:25:59
modified = 2010-02-04 08:25:59
schema = org.gnome.keyring.EncryptionKey
attribute.unique = ssh-store:/home/michael/.ssh/id_rsa.6
[/org/freedesktop/secrets/collection/login/57]
label =
secret =
created = 2009-04-13 13:04:43
modified = 2009-04-13 13:04:43
schema = org.gnome.keyring.EncryptionKey
attribute.unique = ssh-store:/home/michael/.ssh/id_rsa.0
[/org/freedesktop/secrets/collection/login/56]
label =
secret =
created = 2009-04-04 20:23:29
modified = 2009-04-04 20:23:29
schema = org.gnome.keyring.EncryptionKey
attribute.unique = ssh-store:/home/michael/.ssh/id_rsa.4
[/org/freedesktop/secrets/collection/login/55]
label =
secret =
created = 2009-04-03 14:46:42
modified = 2009-04-03 14:46:42
schema = org.gnome.keyring.EncryptionKey
attribute.unique = ssh-store:/home/michael/.ssh/id_rsa.3
[/org/freedesktop/secrets/collection/login/54]
label =
secret =
created = 2009-04-02 04:33:05
modified = 2009-04-02 04:33:05
schema = org.gnome.keyring.EncryptionKey
attribute.unique = ssh-store:/home/michael/.ssh/id_rsa
[/org/freedesktop/secrets/collection/login/53]
label =
secret =
created = 2009-04-02 04:22:45
modified = 2009-04-02 04:22:45
schema = org.gnome.keyring.EncryptionKey
attribute.unique = ssh-store:/home/michael/.ssh/id_rsa.1
[/org/freedesktop/secrets/collection/login/52]
label =
secret =
created = 2009-04-02 04:11:19
modified = 2009-04-02 04:11:19
schema = org.gnome.keyring.EncryptionKey
attribute.unique = ssh-store:/home/michael/.ssh/id_rsa.2
[/org/freedesktop/secrets/collection/login/32]
label =
secret =
created = 2008-08-28 07:22:18
modified = 2008-08-28 07:22:18
schema = org.gnome.keyring.EncryptionKey
attribute.pk-object = LOCAL:/keystore/id_rsa.4
[/org/freedesktop/secrets/collection/login/19]
label =
secret =
created = 2008-05-20 12:20:33
modified = 2008-05-20 12:20:33
schema = org.gnome.keyring.EncryptionKey
attribute.pk-object = HOME:/.ssh/id_rsa
[/org/freedesktop/secrets/collection/login/18]
label =
secret =
created = 2008-05-20 12:20:15
modified = 2008-05-20 12:20:15
schema = org.gnome.keyring.EncryptionKey
attribute.pk-object = LOCAL:/keystore/id_rsa.1
[/org/freedesktop/secrets/collection/login/17]
label =
secret =
created = 2008-05-20 12:05:20
modified = 2008-05-20 12:05:20
schema = org.gnome.keyring.EncryptionKey
attribute.pk-object = LOCAL:/keystore/id_rsa.3
[/org/freedesktop/secrets/collection/login/16]
label =
secret =
created = 2008-05-20 12:02:59
modified = 2008-05-20 12:02:59
schema = org.gnome.keyring.EncryptionKey
attribute.pk-object = LOCAL:/keystore/id_rsa.2
Comment 6 Michael Biebl 2018-03-17 16:59:57 UTC
I can confirm, that with those patches applied, my old keys work properly again.
Comment 7 Daiki Ueno 2018-03-19 11:00:15 UTC
Thank you for confirming.  I will land a slightly modified version.

(In reply to Michael Biebl from comment #4)

> I'm curious what changed in 3.28?

Basically, it's a regression after bug 775981, where we replaced our own ssh-agent implementation by delegating it to OpenSSH's ssh-agent.  That makes it no longer possible to utilize the login keyring access provided by the PKCS#11 layer.
Comment 8 Daiki Ueno 2018-03-19 11:00:48 UTC
Created attachment 369861 [details] [review]
login: Allow different sets of secret attributes for lookup/storing
Comment 9 Daiki Ueno 2018-03-19 11:01:02 UTC
Created attachment 369862 [details] [review]
ssh-agent: Use the same parameters for accessing login keyring

When looking up a secret in the login keyring, do not supply any
schema in the criteria, while using "org.freedesktop.Secret.Generic"
as schema when storing it.  This is for backward compatibility with
gnome-keyring 2.29, which used "org.gnome.keyring.EncryptionKey" as
schema.

In addtion, use the same label for the newly stored passwords as
before.
Comment 10 Daiki Ueno 2018-03-19 11:01:39 UTC
Attachment 369861 [details] pushed as 0a003f0 - login: Allow different sets of secret attributes for lookup/storing
Attachment 369862 [details] pushed as 869b5c6 - ssh-agent: Use the same parameters for accessing login keyring
Comment 11 Michael Biebl 2018-03-19 15:52:45 UTC
Thanks a lot! Everything works again smoothly for me now.

Will those patches also be pulled into the gnome-3-28 branch?
Comment 12 Daiki Ueno 2018-03-20 09:04:45 UTC
Yes, I merged them to the gnome-3-28 branch.  I will make a bug-fix release later in this week.