GNOME Bugzilla – Bug 794631
Spinning CPU when interacting with the ssh client when the password stored in login keyring is incorrect
Last modified: 2018-03-25 08:07:12 UTC
I'm running 3.28.0.1 from the Bionic package, which is the 3-28 branch up to b70a10e0953a7e0a13ca3705677aa974451e2fa1 basically. When I ssh to my server, gnome-keyring-daemon starts spinning the CPU. ssh -vvv shows that this is the last thing to happen: debug1: Offering public key: ECDSA SHA256:qd0wr4suhPRpZYZMy/9EPorDVrzW8Ww6sZJaJME+G80 /home/laney/.ssh/id_ecdsa debug3: send_pubkey_test debug3: send packet: type 50 debug2: we sent a publickey packet, wait for reply debug3: receive packet: type 60 debug1: Server accepts key: pkalg ecdsa-sha2-nistp521 blen 172 debug2: input_userauth_pk_ok: fp SHA256:qd0wr4suhPRpZYZMy/9EPorDVrzW8Ww6sZJaJME+G80 debug3: sign_and_send_pubkey: ECDSA SHA256:qd0wr4suhPRpZYZMy/9EPorDVrzW8Ww6sZJaJME+G80 Here's a backtrace of what's going on at the time: (gdb) t a a bt
+ Trace 238503
Thread 8 (Thread 0x7fcca8ff9700 (LWP 14913))
Thread 7 (Thread 0x7fcca97fa700 (LWP 14851))
Thread 6 (Thread 0x7fccaa7fc700 (LWP 7884))
Thread 5 (Thread 0x7fccaaffd700 (LWP 7761))
and in pstree I can see |-gnome-keyring-d --daemonize --login | |-ssh-add /home/laney/.ssh/id_ecdsa | | `-gcr-ssh-askpass Bad passphrase, try again for /home/laney/.ssh/id_ecdsa: | |-ssh-add /home/laney/.ssh/id_ecdsa | | `-gcr-ssh-askpass Bad passphrase, try again for /home/laney/.ssh/id_ecdsa: | |-ssh-agent -D -a /run/user/1000/keyring/.ssh so I'm guessing that *somehow* we got a bad password stored. I'll go away and delete the keys from seahorse now and see what happens.
Yes, it works after deleting the keys and then re-adding.
Do you happen to have any additional clue in the journal (journalctr -r)?
Also I would like to clarify how you interacted with gnome-keyring: - Did you previously save the password for the key in question, by checking the "Automatically unlock ..." checkbox? If so, do you remember which version of gnome-keyring you used at that time? - Now, when you saw the issue, did you also see the prompt shown on your screen?
(In reply to Daiki Ueno from comment #2) > Do you happen to have any additional clue in the journal (journalctr -r)? I can't see anything interesting (journalctl -b-1 | grep keyring), except maybe Mar 23 17:31:51 nightingale gnome-keyring-daemon[3515]: couldn't allocate secure memory to keep passwords and or keys from being written to the disk Mar 23 17:31:51 nightingale gnome-keyring-daemon[3515]: asked to register item /org/freedesktop/secrets/collection/login/25, but it's already registered Mar 23 17:50:30 nightingale goa-daemon[3689]: /org/gnome/OnlineAccounts/Accounts/account_1497963525_0: Setting AttentionNeeded to TRUE because EnsureCredentials() failed with: Failed to retrieve credentials from the keyring (goa-error-quark, 4) ? (In reply to Daiki Ueno from comment #3) > Also I would like to clarify how you interacted with gnome-keyring: > - Did you previously save the password for the key in question, by checking > the "Automatically unlock ..." checkbox? If so, do you remember which > version of gnome-keyring you used at that time? Yes, I did. I had a bug (fixed in the gnome-3-28 commits?) where, when I upgraded to 3.27.4, my previous keys from gnome-keyring prior to the recent SSH reworking weren't unlocked. I deleted those from seahorse and then asked gnome-keyring to save them. Then when I got 3.28 - both with and without the changes from the gnome-3-28 branch (I tried both) - I experienced this bug. > - Now, when you saw the issue, did you also see the prompt shown on your > screen? No, no prompt at all. The SSH attempt hung, and I noticed that g-k-d was using all of one core.
(In reply to Iain Lane from comment #4) > (In reply to Daiki Ueno from comment #2) > > Do you happen to have any additional clue in the journal (journalctr -r)? > > I can't see anything interesting (journalctl -b-1 | grep keyring), except > maybe > > Mar 23 17:31:51 nightingale gnome-keyring-daemon[3515]: couldn't allocate > secure memory to keep passwords and or keys from being written to the disk This looks strange, but explains that it retrieves a garbage as a password. Nevertheless, it is a bug that gnome-keyring doesn't give up and prompt user if a wrong password is stored in the login keyring. I will attach a patch.
Created attachment 370088 [details] [review] login: Use password from login keyring once for the same interaction
Attachment 370088 [details] pushed as a0526d1 - login: Use password from login keyring once for the same interaction