MX Linux Forum

Posted: **Wed Sep 12, 2018 4:45 pm**

Gnome-keyring - unlocked
Enable secure password store with gnome-keyring to avoid keyring prompt

Gnome-keyring’s default password-stores used by different apps like Chrome/Chromium and other can be setup in such a way that they automatically get unlocked during session login.
Within MX Linux we are already prepared to enable and use this auto-unlock feature provided by the Pluggable Authentication Modules (PAM) mechanism:
After the user enters the login password the pam-library will unlock the login-keyring managed by the gnome-keyring subprocess. To turn PAM on we have only to install the package libpam-gnome-keyring. Use either MX Package Installer, Synaptic or the CLI to install the package:

Code: Select all

sudo apt-get install libpam-gnome-keyring

After logout and login do open „Password and Keys“ to verify that the newly created Login-keyring is automatically unlocked.

Only one keyring : Login keyring
If no other password-store keyring is already in use the Login-keyring will also become the default password-store keyring.
Right click with the Login-keyring to verify / set it to default password store.

1_kr-login-empty.png

When you open an application which requires to save/fetch it’s credential into/from the default password-store keying the keyring to store passwords will be used.
E.g. open Chromium and you‘ll see that Chromiums internal encryption keys get stored within the default (login) keyring:

2_kr-login-default.png

Default keyring already exists
If you already have a password-store “Default keyring” in use by chromium, which holds your passwords and chromiums internal encryption keys you can secure this keyring with a password and automatically unlock the keyring on application request by means of the PAM-Login-keyring mechanism.

To secure and enable auto-unlock of existing “Default keyring” used by chromium (or any other app):
- close Chromium
- open „Password and Keys“
- right click on your existing password store “Default keyring” → set default
- right click on “Default keyring” to verify or change existing password
Now the trick:
- right click on you existing “Default keyring” password store → Lock
And now - this is important:
- right click again on your existing “Default keyring” password store → Unlock
→ Click on “Automatically unlock this keyring whenever I’m logged in”
and enter the password of your “Default keyring”.

Logout, login and to verfiy with „Password and Keys“ that you login-keyring is unlocked
and you “Default keyring” is still locked.

3-kr-log-def-locked.png

Now open chromium and verify that the “Default keyring”
used by chromum get’s automaticaly unlocked.

4-ld-unlocked.png

Attched the above as PDF-file.

--fehlix
on behalf of MX Linux community

Posted: **Wed Sep 12, 2018 5:58 pm**

Thanks for your guide, fehlix.
This is something I don't understand. In Ubuntu 14.04 (still supported) gnome-keyring is installed. I have never been asked to create a password.

Not by:
Networkmanager
Evolution
Skype
Chrome
or any other application.

gnome-keyring is wonderfully unintrusive in Ubuntu. It is running in taskmanager (sleeping). It is marked in start-up manger with this command:
/usr/bin/gnome-keyring-daemon --start --components=secrets

EDIT: I found one more start-up entry/command:
/usr/bin/gnome-keyring-daemon --start --components=gpg

Why is gnome-keyring so silent in Ubuntu and so intrusive in MX Linux?

Posted: **Wed Sep 12, 2018 6:10 pm**

Don't know. But Chromium changed recently something forcing user to use gnome-keyring mainly to store their internal encrpytion key, which are used to "secure" all "sensible" collected (user-)data (aka cookies and DOM-cookies), even if you dont save any passwords.

Posted: **Wed Sep 12, 2018 6:22 pm**

fehlix wrote: Wed Sep 12, 2018 6:10 pm Don't know. But Chromium changed recently something forcing user to use gnome-keyring mainly to store their internal encrpytion key, which are used to "secure" all "sensible" collected (user-)data (aka cookies and DOM-cookies), even if you dont save any passwords.

Weird. What does Chromium use on Windows? Also, do the Antix guys ship gnome-keyring?
The Password and Keys application is dangerous. It shows my Hotmail password in plain text and I don't even need root to launch it.

Posted: **Wed Sep 12, 2018 6:26 pm**

dreamer wrote: Wed Sep 12, 2018 5:58 pm /usr/bin/gnome-keyring-daemon --start --components=secrets
EDIT: I found one more start-up entry/command:
/usr/bin/gnome-keyring-daemon --start --components=gpg

It's not started in MX Linux, as it was never used intensively as elsewhere.
With PAM enabled, it will make sure you don't have to reenter passwords to unlock.
The components=gpg is usefull, if you intent to use gpg signing and encryption e.g. with
Thunderbird or other emailers.
So I assume in other Linux OS's, the usage might by more intensive.
You migh check with Seahorse (= "Passwords and Keys") to see what they do save with gnome-keyring.

Posted: **Wed Sep 12, 2018 6:27 pm**

dreamer wrote: Wed Sep 12, 2018 6:22 pm
fehlix wrote: Wed Sep 12, 2018 6:10 pm Don't know. But Chromium changed recently something forcing user to use gnome-keyring mainly to store their internal encrpytion key, which are used to "secure" all "sensible" collected (user-)data (aka cookies and DOM-cookies), even if you dont save any passwords.
Weird. What does Chromium use on Windows? Also, do the Antix guys ship gnome-keyring?
The Password and Keys application is dangerous. It shows my Hotmail password in plain text and I don't even need root to launch it.

Well, if you setup to store passwords automatically, it's your decision!

Posted: **Wed Sep 12, 2018 6:33 pm**

dreamer wrote: Wed Sep 12, 2018 6:22 pm Weird. What does Chromium use on Windows? Also, do the Antix guys ship gnome-keyring?

If you user Chromium, recent version force you to store the internal encryption keys, other wise you might get functional issues. Chromium offers three options to use as password-store "kwallet", "gnome-keyring" or "basic" ="plaintext".
I.e. if you dont have kwallet or gnome-keyring, Chromim would save it's internal encrypotion key and any passwords, in a "cleartext" level

Posted: **Wed Sep 12, 2018 6:41 pm**

dreamer wrote: Wed Sep 12, 2018 5:58 pm Thanks for your guide, fehlix.
This is something I don't understand. In Ubuntu 14.04 (still supported) gnome-keyring is installed. I have never been asked to create a password.

Not by:
Networkmanager
Evolution
Skype
Chrome
or any other application.

Opera on Ubuntu 14.04 will prompt you to set up your gnome-keyring. And it will ask you to unlock that keyring once in the login session in which it is started.
Now, I don't know if that's just a bug in Opera, or if it is one of the few apps using the keyring as it was intended. Lol. <shrug> It's anyone's guess.

Posted: **Wed Sep 12, 2018 6:55 pm**

clicktician wrote: Wed Sep 12, 2018 6:41 pm Opera on Ubuntu 14.04 will prompt you to set up your gnome-keyring. And it will ask you to unlock that keyring once in the login session in which it is started.
Now, I don't know if that's just a bug in Opera, or if it is one of the few apps using the keyring as it was intended. Lol. <shrug> It's anyone's guess.

With the described auto-unlock PAM technique above, you can have opera's keyring to auto-unlock with help of the Login-keyring. It's the identical precedure as described for chromium above.

Posted: **Wed Sep 12, 2018 7:15 pm**

fehlix wrote: Wed Sep 12, 2018 6:33 pm
dreamer wrote: Wed Sep 12, 2018 6:22 pm Weird. What does Chromium use on Windows? Also, do the Antix guys ship gnome-keyring?
If you user Chromium, recent version force you to store the internal encryption keys, other wise you might get functional issues. Chromium offers three options to use as password-store "kwallet", "gnome-keyring" or "basic" ="plaintext".
I.e. if you dont have kwallet or gnome-keyring, Chromim would save it's internal encrypotion key and any passwords, in a "cleartext" level

I just launched latest Chrome on Ubuntu 14.04 and no demand for keyring password. Maybe it's a Chromium thing...
However, I launched Seahorse (Password and Keys) on Ubuntu and there were entries for both Chrome and Evolution so it must have added them by itself. At least it didn't bother the user to come up with a password. No user should have to deal with gnome-keyring, that's just annoying.

With the described auto-unlock PAM technique above, you can have opera's keyring to auto-unlock with help of the Login-keyring. It's the identical precedure as described for chromium above.

That should be standard. We have a login password to protect our accounts. If some applications want to use gnome-keyring let them do it and if the user wants to set a password then Seahorse is a good place to do that. But giving the user a keyring promt at first launch is the wrong way that may scare away users. Ubuntu does it right, you don't have to deal with gnome-keyring if you don't want to. I didn't even know it was there.

The Evolution thing is annoying, storing my Hotmail password in plain text on both Ubuntu and MX Linux. I can't use it if it insists to store my password in plain text. I have an older version of FossaMail set up. It has a launch password (not keyring related) and I have also gone through the account settings. Not anywhere can I find my Hotmail password so FossaMail seems more secure.

Posted: **Wed Sep 12, 2018 7:38 pm**

dreamer wrote: Wed Sep 12, 2018 7:15 pm That should be standard. We have a login password to protect our accounts. If some applications want to use gnome-keyring let them do it ..

Well, we have it now in MX 17 it's tested and works very well, we would need only to turn it on.
I do have some on my wishlist to improve the keyring-feature, but it's a good start to securely save credentials,
I.e. if you are not logged on, there is no good chance to break the keyring. Surely depends a bit on the quality of your log-in password.

Posted: **Wed Sep 12, 2018 8:08 pm**

I have a load of Mint 18 KDE and it exhibits this same behavior (kwallet) with Google Chrome the first time it's launched. I just hit cancel and carry on. Kind of a PITA, but not a big deal.

Posted: **Wed Sep 12, 2018 9:03 pm**

fehlix wrote: Wed Sep 12, 2018 4:45 pm Gnome-keyring - unlocked
Enable secure password store with gnome-keyring to avoid keyring prompt

Gnome-keyring’s default password-stores used by different apps like Chrome/Chromium and other can be setup in such a way that they automatically get unlocked during session login.
Within MX Linux we are already prepared to enable and use this auto-unlock feature provided by the Pluggable Authentication Modules (PAM) mechanism:
After the user enters the login password the pam-library will unlock the login-keyring managed by the gnome-keyring subprocess. To turn PAM on we have only to install the package libpam-gnome-keyring. Use either MX Package Installer, Synaptic or the CLI to install the package:
Code: Select all
sudo apt-get install libpam-gnome-keyring 
After logout and login do open „Password and Keys“ to verify that the newly created Login-keyring is automatically unlocked.

Only one keyring : Login keyring
If no other password-store keyring is already in use the Login-keyring will also become the default password-store keyring.
Right click with the Login-keyring to verify / set it to default password store.
1_kr-login-empty.png
When you open an application which requires to save/fetch it’s credential into/from the default password-store keying the keyring to store passwords will be used.
E.g. open Chromium and you‘ll see that Chromiums internal encryption keys get stored within the default (login) keyring:
2_kr-login-default.png

Default keyring already exists
If you already have a password-store “Default keyring” in use by chromium, which holds your passwords and chromiums internal encryption keys you can secure this keyring with a password and automatically unlock the keyring on application request by means of the PAM-Login-keyring mechanism.

To secure and enable auto-unlock of existing “Default keyring” used by chromium (or any other app):
- close Chromium
- open „Password and Keys“
- right click on your existing password store “Default keyring” → set default
- right click on “Default keyring” to verify or change existing password
Now the trick:
- right click on you existing “Default keyring” password store → Lock
And now - this is important:
- right click again on your existing “Default keyring” password store → Unlock
→ Click on “Automatically unlock this keyring whenever I’m logged in”
and enter the password of your “Default keyring”.

Logout, login and to verfiy with „Password and Keys“ that you login-keyring is unlocked
and you “Default keyring” is still locked.
3-kr-log-def-locked.png
Now open chromium and verify that the “Default keyring”
used by chromum get’s automaticaly unlocked.

4-ld-unlocked.png

Attched the above as PDF-file.

--fehlix
on behalf of MX Linux community

brilliant! worked like a charm thanks.

my abbreviated procedure, since I don't use the gnome-keyring for anything (except apparently chrome...)

1. install libpam-gnome-keyring
2. delete ~/.local/share/keyrings
3. logout and login.

Posted: **Wed Sep 12, 2018 11:54 pm**

uncle mark wrote: Wed Sep 12, 2018 8:08 pm I have a load of Mint 18 KDE and it exhibits this same behavior (kwallet) with Google Chrome the first time it's launched. I just hit cancel and carry on. Kind of a PITA, but not a big deal.

It only pops up once in a while when I use Google Chrome (granted I only use it when a page doesn't open in FF) in my distros. Like Uncle Mark, I just hit cancel.

I find that some updates of Chrome have it, then it seems to be gone for a while, then it will resurface in another update. Because of that, I prefer to hit cancel since this keyring requirement doesn't always turn up.

Posted: **Thu Sep 13, 2018 6:55 am**

Thanks, fehlix--pasted this into the Wiki:

https://mxlinux.org/wiki/system/gnome-keyring

Will edit, including DO's addition

Posted: **Thu Sep 13, 2018 7:15 am**

Jerry3904 wrote: Thu Sep 13, 2018 6:55 am Thanks, fehlix--pasted this into the Wiki:

https://mxlinux.org/wiki/system/gnome-keyring

Will edit, including DO's addition

Thanks.
You might consider to add something like this foot-note somewhere:
~~~~~~
Note:
If you are changing later your login-password, you have not to forget to
to adjust also the password of the Login-keyring using „Password and keys“,
otherwise PAM cannot unlock your login-keyring automatically.
~~~~~

Posted: **Thu Sep 13, 2018 7:34 am**

fehlix wrote: Thu Sep 13, 2018 7:15 am
Jerry3904 wrote: Thu Sep 13, 2018 6:55 am Thanks, fehlix--pasted this into the Wiki:

https://mxlinux.org/wiki/system/gnome-keyring

Will edit, including DO's addition
Thanks.
You might consider to add something like this foot-note somewhere:
~~~~~~
Note:
If you are changing later your login-password, you have not to forget to
to adjust also the password of the Login-keyring using „Password and keys“,
otherwise PAM cannot unlock your login-keyring automatically.
~~~~~

that's a "maybe", but probably likely since our mx-user-manager runs with root permissions by default.

When the user changes their password, the PAM module changes the password of the 'login' keyring to match.
Again, here gnome-keyring-daemon is started if necessary.

If root changes the password, or /etc/shadow is directly edited then due to the lack of the old password, the 'login' keyring cannot be updated.

Posted: **Thu Sep 13, 2018 7:48 am**

dolphin_oracle wrote: Thu Sep 13, 2018 7:34 am
When the user changes their password, the PAM module changes the password of the 'login' keyring to match.

Ohh.., that's new to me. That might have been introduced recently(?) into PAM...

Posted: **Thu Sep 13, 2018 7:49 am**

fehlix wrote: Thu Sep 13, 2018 7:48 am
dolphin_oracle wrote: Thu Sep 13, 2018 7:34 am
When the user changes their password, the PAM module changes the password of the 'login' keyring to match.

Ohh.., that's new to me. That might have been introduced recently(?) into PAM...

hmm...if its new, it may or may not be in debian yet. we better test that.

Posted: **Thu Sep 13, 2018 8:15 am**

dolphin_oracle wrote: Thu Sep 13, 2018 7:49 am hmm...if its new, it may or may not be in debian yet. we better test that.

Cool, PAM changed by login-keyring password automaticaly in MX17.1 64bit
So no need to add this foot-note above to the wiki!
But , we better verify this in MX16/MX15 also.

Code: Select all

feh@mx:~/Desktop
$ passwd
Changing password for feh.
(current) UNIX password: 
Enter new UNIX password: 
Retype new UNIX password: 
Bad: new password is too simple
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully

Posted: **Thu Sep 13, 2018 8:29 am**

I was prepared to lose application info so took the shortcut:

brilliant! worked like a charm thanks.

my abbreviated procedure, since I don't use the gnome-keyring for anything (except apparently chrome...)

1. install libpam-gnome-keyring
2. delete ~/.local/share/keyrings
3. logout and login.

Started Evolution, had to retype Hotmail password, everything else normal.
Started Skype, had to retype Skype password, everything else normal.
Started Chrome, almost never use it but my settings and history seem intact.

So deleting my existing keyrings didn't really affect my applications. And now I don't see keyring prompts anymore so big win!

Thanks fehlix and dolphin_oracle. I think you solved this keyring nonsense for MX users. An anvanced user who for some reason wants a separate keyring password will be able to set that up. 99 of 100 MX users most likely are happier without keyring prompts.

Posted: **Thu Sep 13, 2018 10:18 am**

Thank you for sharing this abbreviated procedure, with only 3 steps.

Posted: **Thu Sep 13, 2018 5:54 pm**

fehlix wrote: Thu Sep 13, 2018 8:15 am
dolphin_oracle wrote: Thu Sep 13, 2018 7:49 am hmm...if its new, it may or may not be in debian yet. we better test that.
Cool, PAM changed by login-keyring password automaticaly in MX17.1 64bit

OK, verified on MX17.1 and MX16.1:
Installation of libpam-gnome-keyring will make password changes of the users Login-password
to have PAM automatically update the password of the Login-keyring also.

Posted: **Thu Sep 13, 2018 6:52 pm**

With the various changes, could people please review the Wiki entry? I have edited and revised it (still needs some more), and want it to be right.

https://mxlinux.org/wiki/system/gnome-keyring

TIA

Posted: **Thu Sep 13, 2018 7:10 pm**

1. install libpam-gnome-keyring
2. delete ~/.local/share/keyrings
3. logout and login.

FWIW, in Mint 18 KDE, renaming to ~/.local/share/keyrings.bak, and logging in/out did it for me.

Posted: **Thu Sep 13, 2018 7:31 pm**

Jerry3904 wrote: Thu Sep 13, 2018 6:52 pm With the various changes, could people please review the Wiki entry? I have edited and revised it (still needs some more), and want it to be right.

https://mxlinux.org/wiki/system/gnome-keyring

TIA

A corrrection (as the login-keyring can be the default-keyring, you can have multiple keyrings, one is the default, one the login):
< The "default keyring" employs the user's login for encryption, eliminating the need for a second password.
> The "login keyring" employs the user's login for encryption, eliminating the need for a second password.

The below, which is about or a kind of a warning for users, not simply just delete the keyring,
until they later find out that the lost their passwords:
Either:
< Here's the short procedure to turn PAM on:
> Here's the short procedure to turn PAM on, if you do not store any passwords with help of gnome-keyring already.

Or add the one line below
2. delete the existing keyrings folder: ~/.local/share/keyrings
> ( do this only if you do not already store any passwords )

< Default keyring already exists
> Default keyring already exists and is used for storing application password.

And I'm sure, I have overlooked some of my own spelling/typo errors ;=)

Posted: **Thu Sep 13, 2018 7:59 pm**

thanx

Posted: **Sun Sep 16, 2018 7:23 pm**

Since I mentioned Ubuntu 14.04 in this thread it can be worth to mention that libpam-gnome-keyring is indeed installed in that distro.

Posted: **Fri Sep 21, 2018 6:14 am**

I followed the directions, but I was still getting prompted for the password to the default keyring. With the help of this article, I finally figured out the problem.

This was the content of my /etc/pam.d/lightdm:

Code: Select all

#%PAM-1.0

# Block login if they are globally disabled
auth      requisite pam_nologin.so

# Load environment from /etc/environment and ~/.pam_environment
session      required pam_env.so readenv=1
session      required pam_env.so readenv=1 envfile=/etc/default/locale

@include common-auth

-auth  optional pam_gnome_keyring.so

@include common-account

# SELinux needs to be the first session rule. This ensures that any
# lingering context has been cleared. Without out this it is possible
# that a module could execute code in the wrong domain.
# When the module is present, "required" would be sufficient (When SELinux
# is disabled, this returns success.)
session  [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close

session  required        pam_limits.so
session  required        pam_loginuid.so
@include common-session

# SELinux needs to intervene at login time to ensure that the process
# starts in the proper default security context. Only sessions which are
# intended to run in the user's context should be run after this.
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
# When the module is present, "required" would be sufficient (When SELinux
# is disabled, this returns success.)

-session optional        pam_gnome_keyring.so auto_start

@include common-password

The dashes in front of auth optional pam_gnome_keyring.so and session optional pam_gnome_keyring.so auto_start inactivates the options, so PAM was never starting the keyring.

I removed the dashes, logged out and in, and now everything works perfectly.

Posted: **Fri Sep 21, 2018 6:22 am**

Thanks for pointing this out. We will check and adjust accordingly.

Posted: **Fri Sep 21, 2018 8:15 pm**

bwhawk wrote: Fri Sep 21, 2018 6:14 am ...
The dashes in front of auth optional pam_gnome_keyring.so and session optional pam_gnome_keyring.so auto_start inactivates the options, so PAM was never starting the keyring.

I removed the dashes, logged out and in, and now everything works perfectly.

@bwhawk ,
I've just check and verfied the procedure described at the beginning
of this thread and now also within this MX-Wiki entry MX-Wiki: gnome-keyring
by booting from a MX17.1-ISO and just installing libpam-gnome-keyring.

The two lines starting with a dash, you mentioned above,
are still present within /etc/pam.d/lightdm as shown here:

Code: Select all

cat   /etc/pam.d/lightdm  | grep keyring
-auth  optional pam_gnome_keyring.so
-session optional        pam_gnome_keyring.so auto_start

After logout and login I do find within "Password and Keys"
a newly generated login-keyring which was aromatically unlocked
and marked as the default keyring.

To further proof that this login-keyring will be used by an app
requesting credentials I also installed Chromium from MXPI.
Starting Chromium without any password prompt
I can verify that Chromium's internal key was stored within the default/login
gnome-keyring.
So you seem to have done or set up something differently, which
caused some additional steps to do.

Posted: **Fri Sep 21, 2018 9:03 pm**

Yeah, I figured it probably worked normally for most people, or I would have found more incidents of this happening. I was mostly posting this in the hopefully unlikely event anyone else ever experiences it.

Although I am curious. Since the lines are commented out, what is launching gnome-keyring-daemon for you?

Posted: **Sat Sep 22, 2018 4:21 am**

bwhawk wrote: Fri Sep 21, 2018 9:03 pm Since the lines are commented out, what is launching gnome-keyring-daemon for you?

Well, the pam-moule is started by pam.
Appears to me that the dash (hyphen) sign is more relevant to system log
related events according to the man page of pam.d:

man pam.d wrote: man pam.d
...

The type is the management group that the rule corresponds to. It is used to specify which of the management
groups the subsequent module is to be associated with. Valid entries are:
...
auth
this module type provides two aspects of authenticating the user. Firstly, it establishes that the user is
who they claim to be, by instructing the application to prompt the user for a password or other means of
identification. Secondly, the module can grant group membership or other privileges through its credential
granting properties.
...
If the type value from the list above is prepended with a - character the PAM library will not log to the
system log if it is not possible to load the module because it is missing in the system. This can be useful
especially for modules which are not always installed on the system and are not required for correct
authentication and authorization of the login session.

Posted: **Sat Sep 22, 2018 5:33 am**

So that other document is wrong. Which I can believe because after I restarted my system and logged in, the default keyring wasn't unlocked. In my previous test, I only logged out and back in, and that doesn't seem to be enough of a test, at least for my system.

So I'm back where I started from. I'll keep trying to track this down.

Posted: **Sat Sep 22, 2018 6:09 am**

bwhawk wrote: Sat Sep 22, 2018 5:33 am ...I restarted my system and logged in, the default keyring wasn't unlocked. In my previous test, I only logged out and back in, and that doesn't seem to be enough of a test, at least for my system.

To be precise: Pam will unlock the login-keyring after login. If you have only one keyring the login-keyring becomes also the "default keyring". If you have more than one keyring it will further unlock the other keyring on app-request. I.e. after login the other keyring appears to be locked, but will be unlocked automatically by PAM if an application requires access. You can choose another keyring as the default keyring and instruct PAM to unlock the other keyring on application request, as described within my first post of this thread. If an app does not specify which keyring to access the "default keyring" will used.

Posted: **Sat Sep 22, 2018 6:55 am**

The problem is that PAM isn't unlocking the login keyring when I login. So that's what I'm trying to track down. Perhaps I'm missing some PAM components or something is weird in one of the config files.

Posted: **Sat Sep 22, 2018 7:10 am**

bwhawk wrote: Sat Sep 22, 2018 6:55 am The problem is that PAM isn't unlocking the login keyring when I login.

Simple solution: Remove the login keyring using "Password and keys", logout and login. PAM will create a new login keyring, and will also make sure, that the login-keyring will synced any account password changes. In the old days you would need to manually adjust the login keyring-password, after having changed your user account login-password. The newer pam will take care to synchronise both.
Manual solution: Make sure you login-keyring password is identical to you login-account password.

Note further: PAM wil only unlock login-keyring if you authenticate with your password during login. With auto-login PAM cannot unlock the login-keyring as no credentials have been provided.

Posted: **Sat Sep 22, 2018 7:25 am**

Yes, I've tried that several times.

Just now, I deleted the entire ~/.local/share/keyrings folder. When I restarted and logged back in, the folder was not created. That's why I think PAM isn't running, or at least isn't running correctly.

Posted: **Sat Sep 22, 2018 7:35 am**

bwhawk wrote: Sat Sep 22, 2018 7:25 am Yes, I've tried that several times.

Just now, I deleted the entire ~/.local/share/keyrings folder. When I restarted and logged back in, the folder was not created. That's why I think PAM isn't running, or at least isn't running correctly.

Hmm you can verify how it supposed to be by running from a LiveUSB/ISO. just installation of libpam-gnome-keyring logout and login as normal user demo, would do. Not sure what's differenf within your setup.

Posted: **Sat Sep 22, 2018 7:52 am**

I'm about to build a new system anyway, which will hopefully render this whole problem moot since I'll be installing a fresh copy of MX 17.1. I just hate admitting defeat.

Posted: **Tue Sep 25, 2018 4:51 pm**

I use Antix a lot of the time and use Google Chrome, there is no popup keyrings request. I have a number of passwords saved in Google Chrome and have no problems. Using MX on several machines, i must kill 3 keyring popups on machine #1 On Machine #2 I must kill 6 popups...

All my saved passwords are synced with Google Chrome, including my Chromebook.

What is different with Antix "No popups" and MX #1 and Number #2... Where do I look, as I am reading in this thread my passwords maybe stored in MX as text files? Or are all my passwords stored as text files in all my google chrome synced systems including my Chromebook?

Completely confused as to what is happening. I have friends calling they want the popup eliminated in their MX systems and I am still not certain what is happening. In questioning one user, she uses an apple phone to save all her passwords, but uses her MX computer when home for the larger screen. She gets 6 popup to kill and believes she has never saved a password on her computer.

Can gnome-keyring or pam be removed, to kill this popup inconvenience/inconsistency for all chromium or google chrome users?

Posted: **Tue Sep 25, 2018 4:58 pm**

What do you not understand in first post of this thread and the wiki entry?
It was fairly detailed explained inculding D_O short cut version, for user who don't save any password with chromium.

Posted: **Tue Sep 25, 2018 6:01 pm**

I think namida12 wanted to know why it happens in MX, but not in Antix. Anyway, I didn't manage to get rid of them completely at first so this is my extended procedure (just did it and works so far):

(I don't care about saved passwords, they may disappear with this method and have to be reentered)

1. install libpam-gnome-keyring
2. delete everything in "Password and Keys" application unless you have something important there
3. delete ~/.local/share/keyrings
4. reboot

That should do it (I hope).

Posted: **Tue Sep 25, 2018 6:06 pm**

dreamer wrote: Tue Sep 25, 2018 6:01 pm I think namida12 wanted to know why it happens in MX, but not in Antix. Anyway, I didn't manage to get rid of them completely at first so this is my extended procedure (just did it and works so far):

(I don't care about saved passwords, they may disappear with this method and have to be reentered)

1. install libpam-gnome-keyring
2. delete everything in "Password and Keys" application unless you have something important there
3. delete ~/.local/share/keyrings
4. reboot

That should do it (I hope).

Thanks. Good summary.
Re AntiX, will certainly look into this...

Posted: **Tue Sep 25, 2018 6:28 pm**

fehlix wrote: Tue Sep 25, 2018 6:06 pm
dreamer wrote: Tue Sep 25, 2018 6:01 pm I think namida12 wanted to know why it happens in MX, but not in Antix. Anyway, I didn't manage to get rid of them completely at first so this is my extended procedure (just did it and works so far):

(I don't care about saved passwords, they may disappear with this method and have to be reentered)

1. install libpam-gnome-keyring
2. delete everything in "Password and Keys" application unless you have something important there
3. delete ~/.local/share/keyrings
4. reboot

That should do it (I hope).
Thanks. Good summary.
Re AntiX, will certainly look into this...

fehlix, thank you...

I find these in Antix

Code: Select all

gnome-keyring 3.20.0-3
libpam-elogind 234.4.2.3
libpam-gnome-keyring 3.20.03  <--- pam module to unlock the GNOME keyring upon login
libpam-modules 1.1.8-3.6
libpam-modules-bin 1.1.8-3.6
libpam-runtime 1.1.8-3.6
libpam0g 1.1.8-3.6

JR

Posted: **Tue Sep 25, 2018 6:34 pm**

namida12 wrote: Tue Sep 25, 2018 6:28 pm I find these in Antix

Code: Select all

gnome-keyring 3.20.0-3
libpam-elogind 234.4.2.3
libpam-gnome-keyring 3.20.03  <--- pam module to unlock the GNOME keyring upon login
libpam-modules 1.1.8-3.6
libpam-modules-bin 1.1.8-3.6
libpam-runtime 1.1.8-3.6
libpam0g 1.1.8-3.6

So you solved the puzzle. antiX does it already. And your google-synced passwords are already properly
protected by Chromium and with help of gnome-keyring.

Good to know.
Thanks

Posted: **Tue Sep 25, 2018 7:23 pm**

fehlix wrote: Tue Sep 25, 2018 6:34 pm
namida12 wrote: Tue Sep 25, 2018 6:28 pm I find these in Antix
Code: Select all
gnome-keyring 3.20.0-3
libpam-elogind 234.4.2.3
libpam-gnome-keyring 3.20.03  <--- pam module to unlock the GNOME keyring upon login
libpam-modules 1.1.8-3.6
libpam-modules-bin 1.1.8-3.6
libpam-runtime 1.1.8-3.6
libpam0g 1.1.8-3.6
So you solved the puzzle. antiX does it already. And your google-synced passwords are already properly
protected by Chromium and with help of gnome-keyring.
Good to know.
Thanks

fehlix.

MX has
libpam-systemd installed Not in AntiX, I do not know if that matters I am way above my head, just trying to find differences in gnome and Pam in the two...

JR

Posted: **Tue Sep 25, 2018 7:24 pm**

Antix might not have gnome-keyring installed. That would be something to check

Posted: **Tue Sep 25, 2018 7:30 pm**

dolphin_oracle wrote: Tue Sep 25, 2018 7:24 pm Antix might not have gnome-keyring installed. That would be something to check

Think is is installed see my list, but how would I check?

JR

Posted: **Tue Sep 25, 2018 7:40 pm**

namida12 wrote: Tue Sep 25, 2018 7:30 pm
dolphin_oracle wrote: Tue Sep 25, 2018 7:24 pm Antix might not have gnome-keyring installed. That would be something to check
Think is is installed see my list, but how would I check?

JR

check in synaptic. its shows all the status of each package.

but I see in your list that libpam-gnome-keyring is already installed in antiX (as fehlix noted). so that is the difference. MX didn't have libpam-gnome-keyring by default (next release will).

Posted: **Wed Sep 26, 2018 1:46 am**

dolphin_oracle wrote: Tue Sep 25, 2018 7:40 pm
namida12 wrote: Tue Sep 25, 2018 7:30 pm
dolphin_oracle wrote: Tue Sep 25, 2018 7:24 pm Antix might not have gnome-keyring installed. That would be something to check
Think is is installed see my list, but how would I check?

JR
check in synaptic. its shows all the status of each package.

but I see in your list that libpam-gnome-keyring is already installed in antiX (as Felix noted). so that is the difference. MX didn't have libpam-gnome-keyring by default (next release will).

Felix & dolphin_oracle,

I added libpam-gnome-keyring to MX via Synaptic, and shutdown my MX system. When it reopened discovered It did not remember any passwords including Synaptic.
MX had forgotten all of my passwords.

Not true, I synced my Google Chrome accounts via the Chromebook because I was using that system for a video chat and now I have access to most of the passwords via Google Chrome, but still do not have access to Synaptic.
Update: restarting MX several times and using a terminal with su I was able to access Synaptic, and it now works using the GUI... Glitch, or just my typing? it is now working, or could it be libpam-systemd in MX?

Should I remove libpam-systemd? It is not installed in AntiX

JR

Posted: **Wed Sep 26, 2018 2:17 pm**

I added libpam-gnome-keyring to MX via Synaptic to second MX 17.1 computer and restarted. Works well no problems with passwords.

Will call Apple phone user friend and have her add this to her MX 17.1 linux computer and see how it affects her Google Chrome passwords & MX Linux install...
Then I will update this thread...

JR

Posted: **Wed Sep 26, 2018 3:02 pm**

namida12 wrote: Wed Sep 26, 2018 1:46 am I added libpam-gnome-keyring to MX via Synaptic, and shutdown my MX system. When it reopened discovered It did not remember any passwords including Synaptic.
MX had forgotten all of my passwords.

OK, I digged into this a bit further ...
After adding libpam-gnome-keyring and having removed all
keyring-files from ~/.local/share/keyrings
only a logout/login is required. PAM will create a new login-keyring.
This new keyring will also become the "default" keyring, i.e. it has
the properties to be "default". And further PAM will unlock
this "default" login-keyring after you logged-in with a password.

Chrome will now see the new "default" keyring and will further use
this empty keyring to populated after syncing with your passwords.

Synaptic: We do have two GUI-ways to start synaptic, either through
the menu or through right-click of apt-notifier.
Starting synaptic through the menu will go through a pkexec-authentication
and will always ask for a password.

When you start synaptic through apt-notifier-icon it
goes with help of /usr/bin/su-to-root to a call of gksu.
Gksu is enabled with a PAM-API to call gnome-keyring.

And now we should assume that gksu would also use the "default" keyring,
which happens to be the login-keying, when you request the entered
password to be saved "permanently" not only for the session.

When you now enter the password to be saved "remember password"
it will than asked you to enter the password for a new "default" keyring.

And this is an outstanding bug with Gnome/GTK, which I remember have seen
a couple of years ago when gnome-keyring still was young.

The issue is that the gnome/gtk developer seem to be got confused
about the gnome-keyring API and the use of the term "default keyring".

The GTK-implementation used by gksu unfortunately misinterprets
the API-documention and do look for a keyring with the name "default"
instead of the property "default".
So the popup to create a new "default" keyring is about to create a new keyring
with the name "default", instead of using the existing "default" login-keyring

An the other side Chrome/Chromium are doing it right, both using
the existing login-keying (property default) to store/save the passwords.

Now what? The workaround is simple: Let GTK/gksu create
the new "default-keyring", i.e. enter any password you like.
The keyring will be unlocked by PAM. But you might still
enter than once again the password for the "default-keyring" where
you than got an option to click "remember password to unlock after login."

Summary: If you use app which intern relies on gksu, you might still need to"create" a new "default" keyring,
due to a gtk "bug" if you want to store the entered "root" password permanently.
Solution just create the new "default" keyring and click next time remember, if you like.

Ufff .. to many words .. I know .. sorry

Posted: **Wed Oct 03, 2018 10:54 am**

Is it possible to store ssh key passwords also?
Don't want to type it at any time.

Posted: **Wed Oct 03, 2018 12:03 pm**

c4os wrote: Wed Oct 03, 2018 10:54 am Is it possible to store ssh key passwords also?
Don't want to type it at any time.

Yes. In addition to other ssh-agents like libpam-ssh, ssh-agent and gnupg-agent,
you can also use ssh-components of Gnome-keyring to provide a ssh-agent
single-sign-on functionality.

A short How-to enable SSH-single sign-on through Gnome-keyring:
-> enable Gnome-keyring's SSH-agent within session autostart
-> save your ssh-passphrase of your "my_ssh_key" within gnome-keyring like this:

Code: Select all

cd $HOME/.ssh
/usr/lib/x86_64-linux-gnu/seahorse/seahorse-ssh-askpass my_ssh_key

where my_ssh_key is the filename of your pub/sec keys without extension.

Make sure you marked the gnome-keyring which holds your ssh-passphrase
as "Automatically unlock ....", which you can check and set within Seahorse (aka "Passwords and Keys").
Note further you shall only enable/use one ssh-agent to reduce confusion

Posted: **Wed Oct 03, 2018 12:53 pm**

fehlix wrote: Wed Oct 03, 2018 12:03 pm
c4os wrote: Wed Oct 03, 2018 10:54 am Is it possible to store ssh key passwords also?
Don't want to type it at any time.
Yes. In addition to other ssh-agents like libpam-ssh, ssh-agent and gnupg-agent,
you can also use ssh-components of Gnome-keyring to provide a ssh-agent
single-sign-on functionality.

A short How-to enable SSH-single sign-on through Gnome-keyring:
-> enable Gnome-keyring's SSH-agent within session autostart
-> save your ssh-passphrase of your "my_ssh_key" within gnome-keyring like this:
Code: Select all
cd $HOME/.ssh
/usr/lib/x86_64-linux-gnu/seahorse/seahorse-ssh-askpass my_ssh_key
where my_ssh_key is the filename of your pub/sec keys without extension.

Make sure you marked the gnome-keyring which holds your ssh-passphrase
as "Automatically unlock ....", which you can check and set within Seahorse (aka "Passwords and Keys").
Note further you shall only enable/use one ssh-agent to reduce confusion

I' ll get some messages:

Code: Select all

$ /usr/lib/x86_64-linux-gnu/seahorse/seahorse-ssh-askpass my_ssh_key 

(seahorse-ssh-askpass:6294): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:186:14: not a number

(seahorse-ssh-askpass:6294): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:186:14: Expected a string.

(seahorse-ssh-askpass:6294): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:2749:24: not a number

(seahorse-ssh-askpass:6294): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:2749:24: Expected a string.

(seahorse-ssh-askpass:6294): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:2940:14: not a number

(seahorse-ssh-askpass:6294): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:2940:14: Expected a string.

(seahorse-ssh-askpass:6294): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:2946:17: Expected a string.

(seahorse-ssh-askpass:6294): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:4083:14: not a number

(seahorse-ssh-askpass:6294): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:4083:14: Expected a string.

(seahorse-ssh-askpass:6294): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:4088:17: Expected a string.

(seahorse-ssh-askpass:6294): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:4729:14: not a number

(seahorse-ssh-askpass:6294): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:4729:14: Expected a string.

(seahorse-ssh-askpass:6294): Gtk-WARNING **: Theme parsing error: xfce.css:47:16: not a number

(seahorse-ssh-askpass:6294): Gtk-WARNING **: Theme parsing error: xfce.css:47:16: Expected a string.

(seahorse-ssh-askpass:6294): Gtk-WARNING **: Theme parsing error: lightdm-gtk-greeter.css:16:14: not a number

(seahorse-ssh-askpass:6294): Gtk-WARNING **: Theme parsing error: lightdm-gtk-greeter.css:16:14: Expected a string.

(seahorse-ssh-askpass:6294): Gtk-WARNING **: Theme parsing error: lightdm-gtk-greeter.css:26:14: not a number

(seahorse-ssh-askpass:6294): Gtk-WARNING **: Theme parsing error: lightdm-gtk-greeter.css:26:14: Expected a string.

(seahorse-ssh-askpass:6294): Gtk-WARNING **: Theme parsing error: lightdm-gtk-greeter.css:40:16: not a number

(seahorse-ssh-askpass:6294): Gtk-WARNING **: Theme parsing error: lightdm-gtk-greeter.css:40:16: Expected a string.

(seahorse-ssh-askpass:6294): Gtk-WARNING **: Theme parsing error: lightdm-gtk-greeter.css:96:14: Expected a string.

(seahorse-ssh-askpass:6294): Gtk-WARNING **: Theme parsing error: lightdm-gtk-greeter.css:100:16: not a number

(seahorse-ssh-askpass:6294): Gtk-WARNING **: Theme parsing error: lightdm-gtk-greeter.css:100:16: Expected a string.

(seahorse-ssh-askpass:6294): Gtk-WARNING **: Theme parsing error: lightdm-gtk-greeter.css:279:14: not a number

(seahorse-ssh-askpass:6294): Gtk-WARNING **: Theme parsing error: lightdm-gtk-greeter.css:279:14: Expected a string.
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.

And after a "ssh myserver" it asks me again for password.

Posted: **Wed Oct 03, 2018 1:20 pm**

c4os wrote: Wed Oct 03, 2018 12:53 pm And after a "ssh myserver" it asks me again for password.

Not sure. Perhaps try using libpam-ssh, which requires to enter the ssh-pasphrase once within a session.

apt show libpam-ssh wrote: Description: Authenticate using SSH keys
This pluggable authentication module (PAM) provides single sign-on
using secure shell (SSH) keys:
- during authentication, the user types a SSH passphrase and is authenticated
if the passphrase successfully decrypts the user's SSH private keys;
- in session phase, a ssh-agent process is started and decrypted keys are
added, and thus the user can SSH to other hosts that accept key
authentication without typing more passwords for the entire session.

Posted: **Fri Oct 05, 2018 8:37 am**

fehlix wrote: Wed Oct 03, 2018 1:20 pm
c4os wrote: Wed Oct 03, 2018 12:53 pm And after a "ssh myserver" it asks me again for password.
Not sure. Perhaps try using libpam-ssh, which requires to enter the ssh-pasphrase once within a session.
apt show libpam-ssh wrote: Description: Authenticate using SSH keys
This pluggable authentication module (PAM) provides single sign-on
using secure shell (SSH) keys:
- during authentication, the user types a SSH passphrase and is authenticated
if the passphrase successfully decrypts the user's SSH private keys;
- in session phase, a ssh-agent process is started and decrypted keys are
added, and thus the user can SSH to other hosts that accept key
authentication without typing more passwords for the entire session.

libpam-ssh doesn' t work.

ssh-agent only works with one session.
I tried:

Code: Select all

$ eval `ssh-agent`
Agent pid 2157

$ ssh-add ~/.ssh/id_rsa
Enter passphrase for /home/user/.ssh/id_rsa:
Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)

If I run 'ssh-add ~/.ssh/id_rsa', it will help to unlock my key. No need to type in again.

Posted: **Fri Oct 05, 2018 4:12 pm**

dreamer wrote: Tue Sep 25, 2018 6:01 pm I think namida12 wanted to know why it happens in MX, but not in Antix. Anyway, I didn't manage to get rid of them completely at first so this is my extended procedure (just did it and works so far):

(I don't care about saved passwords, they may disappear with this method and have to be reentered)

1. install libpam-gnome-keyring
2. delete everything in "Password and Keys" application unless you have something important there
3. delete ~/.local/share/keyrings
4. reboot

That should do it (I hope).

I did what I described above. Sometimes it works, but sometimes Evolution and Skype show this message:

I accept defeat by Gnome keyring. There is probably some bug in gnome-keyring (as fehlix described). I never saw it in Ubuntu, but it may be present in newer Ubuntu versions that I haven't used.

Posted: **Fri Oct 05, 2018 6:17 pm**

dreamer wrote: Fri Oct 05, 2018 4:12 pm Sometimes it works, but sometimes Evolution and Skype show this message:

"Sometimes?" - Any systematic? after (re-)boot, logout, login, after suspense?
The message shows the "login" keyring was not unlocked.
Could you check "sometimes" with "Password and Keys" the login-keyring is locked or shows unlocked after logged in.
Are there more than one keyring there? Another keyring with name "login" which is not a login-keyring

.
Is gnome-keyring-secrets starting in autostart?

Posted: **Fri Oct 05, 2018 8:07 pm**

fehlix wrote: Fri Oct 05, 2018 6:17 pm Could you check "sometimes" with "Password and Keys" the login-keyring is locked or shows unlocked after logged in.
Are there more than one keyring there? Another keyring with name "login" which is not a login-keyring .
Is gnome-keyring-secrets starting in autostart?

Problem solved. Thanks, fehlix.

Secret Storage Service (GNOME Keyring: Secret Service)

Code: Select all

/usr/bin/gnome-keyring-daemon --start --components=secrets

This checkbox wasn't marked in Application Autostart. Evolution, Skype and Chrome now start without keyring prompt. I have only one keyring and it is unlocked.

Here is the updated procedure:
1. install libpam-gnome-keyring AND MAKE SURE the service is marked in Application Autostart
2. delete everything in "Password and Keys" application unless you have something important there
3. delete ~/.local/share/keyrings
4. reboot

Posted: **Tue Oct 09, 2018 4:16 am**

I'll get an error with the command:

Code: Select all

$ /usr/bin/gnome-keyring-daemon --start --components=secrets
** Message: couldn't access control socket: /run/user/1000/keyring/control:  Datei oder Verzeichnis nicht gefunden

"Datei oder Verzeichnis nicht gefunden" means file or directory not found.
Courious, there is a file called control:

Code: Select all

$ ls -l /run/user/1000/keyring/
insgesamt 0
srwxr-xr-x 1 c4os c4os 0 Okt  9 09:33 control

And ssh still asks me for the password of my ~/.ssh/id_rsa.
My look on the autostart commponents found an agent for ssh. But this wont also help.

Code: Select all

$ /usr/bin/gnome-keyring-daemon --start --components=ssh
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh

ssh still asks my password.
Maybe I need Gnome terminal to bring it to work?
But I want to keep my lovely Terminator.

Will my ssh and gpg keys removed from my system when I delete it's from password and encryption app?

The only one which works on my side with ssh is:

Code: Select all

$ ssh-add ~/.ssh/id_rsa
Enter passphrase for /home/c4os/.ssh/id_rsa: 
Identity added: /home/c4os/.ssh/id_rsa (/home/c4os/.ssh/id_rsa)

Posted: **Tue Oct 09, 2018 5:19 am**

c4os wrote: Tue Oct 09, 2018 4:16 am I'll get an error with the command:
Code: Select all
$ /usr/bin/gnome-keyring-daemon --start --components=secrets
** Message: couldn't access control socket: /run/user/1000/keyring/control:  Datei oder Verzeichnis nicht gefunden

That's a message is to inform that no running daemon exists, so it will create a new gnome-keyring control-soccket.

c4os wrote: Tue Oct 09, 2018 4:16 am ssh still asks my password.
Maybe I need Gnome terminal to bring it to work?
But I want to keep my lovely Terminator.

The keyring component starts from with autostart, no need for gnome terminal.
We need to look into this, to find a way to fix this.

c4os wrote: Tue Oct 09, 2018 4:16 am Will my ssh and gpg keys removed from my system when I delete it's from password and encryption app?

"Password and Keys" provides not only access to gnome-keyring, but also to your gpg-keyring and ssh-key's.
So yes you can remove within Password and Keys (Seahorse), your gnupg and ssh-key , if you like

c4os wrote: Tue Oct 09, 2018 4:16 am The only one which works on my side with ssh is:
Code: Select all
$ ssh-add ~/.ssh/id_rsa
Enter passphrase for /home/c4os/.ssh/id_rsa: 
Identity added: /home/c4os/.ssh/id_rsa (/home/c4os/.ssh/id_rsa)

Yea, using ssh-add + ssh- agent seem to be the most reliable way to deal with single-sign-on ssh-authentication.

Posted: **Thu Nov 01, 2018 7:30 am**

It's all very confusing

Should there separate Login keyring as well as the default and should they both be left open after I run Chromium or Geary?
I followed the the procedure described after "Default keyring already exists" in the Wiki mentioned in this subject. I had already installed libpam-gnome-keyring but I never saw the mention of "Automatically unlock this keyring whenever I’m logged in" when unlocking the Default keyring. However, on logging back in I briefly saw a mention of this automatic option already ticked in a pop-up immediately after I entered my normal user password.
Now everything sees to work without any requests to re-enter passwords as mentioned by some other users here. However, as I mentioned, I'm a bit concerned that both keyrings are left permanently open as long as I'm logged in. Is this normal?

agrendel

Posted: **Thu Nov 01, 2018 9:17 am**

agrendel wrote: Thu Nov 01, 2018 7:30 am Should there separate Login keyring as well as the default and should they both be left open after I run Chromium or Geary?

It depends, if the login keyring is also marked as "default" an application might "decide" to use this "default" login-keyring.
Not sure about Geary, some applications requesting to use a keyring with the name "default" some other with the property "default".

agrendel wrote: Thu Nov 01, 2018 7:30 am However, as I mentioned, I'm a bit concerned that both keyrings are left permanently open as long as I'm logged in. Is this normal?

Well, that's per design. If you want to lock the keyrings manually, you can bind a desktop-shortcut or a keyboard-shortcut to this command:

Code: Select all

gnome-keyring-daemon --replace --daemonize

After running the command, gnome-keyring will be restarted and by this goes into the state of locked keyrings.
Note: If you would now restart Chromium or Geary, you will get prompted to enter the password for
the used "default" keyring. You can check the used password of the "default" keyring by changing password e.g. using the identical password
within Password and Key (aka Seahorse).

If you are still confused, don't hesitate to formulate the unknown

Posted: **Fri Nov 02, 2018 7:53 am**

Many thanks fehlix for your prompt and very complete reply. As I have a mini-PC also running mx-linux now I decided to try the same operation as on my Thinkpad and the result was more or less the same except that I had to log back in twice for the automatic opening of the default and log-in keys to be completed. The first login asked for my password but had the box "Automatically unlock this keyring whenever I’m logged in" already ticked so on the second login the second key was added and both are now unlocked. Works fine.

Posted: **Mon Nov 12, 2018 12:26 am**

fehlix,

I certainly hope this is fixed and does not require any fixes for new or experienced users of MX-18 or MX-17.2 in the forthcoming release...

JR

Posted: **Tue Nov 27, 2018 11:30 am**

Hello to all. I'm new to this forum.

Hope the next release comes per default with libpam-gnome-keyring. In Xfce DE you must also set Settings>Session and Startup>Advanced and selecting Launch Gnome Services on Startup per default. Works nicely.

Posted: **Tue Nov 27, 2018 11:53 am**

Welcome, and thanks for the tip.

Posted: **Tue Nov 27, 2018 12:01 pm**

dphn wrote: Tue Nov 27, 2018 11:30 am In Xfce DE you must also set Settings>Session and Startup>Advanced and selecting Launch Gnome Services on Startup per default.

Not necessarily. For unlocking (and/or creating) the default keyring libpam will already trigger gnome-keyring-daemon at login-time. So there is no need to start gnome-keyring again, it might even conflicting with the already running daemon. Only for additional keyring-components like ssh-agents or certificat-access additional autostart-entries might need to get turned on.
At least this is the theory. Anyway for any app which really does not work without the already running daemon, we migth have a look for find the reason for this.

Posted: **Sat Apr 27, 2019 3:05 pm**

fehlix wrote: Wed Sep 12, 2018 4:45 pm Gnome-keyring - unlocked
Enable secure password store with gnome-keyring to avoid keyring prompt
...
Attched the above as PDF-file.

--fehlix
on behalf of MX Linux community

... Perfect

Posted: **Mon Jun 17, 2019 7:22 am**

Sorry, fehlix, I am confused by your pdf.
Please tell me in simple words how to completely disable the annoying popups which I get every time I open opera - I just click cancel on the popup but it pops up again, and I again click cancel .... finally opera starts. I just want to stop all this annoyance - I don't want any keyring.

Posted: **Mon Jun 17, 2019 7:32 am**

Now in the Wiki: https://mxlinux.org/uncategorized/gnome-keyring/

Posted: **Mon Jun 17, 2019 7:50 am**

Just to note that this is not a 100% guarantee the problem will stay gone. But if it reoccurs, simply do it again.

Or enter your username password, works for me until it gets TOO annoying.

Posted: **Mon Jun 17, 2019 7:55 am**

Jerry3904 wrote: Mon Jun 17, 2019 7:32 am Now in the Wiki: https://mxlinux.org/uncategorized/gnome-keyring/

I can't find "/.local/share/keyrings".

Screenshot-1.png

Perhaps because I do not want, and have not created, any keyrings?

Posted: **Mon Jun 17, 2019 8:04 am**

You're searching within the main file system, not your home directory. In Thunar file manager click View/Show Hidden Files within your own home directory (which Thunar will open by default when you start it) and you'll see .local. Double-click on it then on share then on keyrings.

Posted: **Mon Jun 17, 2019 8:14 am**

I can't find "/.local/share/keyrings"

Actually, you left off the symbol "~" that is in the Wiki, which indicates what JayM said.

[I wonder where that convention is made clear to users...? EDIT: I expanded the Wiki entry to make it clear]

Posted: **Mon Jun 17, 2019 9:01 am**

GuiGuy wrote: Mon Jun 17, 2019 7:22 am .. I am confused ..
Please tell me in simple words ...

I can try simplify to reformulate in layman's terms .. or perhaps think about a little "unlock my opera" rescue script... later ...

For now quick workaround/fix:
-> don't use Thunar as Root - as it will lock all keyrings
-> just logout an login again : keyring will be "unlocked" when logged in
-> if entered already a password into the"keyring popup", and if
this password differs from your normal log-in password, better remove all keyrings and
logout login again.

GuiGuy wrote: Mon Jun 17, 2019 7:22 am I just want to stop all this annoyance - I don't want any keyring.

Opera is based on Chromium, which now insists on having a keyring ...
I might check whether "plaintext keyring" (which is not gnome-keyring") is still possible to enable.
OTOH, plaintext keyring is highly not recommended, as session-hi-jacking might be to easy, so if you do any sensible stuff, with login's on website, better think twice ...
ALso some user recommend an "empty" password to use, which goes in the same in-secure category as plaintext keyring
... that's it for now ...

...later ...

Posted: **Mon Jun 17, 2019 9:08 am**

ALso some user recommend an "empty" password to use

I believe that user has been corrected and feels ashamed...

Posted: **Mon Jun 17, 2019 9:36 am**

Jerry3904 wrote: Mon Jun 17, 2019 8:14 am
I can't find "/.local/share/keyrings"
Actually, you left off the symbol "~" that is in the Wiki, which indicates what JayM said.

[I wonder where that convention is made clear to users...? EDIT: I expanded the Wiki entry to make it clear]

Still can't find it.

Screenshot-4.png

P.S. I am using MX8.2, fully updated: my username is "dtest"
P.P.S May I suggest that this keyring nonsense should be made optional rather than being in the distro by default?

Posted: **Mon Jun 17, 2019 9:48 am**

GuiGuy wrote: Mon Jun 17, 2019 9:36 am Still can't find it.
P.S. I am using MX8.2, fully updated: my username is "dtest"

Just open thunar and paste into the "address fied"
either

Code: Select all

~/.local/share/keyrings

or

Code: Select all

/home/dtest/.local/share/keyrings

Note "~/" is shorthand for your home directory /home/dest/
And Thunar shall accept this short version.
Also have you read the quick workaround above. As a simple logout login might be sufficient.

Posted: **Mon Jun 17, 2019 10:01 am**

fehlix wrote: Mon Jun 17, 2019 9:48 am
Just open thunar and paste into the "address fied"
either
Code: Select all
~/.local/share/keyrings
or
Code: Select all
/home/dtest/.local/share/keyrings
Note "~/" is shorthand for your home directory /home/dest/
And Thunar shall accept this short version.
Also have you read the quick workaround above. As a simple logout login might be sufficient.

Screenshot-5.png

Nothing found!

Posted: **Mon Jun 17, 2019 10:09 am**

Why is this keyring nonsense in the distro by default: could it not be made optional?
BTW when I attempt to remove the keyring app, synaptic wants to remove other apps which I do require.

Posted: **Mon Jun 17, 2019 10:13 am**

It came like that? Blame the google devs who made chrome?

It's like this in other distros as well. Manjaro forum has posts on it.

Posted: **Mon Jun 17, 2019 10:19 am**

asqwerth wrote: Mon Jun 17, 2019 10:13 am It came like that? Blame the google devs who made chrome?

It's like this in other distros as well. Manjaro forum has posts on it.

In my case I guess opera is the culprit: I don't use chrome.

But I do like opera: is there a workaround for this problem?

Posted: **Mon Jun 17, 2019 10:44 am**

Yes.. the one that was posted... or a different browser not Opera and not Chrome.

Unfortunately there is no getting around it as far as I know.

Posted: **Mon Jun 17, 2019 10:57 am**

Doesn't Opera use the same browser engine as Chrome or Chromium?

The workaround - fehlix was giving you the instructions, I believe.

Posted: **Mon Jun 17, 2019 11:15 am**

asqwerth wrote: Mon Jun 17, 2019 10:57 am Doesn't Opera use the same browser engine as Chrome or Chromium?

The workaround - fehlix was giving you the instructions, I believe.

Which fehlix post has the correct workaround? (This thread is very long and confusing.)
BTW am now posting from opera, after cancelling the dreaded popup three times

.

Posted: **Mon Jun 17, 2019 11:35 am**

Guy

This works for me .. YMMV

In Xfce - go to Utilities - Passwords & Keys - delete Default Keyring & close
Done ... log into your favorite program, hit continue, two times ... done
Y'all might have to do this again, right after successful login ..

This works for Skype ... and has for many months [KDE]should be good for Opera too

Wish one of the devs would kill this thing ... enough with the nanny-state stuff already

Wouldnt us Chrome on a bet

Regards

Jack

GuiGuy wrote: Mon Jun 17, 2019 10:09 am Why is this keyring nonsense in the distro by default: could it not be made optional?
BTW when I attempt to remove the keyring app, synaptic wants to remove other apps which I do require.

Posted: **Mon Jun 17, 2019 11:39 am**

Thing is the nanny state is not something WE do, as far as I know.

Trust me if it could be gotten rid of easily it would have been done already.

Posted: **Mon Jun 17, 2019 6:25 pm**

I think I have found the answer

:-

Started seahorse (Whisker menu calls it "Passwords and Keys") and created a new keyring named login (don't know whether the name matters) with blank password.
The nasty popups when starting skype or opera now do not happen :party5:

.

I hope this will survive reboots: if it does not I will report back on this thread.

Posted: **Tue Jun 18, 2019 4:34 am**

Still no pesky popups

.

login.keyring file appears in my home directory

Screenshot-6.png

The file is readable by seahorse but looks garbled in featherpad.

I believe my solution works: it's certainly simpler than those previously discussed in this thread.

Posted: **Tue Jun 18, 2019 6:13 am**

GuiGuy wrote: Tue Jun 18, 2019 4:34 am I believe my solution works: it's certainly simpler than those previously discussed in this thread.

Yes, with an empty password it works. So make sure you protect your Browser and access to your laptop, as password-less unprotected keyrings are readable by any process you are running. As otherwise session hi-jacking, identity-theft or stolen password might be the consequence. I guess, there is a reason, why Chromium has chosen to insists in having a normally well protected keyring to store a online-session related information into.

Posted: **Tue Jun 18, 2019 6:42 am**

Thanks, fehlix.

Jerry: should the wiki be modified again?

Posted: **Tue Jun 18, 2019 6:46 am**

Not sure ATM. I was chastised originally when I posted that solution, which we had in the Wiki and the Users Manual. Will let it ride for a bit...

Posted: **Tue Jun 18, 2019 7:33 am**

GuiGuy wrote: Tue Jun 18, 2019 6:42 am Thanks, fehlix.

Jerry: should the wiki be modified again?

Not sure if I read this correctly, probably I should have spelled it out more directly.
The password-less login-keyring setup, is not a solution, we shall recommend,
it's rather a highly insecure workaround, for the situation the system is screwed up somehow.
The proper way to handle this, is to let pam (Pluggable Authentication Modules) do unlock
the login-keyring after user login.

You can test whether your pam is broken, by changing the password of the login keyring
using seahorse "Passwords and Keys" to be identical to your login password. After logout login open seahorse again,
and check whether you can open the login keyring without entering a password, i.e. the keyring is already unlocked.

Another test whether you login-pam is broken, would be : remove all keyrings within seahorse
logout and login. Now if login-pam is working, it would have create a new login keyring automatically,
already unlocked but protected with you normal login-password.

You could check the "protecting password of the login-keyring, by right-click-> lock,
and again by right-click unlock, entering your login-password to unprotect.

If you verified that your pam is not broken, we can instruct/setup the individual apps, like skype, chromium, vialvadi, opera etc in a way the do have access to the protected keyring without entering a password.

I might redo this with Opera, and provide a step by step instruction, in case it is still unclear.

Posted: **Tue Jun 18, 2019 12:11 pm**

Thanks again, fehlix.

By deleting my login.keyring file and following the Wiki instructions I now have the keyring working correctly and

securely

.

[There are some typos in the instructions: IMO this bit

Screenshot-7.png

is confusing and should be corrected.]

Posted: **Tue Jun 18, 2019 12:22 pm**

Which part is confusing?

Posted: **Tue Jun 18, 2019 12:59 pm**

GuiGuy wrote: Tue Jun 18, 2019 12:11 pm By deleting my login.keyring file and following the Wiki instructions I now have the keyring working correctly and securely .
[There are some typos in the instructions: IMO this bitScreenshot-7.pngis confusing and should be corrected.]

Just ignore this part under the headeline "Default keyring already exists".
This part is meant for user who do have already a "default" keyring used by apps wich already had stored passwords into.
Those user certainly do not want to remove all keyrings including their existing passwords.
Please do ask explicitly what you do not understand, as otherwise I tend explain to much, which might not help you to get a clear picture of your situation.
Note: Gnome-keyring can handle multiple keyrings: One of those is the "login"-keyring, automatically unlocked by pam.
And another one can be marked as "default", which stores user passwords on application request, e.g by Opera, etc.
If only one keyring (the login-keyring) exists, this keyring takes also the role as "default" keyring.. I shall better stop now I guess .

Posted: **Tue Jun 18, 2019 1:32 pm**

fehlix wrote: Tue Jun 18, 2019 12:59 pm..........
Note: Gnome-keyring can handle multiple keyrings: One of those is the "login"-keyring, automatically unlocked by pam.
And another one can be marked as "default", which stores user passwords on application request, e.g by Opera, etc.
If only one keyring (the login-keyring) exists, this keyring takes also the role as "default" keyring.. I shall better stop now I guess .

Thanks once again, fehlix.
I did not realise I could have more than one keyring: otherwise I am now quite happy with my setup.

I am just trying to help with perfecting the Wiki: IMO it needs careful proof-reading, preferably by somebody whose mother-tongue is English(American).
Of course it is pretty good already, otherwise I could not have followed it with 90% success.

P.S. I apologize for my slow octogenarian brain.

Posted: **Thu Jun 27, 2019 12:50 pm**

I found the gnome-keyring to be very annoying - whenever I booted this OS from a computer-off state the keyring was NOT unlocked automatically by my logging in.
I believe I have got around the problem by changing my keyring password to blank: this seems to work OK, and I presume my keyring is still encrypted.

Posted: **Thu Jun 27, 2019 1:35 pm**

GuiGuy wrote: Thu Jun 27, 2019 12:50 pm I found the gnome-keyring to be very annoying - whenever I booted this OS from a computer-off state the keyring was NOT unlocked automatically by my logging in.
I believe I have got around the problem by changing my keyring password to blank: this seems to work OK, and I presume my keyring is still encrypted.

The only situation, I can think of, is when you autologin. In this situation, the pam-module cannot unlock the keyring, as no password, was given during login.
With a blank password, the keyring (file) is readable by any processes. E.g. a little script, with read permission of the filesystem, can transfer the whole content to another place. :lipsrsealed:

Posted: **Thu Jun 27, 2019 1:57 pm**

fehlix wrote: Thu Jun 27, 2019 1:35 pm
The only situation, I can think of, is when you autologin. In this situation, the pam-module cannot unlock the keyring, as no password, was given during login.
With a blank password, the keyring (file) is readable by any processes. E.g. a little script, with read permission of the filesystem, can transfer the whole content to another place. :lipsrsealed:

No, I never use autologin.
And nobody but my wife and I has physical access to this machine.

Has any other MX user tried the gnome-keyring ?

Posted: **Thu Jun 27, 2019 2:31 pm**

GuiGuy wrote: Thu Jun 27, 2019 1:57 pm Has any other MX user tried the gnome-keyring ?

Not willingly

We just encounter it when running Skype, Google Chrome, and some other stuff

Posted: **Thu Jun 27, 2019 3:46 pm**

Eadwine Rose wrote: Thu Jun 27, 2019 2:31 pm
GuiGuy wrote: Thu Jun 27, 2019 1:57 pm Has any other MX user tried the gnome-keyring ?
Not willingly

We just encounter it when running Skype, Google Chrome, and some other stuff

So how do you deal with it?

Posted: **Thu Jun 27, 2019 3:48 pm**

Swearing, muttering, entering my user password, or using the solution Fehlix gave a while ago.

I believe it is described here: https://mxlinux.org/uncategorized/gnome-keyring/

Posted: **Thu Jun 27, 2019 3:58 pm**

Eadwine Rose wrote: Thu Jun 27, 2019 3:48 pm Swearing, muttering, entering my user password, or using the solution Fehlix gave a while ago.

I believe it is described here: https://mxlinux.org/uncategorized/gnome-keyring/

Thanks, E R. I found Fehlix's method unsatisfactory until I changed the keyring password to blank.
I wonder what Jerry does when he uses Opera.

Posted: **Thu Jun 27, 2019 6:30 pm**

GuiGuy wrote: Thu Jun 27, 2019 3:58 pm .. unsatisfactory until I changed the keyring password to blank.

Any chance to help you? I mean the more detailed information is provided they higher is the chance we identify the issue why it is not working for you properly.
I have Chromium and Vivaldi, which both require a keyring, and works unlocked after login. OK as soon I run Thunar as root, the keyring is blocked, but I run Thunar as root rather rarely anyway.

Posted: **Fri Jun 28, 2019 4:53 am**

Thanks for offering further help, Fehlix, but I do not need it because I am now satisfied with the performance of my system.

Unless another MX user wants more information I am minded to mark this thread "SOLVED".

Duh! I did not start the thread....have just marked my own posts.

Posted: **Sun Jul 28, 2019 4:12 am**

Was experiencing the same issue, and just went into mx package manager, stable repo, put gnome in the search box and uninstalled the following programs, now i do not get a request for keyring with chromiuim.

the main programs i ticked for uninstall were the

gnome settings daemon
gnome system log
open vpn-gnome
gnome pinentry-gnome3 and policykit-1-gnome.

In my case think the issue was caused by installing gnome desktop a few weeks back.

Posted: **Sun Jul 28, 2019 12:18 pm**

whenever I booted this OS from a computer-off state the keyring was NOT unlocked automatically by my logging in.
I believe I have got around the problem by changing my keyring password to blank

This was the same for me, even though I don't auto login. I was not unduly troubled by it as I used firefox but a couple of months ago I switched to using Brave ( a chromium base browser) and started getting the keyring popups. I did the same thing blanked the password and bingo.
I am guessing chromium is protecting the passwords it offers to save for you in those keyrings. And as I dont let it do that ( I use lastPass ) I dont have any security issues by not password protecting the keyring ....unless someone can tell me otherwise?

Posted: **Sun Jul 28, 2019 2:01 pm**

wellsey wrote: Sun Jul 28, 2019 12:18 pm ....unless someone can tell me otherwise?

Chrome stores within Gnome-keyring passwords for web-sites, if allowing to store passwords was not deselect.

Chrome stores it's "Chrome Safe Storage" master key during installation or first time run as an application password. This "master" key is used by Chrome to encrypt/decrypt securely any data stored within the local store-databases.

To get a rough idea what this might be: press F12 -> Application Tab -> Storage.

Not sure whether Chrome has a reason to protect that data, but I guess there must be one.

If it is considered to be not worth to protect that data, opening Chrome /chromium using this command line flag:
--password-store=basic
will disable secure protection and chrome will not protect any data/password stored.

Having gnome-keyring set to use an empty password, will also have all other application using gnome-keyring to store the application related passwords/data unprotected.
HTH

Posted: **Sun Jul 28, 2019 2:52 pm**

Thanks for the reply Fehlix

Posted: **Tue Jun 30, 2020 3:55 am**

Please, explain me:

How can I check that my passwords are not a plain text saved in file?
How can I view the current chromium flag value --password-store?
Possible values are: kwallet, kwallet5, gnome, gnome-keyring, gnome-libsecret, basic. Which one will be correct for libpam-gnome-keyring?
How can I define it permanently in MxLinux?

Posted: **Tue Jun 30, 2020 5:14 am**

simwin wrote: Tue Jun 30, 2020 3:55 am Please, explain me:
How can I check that my passwords are not a plain text saved in file?

How can I view the current chromium flag value --password-store?

Possible values are: kwallet, kwallet5, gnome, gnome-keyring, gnome-libsecret, basic. Which one will be correct for libpam-gnome-keyring?

How can I define it permanently in MxLinux?

The default auto-detected flag in MX Linux is "detect": --password-store=detect
Which defaults in MX Linux Xfce to --password-store=gnome
You can check it this way: Open Password and Keys (aka seahorse), lock the default keyring and start chromium, it will ask to unlock the default login keyring. The default login keyring will be unlocked during Session login after you entered the login-password. If you have enabled auto-login, the default-login keyring cannot be unlocked, so chromium would always ask to manually unlock.

Posted: **Tue Jun 30, 2020 8:33 am**

fehlix wrote: Tue Jun 30, 2020 5:14 am
simwin wrote: Tue Jun 30, 2020 3:55 am Please, explain me:
How can I check that my passwords are not a plain text saved in file?

How can I view the current chromium flag value --password-store?

Possible values are: kwallet, kwallet5, gnome, gnome-keyring, gnome-libsecret, basic. Which one will be correct for libpam-gnome-keyring?

How can I define it permanently in MxLinux?

The default auto-detected flag in MX Linux is "detect": --password-store=detect
Which defaults in MX Linux Xfce to --password-store=gnome
You can check it this way: Open Password and Keys (aka seahorse), lock the default keyring and start chromium, it will ask to unlock the default login keyring. The default login keyring will be unlocked during Session login after you entered the login-password. If you have enabled auto-login, the default-login keyring cannot be unlocked, so chromium would always ask to manually unlock.

Yes, I've checked it - chromium ask to unlock the default login keyring. But why I can not see chromium saved passwords in seahorse?

Posted: **Tue Jun 30, 2020 8:35 am**

simwin wrote: Tue Jun 30, 2020 8:33 am
fehlix wrote: Tue Jun 30, 2020 5:14 am
simwin wrote: Tue Jun 30, 2020 3:55 am Please, explain me:
How can I check that my passwords are not a plain text saved in file?

How can I view the current chromium flag value --password-store?

Possible values are: kwallet, kwallet5, gnome, gnome-keyring, gnome-libsecret, basic. Which one will be correct for libpam-gnome-keyring?

How can I define it permanently in MxLinux?

The default auto-detected flag in MX Linux is "detect": --password-store=detect
Which defaults in MX Linux Xfce to --password-store=gnome
You can check it this way: Open Password and Keys (aka seahorse), lock the default keyring and start chromium, it will ask to unlock the default login keyring. The default login keyring will be unlocked during Session login after you entered the login-password. If you have enabled auto-login, the default-login keyring cannot be unlocked, so chromium would always ask to manually unlock.
Yes, I've checked it - chromium ask to unlock the default login keyring. But why I can not see chromium saved passwords in seahorse?

It holds only the "master" key(s), the "encrypted storage" is internal within chromium somewhere.

Posted: **Tue Jun 30, 2020 8:52 am**

fehlix wrote: Tue Jun 30, 2020 8:35 am
simwin wrote: Tue Jun 30, 2020 8:33 am
fehlix wrote: Tue Jun 30, 2020 5:14 am
The default auto-detected flag in MX Linux is "detect": --password-store=detect
Which defaults in MX Linux Xfce to --password-store=gnome
You can check it this way: Open Password and Keys (aka seahorse), lock the default keyring and start chromium, it will ask to unlock the default login keyring. The default login keyring will be unlocked during Session login after you entered the login-password. If you have enabled auto-login, the default-login keyring cannot be unlocked, so chromium would always ask to manually unlock.
Yes, I've checked it - chromium ask to unlock the default login keyring. But why I can not see chromium saved passwords in seahorse?
It holds only the "master" key(s), the "encrypted storage" is internal within chromium somewhere.

Ok! Thank you for consult!

Posted: **Tue Jul 21, 2020 7:29 pm**

fehlix wrote: Tue Jun 30, 2020 8:35 am
simwin wrote: Tue Jun 30, 2020 8:33 am
fehlix wrote: Tue Jun 30, 2020 5:14 am
The default auto-detected flag in MX Linux is "detect": --password-store=detect
Which defaults in MX Linux Xfce to --password-store=gnome
You can check it this way: Open Password and Keys (aka seahorse), lock the default keyring and start chromium, it will ask to unlock the default login keyring. The default login keyring will be unlocked during Session login after you entered the login-password. If you have enabled auto-login, the default-login keyring cannot be unlocked, so chromium would always ask to manually unlock.
Yes, I've checked it - chromium ask to unlock the default login keyring. But why I can not see chromium saved passwords in seahorse?
It holds only the "master" key(s), the "encrypted storage" is internal within chromium somewhere.

Please help! :) Chromium, Chrome and Opera can't use gnome-keyring and I don't know why, what was doing by me... may be - intalling nodm (no display manager), but when I switch to lightdm the problem isn't disappeared

ps aux | grep gnome

/usr/bin/gnome-keyring-daemon --start --components=pkcs11,secrets,ssh
/usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1
/usr/lib/at-spi2-core/at-spi2-registryd --use-gnome-session

Now I use nodm and unlock gnome keys in seahorse by hands. In login chain keys section chromium, chrome, opera can't generate its keys. With lightdm the result is the same.

Posted: **Tue Jul 21, 2020 7:35 pm**

simwin wrote: Tue Jul 21, 2020 7:29 pm Plese help! :) Chromium, Chrome and Opera can't use gnome-keyring and I don't know why, what was doing by me...

Any error message?

Posted: **Tue Jul 21, 2020 7:41 pm**

fehlix wrote: Tue Jul 21, 2020 7:35 pm
simwin wrote: Tue Jul 21, 2020 7:29 pm Plese help! :) Chromium, Chrome and Opera can't use gnome-keyring and I don't know why, what was doing by me...
Any error message?

chromium --enable-logging --v=10

Code: Select all

Using PPAPI flash.
[2573:2573:0722/023847.629965:ERROR:edid_parser.cc(102)] Too short EDID data: manufacturer id
[2573:2611:0722/023847.657287:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[2573:2611:0722/023847.657350:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[2573:2611:0722/023847.705783:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[2573:2611:0722/023847.705858:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[2612:2612:0722/023848.211788:ERROR:sandbox_linux.cc(374)] InitializeSandbox() called with multiple threads in process gpu-process.
[2612:2661:0722/023848.224186:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: 
No such file or directory (2)
[2612:2661:0722/023848.224437:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: 
No such file or directory (2)
[2612:2661:0722/023848.224554:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: 
No such file or directory (2)
[2630:1:0722/023848.277511:ERROR:paint_controller.cc(646)] PaintController::FinishCycle() completed
[2630:1:0722/023848.405037:ERROR:paint_controller.cc(646)] PaintController::FinishCycle() completed
[2630:1:0722/023848.477842:ERROR:paint_controller.cc(646)] PaintController::FinishCycle() completed

Sorry - I have to sleep :) Try to solve to 02:40 am :)

Posted: **Tue Jul 21, 2020 8:41 pm**

simwin wrote: Tue Jul 21, 2020 7:41 pm

fehlix wrote: Tue Jul 21, 2020 7:35 pm
simwin wrote: Tue Jul 21, 2020 7:29 pm Plese help! :) Chromium, Chrome and Opera can't use gnome-keyring and I don't know why, what was doing by me...
Any error message?

chromium --enable-logging --v=10

Code: Select all

Using PPAPI flash.
[2573:2573:0722/023847.629965:ERROR:edid_parser.cc(102)] Too short EDID data: manufacturer id
[2573:2611:0722/023847.657287:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[2573:2611:0722/023847.657350:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[2573:2611:0722/023847.705783:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[2573:2611:0722/023847.705858:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[2612:2612:0722/023848.211788:ERROR:sandbox_linux.cc(374)] InitializeSandbox() called with multiple threads in process gpu-process.
[2612:2661:0722/023848.224186:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: 
No such file or directory (2)
[2612:2661:0722/023848.224437:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: 
No such file or directory (2)
[2612:2661:0722/023848.224554:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: 
No such file or directory (2)
[2630:1:0722/023848.277511:ERROR:paint_controller.cc(646)] PaintController::FinishCycle() completed
[2630:1:0722/023848.405037:ERROR:paint_controller.cc(646)] PaintController::FinishCycle() completed
[2630:1:0722/023848.477842:ERROR:paint_controller.cc(646)] PaintController::FinishCycle() completed

Don't see any relationship with those error messages and your statement "can't use gnome-keyring".
The only one might be, a non running browser can not use gnome-keyring ... but you might have another reason, why you think that this has something todo with gnome-keyring. If not, your report would not fit into this thread.

Posted: **Wed Jul 22, 2020 2:18 am**

fehlix wrote: Tue Jul 21, 2020 8:41 pm

simwin wrote: Tue Jul 21, 2020 7:41 pm

fehlix wrote: Tue Jul 21, 2020 7:35 pm
Any error message?

chromium --enable-logging --v=10

Code: Select all

Using PPAPI flash.
[2573:2573:0722/023847.629965:ERROR:edid_parser.cc(102)] Too short EDID data: manufacturer id
[2573:2611:0722/023847.657287:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[2573:2611:0722/023847.657350:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[2573:2611:0722/023847.705783:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[2573:2611:0722/023847.705858:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[2612:2612:0722/023848.211788:ERROR:sandbox_linux.cc(374)] InitializeSandbox() called with multiple threads in process gpu-process.
[2612:2661:0722/023848.224186:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: 
No such file or directory (2)
[2612:2661:0722/023848.224437:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: 
No such file or directory (2)
[2612:2661:0722/023848.224554:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: 
No such file or directory (2)
[2630:1:0722/023848.277511:ERROR:paint_controller.cc(646)] PaintController::FinishCycle() completed
[2630:1:0722/023848.405037:ERROR:paint_controller.cc(646)] PaintController::FinishCycle() completed
[2630:1:0722/023848.477842:ERROR:paint_controller.cc(646)] PaintController::FinishCycle() completed

Don't see any relationship with those error messages and your statement "can't use gnome-keyring".
The only one might be, a non running browser can not use gnome-keyring ... but you might have another reason, why you think that this has something todo with gnome-keyring. If not, your report would not fit into this thread.

Now I use nodm, fluxbox and I unlock gnome keys in seahorse by my hands. Chromium, Chrome and Opera can't generate its keys in gnome login key section. With lightdm the result is the same. All browsers can start and work perfectly, but save passwords without gnome-keyring in base type manner. May be some services don't run in fluxbox?

Posted: **Wed Jul 22, 2020 3:17 am**

simwin wrote: Wed Jul 22, 2020 2:18 am
fehlix wrote: Tue Jul 21, 2020 8:41 pm
simwin wrote: Tue Jul 21, 2020 7:41 pm

chromium --enable-logging --v=10
Code: Select all
Using PPAPI flash.
[2573:2573:0722/023847.629965:ERROR:edid_parser.cc(102)] Too short EDID data: manufacturer id
[2573:2611:0722/023847.657287:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[2573:2611:0722/023847.657350:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[2573:2611:0722/023847.705783:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[2573:2611:0722/023847.705858:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[2612:2612:0722/023848.211788:ERROR:sandbox_linux.cc(374)] InitializeSandbox() called with multiple threads in process gpu-process.
[2612:2661:0722/023848.224186:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: 
No such file or directory (2)
[2612:2661:0722/023848.224437:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: 
No such file or directory (2)
[2612:2661:0722/023848.224554:ERROR:gbm_wrapper.cc(271)] Failed to export buffer to dma_buf: 
No such file or directory (2)
[2630:1:0722/023848.277511:ERROR:paint_controller.cc(646)] PaintController::FinishCycle() completed
[2630:1:0722/023848.405037:ERROR:paint_controller.cc(646)] PaintController::FinishCycle() completed
[2630:1:0722/023848.477842:ERROR:paint_controller.cc(646)] PaintController::FinishCycle() completed
Don't see any relationship with those error messages and your statement "can't use gnome-keyring".
The only one might be, a non running browser can not use gnome-keyring ... but you might have another reason, why you think that this has something todo with gnome-keyring. If not, your report would not fit into this thread.
Now I use nodm, fluxbox and I unlock gnome keys in seahorse by my hands. Chromium, Chrome and Opera can't generate its keys in gnome login key section. With lightdm the result is the same. All browsers can start and work perfectly, but save passwords without gnome-keyring in base type manner. May be some services don't run in fluxbox?

My problem (and its name is Failed to connect to the bus) was solved by this line in ~/.xsessionrc:

exec dbus-launch --sh-syntax --exit-with-session startfluxbox

The old version was:

exec startfluxbox

So all my ~/.xsessionrc is:

Code: Select all

eval $(/usr/bin/gnome-keyring-daemon --start --components=pkcs11,secrets,ssh)
export SSH_AUTH_SOCK
exec dbus-launch --sh-syntax --exit-with-session startfluxbox

Posted: **Sat Sep 26, 2020 12:16 am**

fehlix wrote: Wed Sep 26, 2018 3:02 pm
namida12 wrote: Wed Sep 26, 2018 1:46 am I added libpam-gnome-keyring to MX via Synaptic, and shutdown my MX system. When it reopened discovered It did not remember any passwords including Synaptic.
MX had forgotten all of my passwords.
OK, I digged into this a bit further ...
After adding libpam-gnome-keyring and having removed all
keyring-files from ~/.local/share/keyrings
only a logout/login is required. PAM will create a new login-keyring.
This new keyring will also become the "default" keyring, i.e. it has
the properties to be "default". And further PAM will unlock
this "default" login-keyring after you logged-in with a password.

Chrome will now see the new "default" keyring and will further use
this empty keyring to populated after syncing with your passwords.

Synaptic: We do have two GUI-ways to start synaptic, either through
the menu or through right-click of apt-notifier.
Starting synaptic through the menu will go through a pkexec-authentication
and will always ask for a password.

When you start synaptic through apt-notifier-icon it
goes with help of /usr/bin/su-to-root to a call of gksu.
Gksu is enabled with a PAM-API to call gnome-keyring.

And now we should assume that gksu would also use the "default" keyring,
which happens to be the login-keying, when you request the entered
password to be saved "permanently" not only for the session.

When you now enter the password to be saved "remember password"
it will than asked you to enter the password for a new "default" keyring.

And this is an outstanding bug with Gnome/GTK, which I remember have seen
a couple of years ago when gnome-keyring still was young.

The issue is that the gnome/gtk developer seem to be got confused
about the gnome-keyring API and the use of the term "default keyring".

The GTK-implementation used by gksu unfortunately misinterprets
the API-documention and do look for a keyring with the name "default"
instead of the property "default".
So the popup to create a new "default" keyring is about to create a new keyring
with the name "default", instead of using the existing "default" login-keyring

An the other side Chrome/Chromium are doing it right, both using
the existing login-keying (property default) to store/save the passwords.

Now what? The workaround is simple: Let GTK/gksu create
the new "default-keyring", i.e. enter any password you like.
The keyring will be unlocked by PAM. But you might still
enter than once again the password for the "default-keyring" where
you than got an option to click "remember password to unlock after login."

Summary: If you use app which intern relies on gksu, you might still need to"create" a new "default" keyring,
due to a gtk "bug" if you want to store the entered "root" password permanently.
Solution just create the new "default" keyring and click next time remember, if you like.

Ufff .. to many words .. I know .. sorry

APOLOGIES FOR BUMPING AN OLD THREAD but just to maintain the accuracy and completeness of the thread, I thought I would point out a couple of things here:

1) gksu has been deprecated from Debian so it can't be used any longer to 'unlock' synaptic in the way you described.

I had an amazing function in my MX15 build before I installed MX19 a few days ago which I really miss alot. Whenever I would run apt-notifier (or synaptic as you mentioned above and the package installer too if i remember correctly) a dialog box would come up and ask me if I wanted to save my sudo password for the session or for longer. I would choose entire session and then it was always so easy to keep opening synaptic without entering passwords. Over the last few days, I have had to open synaptic hundreds of times to check the packages themselves as well as detailed info on dependencies, file locations etc and it has been very very frustrating and exhausting to constantly type the password in.

Also

2) since I did an MX19 install with a preserved /home partition, my previous keys (Evolution, chrome) were still stored in ~./local/share/keyrings so I had a look and THEY WERE IN PLAIN TEXT FILES!!!!!! The Passwords and Keys app had also picked the old keys up automatically and they were saved in the app as well. I had 2 keys: Login and Default. The old chrome and old evolution (uninstalled a long time ago even before updating to MX19) passwords were stored under the Default key and the Login key was empty. The Default key was 'set as default'. I took your advice and deleted the old keyrings directory from my ~./local/share/ (actually I just renamed it keyrings.bak) and rebooted. After reboot, I checked Passwords and Keys and indeed there was only ONE key there called Login and it was 'set as default'. I close the app and then opened SLIMJET browser, which is based on Chromium and SLIMJET asked me to sign-in again. (I was already signed in before rebooting). Anyway, after signing in, I closed and re-opened Passwords and Keys app and there was still only one key: Login but this time the chrome and Chromium passwords were stored under it. When I clicked on the chrome password a dialog box came up with the password highlighted but hidden i.e. *********. I clicked on the symbol to see if it would reveal the password. IT DID, BUT IS WAS ENCRYPTED. I checked the ./local/share keyrings directory (the app automatically made a new one) and there are NO TEXT FILES so it looks like everything is working as it should and safe and secure.

To summarise: Just delete the hidden /home/user/.local/share/keyrings directory as Fehlix mentioned and reboot and you should be good to go.

Posted: **Tue Jan 26, 2021 2:01 pm**

Not sure if I can tag along or open another thread. I followed the instructions, when I closed my browser (Brave), and opened Password and Keys, my Login entry Set default is grayed out, what I'm missing? Here's my screenshot

ps: how can I post my image on my desktop?

Posted: **Tue Jan 26, 2021 4:38 pm**

michaelbr wrote: Tue Jan 26, 2021 2:01 pm I followed the instructions, when I closed my browser (Brave), and opened Password and Keys, my Login entry Set default is grayed out, what I'm missing? Here's my screenshot

Not sure what you followd and what you actually did.
Just checked within a live system.
Installing Brave and Vivaldi from MX Package Installer ->Pop.Apps->Browser:
First on Live System I need to logout and login again, b/c live's auto-login would prevent PAM to create a login-keyring.
Opening Brave and closing shows in Password'n'Keys this:

brave-safe-storage.png

Now open Vivaldi:

chrome-safe-storage.png

So Vivaldi still uses the original chromium safe-storage name.
PS: You would attach an image with the "Attachments" button below the editor.

Posted: **Wed Jan 27, 2021 1:03 pm**

fehlix wrote: Tue Jan 26, 2021 4:38 pm Not sure what you followd and what you actually did.
Just checked within a live system.
Installing Brave and Vivaldi from MX Package Installer ->Pop.Apps->Browser:
First on Live System I need to logout and login again, b/c live's auto-login would prevent PAM to create a login-keyring.

I followed your first post on this topic, when I tried to set my keyring as default, it's grayed out, unfortunately the screenshot doesn't allow me to right click, as you can see, the Brave is in the list.

Posted: **Wed Jan 27, 2021 1:59 pm**

michaelbr wrote: Wed Jan 27, 2021 1:03 pm I followed your first post on this topic, when I tried to set my keyring as default ...

The automatically generated login keyring is also the default b/c there is only one keyring - nothing to set here.

Posted: **Thu Jan 28, 2021 2:28 am**

fehlix wrote: Wed Jan 27, 2021 1:59 pm The automatically generated login keyring is also the default b/c there is only one keyring - nothing to set here.

So why everytime I login, a message came up saying that

Code: Select all

my login keyring could not unlock

or something similar, and asked for my password? Is this supposed to work this way?
ps: I set to automatically login, this has something to do with asking for password?

Posted: **Thu Jan 28, 2021 8:35 am**

michaelbr wrote: Thu Jan 28, 2021 2:28 am ps: I set to automatically login, this has something to do with asking for password?

Yes, with auto-login enabled you would need to manually unlock the login-keyring.

Posted: **Fri Jan 29, 2021 8:13 am**

fehlix wrote: Thu Jan 28, 2021 8:35 am Yes, with auto-login enabled you would need to manually unlock the login-keyring.

Thanks so much for your patience and feedback.

Posted: **Fri Mar 05, 2021 9:10 am**

I have made the following experiment. My question is: Is this the normal behaviour?

1. I use auto-login
2. I have one key-ring. It is default and has auto unlock when I log me in manually.

Now I have made this:
0. the default key-ring is unlocked.
1. Added an additional key-ring. Name "experiment", password: "123456"
2. in Seahorse: locked the key-ring "experiment"
3. unlocked the key-ring "experiment"
4. entered the password "123456"
5. checked the text: "Automatically unlock this key ring when logging in"
6. both key-rings are unlocked now
7. log out. log in. (NOT a new boot)
8. My expectation was, that now both key-rings are unlocked. But only the default key-ring is unlocked.

Is this as it should be?

9. Now I open Seahorse
10. try to unlock the key-ring "experiment"
11. -> This works without asking for any password

Is this the way it should work?

Thank you.

Edit: The behaviour is the same, after having added a new password entry into the key-ring "experiment".

Posted: **Fri Mar 05, 2021 11:55 am**

Duliwi wrote: Fri Mar 05, 2021 9:10 am I have made the following experiment. My question is: Is this the normal behaviour?

1. I use auto-login
2. I have one key-ring. It is default and has auto unlock when I log me in manually.

Now I have made this:
0. the default key-ring is unlocked.
1. Added an additional key-ring. Name "experiment", password: "123456"
2. in Seahorse: locked the key-ring "experiment"
3. unlocked the key-ring "experiment"
4. entered the password "123456"
5. checked the text: "Automatically unlock this key ring when logging in"
6. both key-rings are unlocked now
7. log out. log in. (NOT a new boot)
8. My expectation was, that now both key-rings are unlocked. But only the default key-ring is unlocked.

Is this as it should be?

9. Now I open Seahorse
10. try to unlock the key-ring "experiment"
11. -> This works without asking for any password

Is this the way it should work?

Thank you.

Edit: The behaviour is the same, after having added a new password entry into the key-ring "experiment".

Yes, the one keyring which is a the "login" keyring (regardless of the names shown) will be unlocked at login.
The login-keyring can only be unlocked at login, when both user-login-password and the password of the login-kyring are identical. Now, the login keyinring can hold normal passwords but also passwords from other keyrings.
Liek in you example the "experiment" keyring it protected by it's own password. But you was prompted with the question "Automatically unlock this key ring when logging in", and by accepting it, the system stored the password of the experiment-keyring into the login-keyring. What happens: As soon as an application ( or you manually) try to access the "experiment"-keyring it checks whther this can be automtically unlocked. It can, as long as you have stored it password with the login-keyring. Try to remove the experiment-password from the login-keyring, and it will not unlock anymore without entering the correct experiment-password.

[Klare Sache und damit hopp!]

Posted: **Fri Mar 05, 2021 12:22 pm**

Thank you @fehlix

fehlix wrote: Fri Mar 05, 2021 11:55 am ... you was prompted with the question "Automatically unlock this key ring when logging in", and by accepting it, the system stored the password of the experiment-keyring into the login-keyring.

Indeed. I did not realise that until now.

Posted: **Tue May 11, 2021 2:44 am**

As far as I can tell this guide allows me to not have to enter my login password of the PC whenever I use Thunar to connect to my local nas. I still have to enter the login to the nas however so I'm not quite sure how exactly useful it really is at this time. I spent 20m trying to understand the 1st post, which btw should be upodated (libpam-gnome-keyring does not need to be installed anymore), and was trying to autologin to the nas with no success.

When I first unlocked the "Login" ring it added an entry for the nas and I hadn't even logged into it yet. VERY confusing.
I created a 2nd keyring to correspond to the nas but that is also confusing. Is the name the address because the only other option is the password?, and of course the "automatically log me in" option does nothing, because it simply doesn't.
Very confusing. 30 m later and now under the 'default' "Login" keyring I have 2 entries: one titled admin@mynas.local, and the other "Unlock password for: smb://admin@mynas.local/. Yet if I log out and back in (Login is unlocked) it prompts me to enter the nas login credentials. Seriously?

If it's unlocked does this mean it automatically stores passwords because automatically logging in isn't working. OR, do I have to create a send ring to incl. the nas that specifically states autologin (didn't work before???)
Like I said, networking is not my forte. I may as well delete what I did cause having to type my login and the nas credentials is simpler than spending 30m trying to figure out seahorse and getting nowhere.

After logging out and in 5 times, and after rebooting 5 times, all I can figure is to simply unlock the "Login" keyring, login to nas (this creates a key entry) and tell it to remember forvever, create a second keyring for nas titled admin@mynas.local and call it a day. I still have to login to the nas on reboots. Logging in and out is simply entering the password which I was trying NOT to do. On boot It STILL makes me login to the nas. USELESS OMG
Seahorse is more like an exercise (a futile one) in entering passwords and rebooting.
Back to square 1. Only difference is I'm logged in, I'm logged into nas, and the "Login" keyring is unlocked with zero entries. No matter what I try it asks me to login to the nas EVERY SINGLE TIME I reboot. I seriously cannot believe it won't allow thunar to login by itself. Who knows whatever

Posted: **Tue May 11, 2021 7:43 am**

It works here out of the box. Actually just tested with my NAS using with ftp or smb protocoll and on MX 19.4. LiveISO.
The easiest to test and find the culprit might be, boot from latest LiveISO/USB. As it defaults to autologin
do logout/login to have a login-keyring generated. The way I'm testing is just by booting VirtualBox with networkbridge and attached MX LiveISO. And it stores credentials for both NAS-ftp and NAS-smb.
To start from scratch just remove the existing keyrings ( rm ~/.local/share/keyrings/* )
and logout login again.
If still not working you might consider to give more details. Or if something not yet clear, do formulate it as a specific question, which I can understand and potentially find an answer.

Posted: **Thu May 13, 2021 9:51 am**

Thanks. I remember, not even sure exactly when, but I had checked a gnome-keyring? box in the boot/sessions dialog one time and then on reboot it asked for a keyring password (3rd password?) you enter only once per session, I think, I really don't remember. I did not have a nas or network then. If I check the last box in sessions, some keyring thing, I do not get any prompts after booting that anything has changed. I'm aware of having a keyring password but do not want to have an arbitrary time at which it pops up. If I need to, or it's useful to use it, I want it to be the very next thing I do after I login to password safe when booting. Shoots I don't really know what the keyring does (for me) at this point. I can't quite figure out the seahorse nonsense.

I literally had 2 "login" keyrings going at once when I checked seahorse yesterday and deleted one. I did not mess with seahorse at all as I had 'reset' it and it just created a 2nd entry all on it's own. Could be my network config. I'm running a wireguard vpn but I generally connect to the same ap using the same browser, thunar, or DC, though either works (the nas has it's own AP). The nas does use a website cert but I'm not sure that has anything to do with seahorse stuff lol.
Once your login keyring creates entries do you lock it, reboot, and are then prompted for the keyring password? As far as I know I have never created one on this device. I was running it unlocked. Please excuse me if It's confusing because it really is. A simple one time per session entry to NOT have to constantly enter a network login would be great. And why if I hadn't even connected to my nas would editing the blank login keyring automatically populate it with my nas entry? That makes no sense at all. Unless the data is hidden of course.

Posted: **Thu May 13, 2021 10:39 am**

LibertyLinux wrote: Thu May 13, 2021 9:51 am Thanks. I remember, not even sure exactly when, but I had checked a gnome-keyring? box in the boot/sessions dialog one time and then on reboot it asked for a keyring password (3rd password?) you enter only once per session, I think, I really don't remember. I did not have a nas or network then. If I check the last box in sessions, some keyring thing, I do not get any prompts after booting that anything has changed. I'm aware of having a keyring password but do not want to have an arbitrary time at which it pops up. If I need to, or it's useful to use it, I want it to be the very next thing I do after I login to password safe when booting. Shoots I don't really know what the keyring does (for me) at this point. I can't quite figure out the seahorse nonsense.

I literally had 2 "login" keyrings going at once when I checked seahorse yesterday and deleted one. I did not mess with seahorse at all as I had 'reset' it and it just created a 2nd entry all on it's own. Could be my network config. I'm running a wireguard vpn but I generally connect to the same ap using the same browser, thunar, or DC, though either works (the nas has it's own AP). The nas does use a website cert but I'm not sure that has anything to do with seahorse stuff lol.
Once your login keyring creates entries do you lock it, reboot, and are then prompted for the keyring password? As far as I know I have never created one on this device. I was running it unlocked. Please excuse me if It's confusing because it really is. A simple one time per session entry to NOT have to constantly enter a network login would be great. And why if I hadn't even connected to my nas would editing the blank login keyring automatically populate it with my nas entry? That makes no sense at all. Unless the data is hidden of course.

OK, I may see some confusion.
Note Seahorse is just a tool for viewing/accessing all kinds of keyrings like pgp/gpg and also gnome-keyrings and some more.
You can even uninstall seahorse, it would not change the functionality of the login-keyring mechanism.
Further, to make auto-unlock gnome-keyring working: not the user but the pam-authentication plugin will create a login-keyring at first login, when no login-keying is available. A user cannot create a "login"-keying only PAM can do.

Please do this, to make/check login-keyring mechanism works:
-> Close "all" apps.
-> Remove all keyrings/files under ~/.local/share/keyrings
-> logout and login from the X-session.
Check pam has create a new keyring:

Code: Select all

ls -l  ~/.local/share/keyrings

Now open any app, which is known to use the login keyring.
E.g. some chromium based browser, like vivaldi, chrome/chromium do save a "master" key into gnome-keyring.
check with seahorse those app#s just created an entry

Code: Select all

seahorse

In case you auto-login, no login keyring would have been created or opened/unlocked, and the app trying save something into a keyring would trigger to create a new keyring, which you might now have to always enter a password to get opened.

Posted: **Fri May 14, 2021 6:25 am**

I believe that did the trick. I deleted the default "Login" ring (it then listed 12 keyrings when before it was 16), logged out & in. When I went to login to my nas it wanted to create a new keyring password. If you can believe this, I'd been using my actual login every time it would ask for a password (it never asked to create a new keyring password for some reason-maybe I missed it), so deleting everything worked. Finally. At least now my 3 passwords are working as they should be and most importantly I'm not using my login password as the keyring password.
Thank you so much sir.
MX ROXS! as usual

Posted: **Sun Jun 06, 2021 11:32 am**

So just deleting everything when confused works huh? I'm about to pull the trigger on a nas device myself so this will help I'm sure. Thanks Lilberty

Posted: **Thu Nov 25, 2021 2:00 pm**

forgot to backup the "keyrings" folder before the MX21 update. It seems this bug is still in Seahorse. For over an hour now I'm trying to get the password for this forum saved in Vivaldi, but after logout from MX it is gone. I tried all the descriptions here in this thread through and through and it doesn't save it.
Can one remove Seahorse in Synaptics and use just another Password Manager? Slowly it's driving me nuts.

Posted: **Sun Mar 20, 2022 11:16 am**

I use pass (the standard UNIX password manager) and its extensions. I found it quite secure, data is stored after encryption. Passwords can be synced with git hub using SSH keys securely. Linux/Mac/Windows/Android/IOS platforms support this either directly or through extensions both at browser and OS level. If used through github, then data on all devices will remain in sync by using pull and push operation from git. At a overall level i am quite contended with this option. For more information please visit https://www.passwordstore.org/.

Posted: **Sat Dec 21, 2024 4:06 am**

I used to be able to simply add this:
--password-store=basic %U
behind every startup command for the three web browsers which I'm using. As of the latest MX 23.4 Libretto that no longer works. At first I thought it was just Chrome until I noticed that that addition to the startup command no longer appears to work on any web browser. The solution at the beginning of this thread worked for me though. Haven't rebooted yet to see if the change sticks permanently.
Shouldn't there be some way of utilizing about:config in a web browser, in order to not require the password during startup?

Posted: **Wed Dec 25, 2024 4:26 am**

Well the instructions on the first page work ..... but only until the machine is rebooted. At that point that message about entering the password when you access the web browser appears again. I'm seeing this on all three browsers that I have in use, Chrome, Firefox, and Edge. Isn't there some way to just disable that once and for all, permanently?

Posted: **Wed Dec 25, 2024 8:30 am**

germany wrote: Wed Dec 25, 2024 4:26 am Well the instructions on the first page work ..... but only until the machine is rebooted.

Instructions can be read and interpreted differently, better tell the steps you have done.

germany wrote: Wed Dec 25, 2024 4:26 am At that point that message about entering the password when you access the web browser appears again. I'm seeing this on all three browsers that I have in use, Chrome, Firefox, and Edge. Isn't there some way to just disable that once and for all, permanently?

Perhaps, this way:
* first reset all what was done, and by this verify/confirm that's really the gnome-keyring, and nothing else,
e.g this way:
** remove/ reset keying and disable autologin
- first disable autologin, e.g. with help of "MX User Manager" tool
- close all applications /browser
- open terminal and remove existing gnome-keyring:

Code: Select all

rm ~/.local/share/keyrings/*

- reboot

Code: Select all

sudo reboot

You should now have login screen, where you enter the user password to login.
Now a new gnome-keyring would have been created and already unlocked, ready to work
with any app requiring access to the keyring.
If you still get a password prompt, than something else is causing the issue.

Posted: **Thu Dec 26, 2024 6:24 am**

fehlix wrote: Wed Dec 25, 2024 8:30 am
germany wrote: Wed Dec 25, 2024 4:26 am Well the instructions on the first page work ..... but only until the machine is rebooted.
Instructions can be read and interpreted differently, better tell the steps you have done.

No, those instructions along with the visual guide can't possibly be interpreted differently. I found out what caused the issue. For some reason I have the default keyring but then there's also the standard keyring. When I went ahead and repeated the process on the standard keyring everything was fine. I've now rebooted three times and was able to open the web-browsers without any issues. Thanks for the information though, fehlix. I will make a note of that for the future.

.

Posted: **Thu Dec 26, 2024 7:19 am**

germany wrote: Thu Dec 26, 2024 6:24 am
fehlix wrote: Wed Dec 25, 2024 8:30 am
germany wrote: Wed Dec 25, 2024 4:26 am Well the instructions on the first page work ..... but only until the machine is rebooted.
Instructions can be read and interpreted differently, better tell the steps you have done.
No, those instructions along with the visual guide can't possibly be interpreted differently.

You missed the point, reporting the steps done would have helped me to see what you have done,
in order to get a clear picture of the issue.

germany wrote: Thu Dec 26, 2024 6:24 am I found out what caused the issue. For some reason I have the default keyring but then there's also the standard keyring.

Yes, without an existing login-keyring a new "default" keyring will be created when app requesting access to a keyring
in order to store their stuff. Somehow I thought that was explained with the early posts.
To get additional default keyring unlocked at login, the system offers to place the unlocking password of
the default keyring into the login keyring, when login keyring would have been unlocked at login.
Note: IIRC, it helped me to understand whats going on, by checking with help of seahorse tool (Password & Keys) the keyring status.

Posted: **Fri Dec 27, 2024 2:08 am**

fehlix wrote: Wed Dec 25, 2024 8:30 am You missed the point, reporting the steps done would have helped me to see what you have done,
in order to get a clear picture of the issue.

I did exactly as directed, by opening the keyring app, then selecting the default keyring with a right click, followed by changing the password / leaving both password fields blank, closing the application, and finally testing with a reboot if the web browsers are now working without the unlocking keyring request .... which they did.

.

Posted: **Fri Dec 27, 2024 3:59 am**

germany wrote: Fri Dec 27, 2024 2:08 am
fehlix wrote: Wed Dec 25, 2024 8:30 am You missed the point, reporting the steps done would have helped me to see what you have done,
in order to get a clear picture of the issue.
I did exactly as directed, by opening the keyring app, then selecting the default keyring with a right click, followed by changing the password / leaving both password fields blank, closing the application, and finally testing with a reboot if the web browsers are now working without the unlocking keyring request .... which they did.

That's not really what I do recommend:
Leaving the keyring with an unprotected empty password open, is a security issue,
b/c any bad websites, which are smart enough, can now read any "secretes" googl's chromium would rather protect from not getting stolen.
But to each his own. Not my recommendation, b/c of a potetial security risk.
My recommendation is to keep a password for both login and defaul keyring.
and do disable autologin. So that at login the keyring and the default keyring (if separate) get unlocked,
and stays protected.

Posted: **Fri Dec 27, 2024 4:19 am**

Well security is in the eye of the beholder. Nobody but nobody gets into our house to touch our computers. We use password programs for all of our passwords and our passwords are generally between 15 und 25 characters long with special characters etc. We do not ever use phone apps to sync anything with our computers either. So from our point of view, the security that we actually require for our machines is minimal at best. We also do not use WiFi unless we absolutely have to. Everything is done with much more secure LAN cables. What needs to be protected is protected and we're not in the habit of using web browsers for password storage. So yes, you're right, to each their own .... as per what each user needs.

Posted: **Fri Dec 27, 2024 4:39 am**

They have your session, don't need your password.

Posted: **Fri Dec 27, 2024 5:41 am**

How do they get into the session in the first place? Access must be created first and hacking into hardware LAN is almost impossible.

MX Linux Forum

Gnome-keyring - unlocked

Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked[SOLVED]

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked[SOLVED]

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked

Re: Gnome-keyring - unlocked