keyring best practices with systemd
There plenty of tools working with keyrings: ssh-agent, gpg-agent, gnome-keyring, kwallet, wrappers like keychain, keyctl talking to GNU/Linux kernel. There are various recommendation on how/when to start it tailored for different environments.
This make it rather confusing. I'm using modern GNU/Linux distro with systemd and I start my user session with systemd --user as well. I expect this setup to last decades so I wonder what's the best way to get keyring into picture?
The main use-case is to store passwords from chromium/firefox in one consolidated place.
Shall I start keychain from my user shell autostart script (I use fish for interactive and dash as login shells if that matters)? Right now "gnome-keyring-daemon --daemonize --login" is spawned via PAM. Shall I start "gnome-keyring --start" from user systemd unit? Is there some dbus service which would start some keyring daemon upon first request?
The list of questions go on but you get the idea - what is the right way to get keyring-as-a-service?
systemd gnome-keyring kwallet
bumped to the homepage by Community♦ 11 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
There plenty of tools working with keyrings: ssh-agent, gpg-agent, gnome-keyring, kwallet, wrappers like keychain, keyctl talking to GNU/Linux kernel. There are various recommendation on how/when to start it tailored for different environments.
This make it rather confusing. I'm using modern GNU/Linux distro with systemd and I start my user session with systemd --user as well. I expect this setup to last decades so I wonder what's the best way to get keyring into picture?
The main use-case is to store passwords from chromium/firefox in one consolidated place.
Shall I start keychain from my user shell autostart script (I use fish for interactive and dash as login shells if that matters)? Right now "gnome-keyring-daemon --daemonize --login" is spawned via PAM. Shall I start "gnome-keyring --start" from user systemd unit? Is there some dbus service which would start some keyring daemon upon first request?
The list of questions go on but you get the idea - what is the right way to get keyring-as-a-service?
systemd gnome-keyring kwallet
bumped to the homepage by Community♦ 11 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
There plenty of tools working with keyrings: ssh-agent, gpg-agent, gnome-keyring, kwallet, wrappers like keychain, keyctl talking to GNU/Linux kernel. There are various recommendation on how/when to start it tailored for different environments.
This make it rather confusing. I'm using modern GNU/Linux distro with systemd and I start my user session with systemd --user as well. I expect this setup to last decades so I wonder what's the best way to get keyring into picture?
The main use-case is to store passwords from chromium/firefox in one consolidated place.
Shall I start keychain from my user shell autostart script (I use fish for interactive and dash as login shells if that matters)? Right now "gnome-keyring-daemon --daemonize --login" is spawned via PAM. Shall I start "gnome-keyring --start" from user systemd unit? Is there some dbus service which would start some keyring daemon upon first request?
The list of questions go on but you get the idea - what is the right way to get keyring-as-a-service?
systemd gnome-keyring kwallet
There plenty of tools working with keyrings: ssh-agent, gpg-agent, gnome-keyring, kwallet, wrappers like keychain, keyctl talking to GNU/Linux kernel. There are various recommendation on how/when to start it tailored for different environments.
This make it rather confusing. I'm using modern GNU/Linux distro with systemd and I start my user session with systemd --user as well. I expect this setup to last decades so I wonder what's the best way to get keyring into picture?
The main use-case is to store passwords from chromium/firefox in one consolidated place.
Shall I start keychain from my user shell autostart script (I use fish for interactive and dash as login shells if that matters)? Right now "gnome-keyring-daemon --daemonize --login" is spawned via PAM. Shall I start "gnome-keyring --start" from user systemd unit? Is there some dbus service which would start some keyring daemon upon first request?
The list of questions go on but you get the idea - what is the right way to get keyring-as-a-service?
systemd gnome-keyring kwallet
systemd gnome-keyring kwallet
asked Jun 1 '15 at 10:46
godgod
9418
9418
bumped to the homepage by Community♦ 11 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
bumped to the homepage by Community♦ 11 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
On my machine (debian unstable) ssh-agent and gpg-agent have their own systemd user service/socket files. That means that they should be started when the user logs in or be activated when the first time an application is trying to access them.
Regarding gnome-keyring, there is (ATM?) no such systemd file and gnome-keyring is started both by PAM (as you mentioned) and by a .desktop
file located in /etc/xdg/autostart/
. The services located there should be started by your session manager (gnome-session, ...).
I see on debian a package called obsession
that contains a /usr/bin/xdg-autostart
I personally never used that tool, but that might help you to manually start the needed components if you are not using a session manager that supports XDG specification
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f206809%2fkeyring-best-practices-with-systemd%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
On my machine (debian unstable) ssh-agent and gpg-agent have their own systemd user service/socket files. That means that they should be started when the user logs in or be activated when the first time an application is trying to access them.
Regarding gnome-keyring, there is (ATM?) no such systemd file and gnome-keyring is started both by PAM (as you mentioned) and by a .desktop
file located in /etc/xdg/autostart/
. The services located there should be started by your session manager (gnome-session, ...).
I see on debian a package called obsession
that contains a /usr/bin/xdg-autostart
I personally never used that tool, but that might help you to manually start the needed components if you are not using a session manager that supports XDG specification
add a comment |
On my machine (debian unstable) ssh-agent and gpg-agent have their own systemd user service/socket files. That means that they should be started when the user logs in or be activated when the first time an application is trying to access them.
Regarding gnome-keyring, there is (ATM?) no such systemd file and gnome-keyring is started both by PAM (as you mentioned) and by a .desktop
file located in /etc/xdg/autostart/
. The services located there should be started by your session manager (gnome-session, ...).
I see on debian a package called obsession
that contains a /usr/bin/xdg-autostart
I personally never used that tool, but that might help you to manually start the needed components if you are not using a session manager that supports XDG specification
add a comment |
On my machine (debian unstable) ssh-agent and gpg-agent have their own systemd user service/socket files. That means that they should be started when the user logs in or be activated when the first time an application is trying to access them.
Regarding gnome-keyring, there is (ATM?) no such systemd file and gnome-keyring is started both by PAM (as you mentioned) and by a .desktop
file located in /etc/xdg/autostart/
. The services located there should be started by your session manager (gnome-session, ...).
I see on debian a package called obsession
that contains a /usr/bin/xdg-autostart
I personally never used that tool, but that might help you to manually start the needed components if you are not using a session manager that supports XDG specification
On my machine (debian unstable) ssh-agent and gpg-agent have their own systemd user service/socket files. That means that they should be started when the user logs in or be activated when the first time an application is trying to access them.
Regarding gnome-keyring, there is (ATM?) no such systemd file and gnome-keyring is started both by PAM (as you mentioned) and by a .desktop
file located in /etc/xdg/autostart/
. The services located there should be started by your session manager (gnome-session, ...).
I see on debian a package called obsession
that contains a /usr/bin/xdg-autostart
I personally never used that tool, but that might help you to manually start the needed components if you are not using a session manager that supports XDG specification
answered Dec 6 '17 at 10:57
BigonBigon
1,257713
1,257713
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f206809%2fkeyring-best-practices-with-systemd%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown