keyring best practices with systemd

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












4















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?










share|improve this question






















  • Note that ssh-agent and keychain are for SSH keys only, gpg-agent can be used for GPG keys and optionally also for SSH keys, gnome-keyring and kwallet aim to be generic password/key/secret management systems for Gnome and KDE desktop environments respectively, and keyctl is for kernel-level key management which can be used for various purposes, including kernel module authentication to conform to Secure boot requirements. In other words, most of these are completely separate systems; among those listed, only gnome-keyring and kwallet are fully general-purpose.

    – telcoM
    Feb 2 at 11:11















4















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?










share|improve this question






















  • Note that ssh-agent and keychain are for SSH keys only, gpg-agent can be used for GPG keys and optionally also for SSH keys, gnome-keyring and kwallet aim to be generic password/key/secret management systems for Gnome and KDE desktop environments respectively, and keyctl is for kernel-level key management which can be used for various purposes, including kernel module authentication to conform to Secure boot requirements. In other words, most of these are completely separate systems; among those listed, only gnome-keyring and kwallet are fully general-purpose.

    – telcoM
    Feb 2 at 11:11













4












4








4


1






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?










share|improve this question














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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Jun 1 '15 at 10:46









godgod

9418




9418












  • Note that ssh-agent and keychain are for SSH keys only, gpg-agent can be used for GPG keys and optionally also for SSH keys, gnome-keyring and kwallet aim to be generic password/key/secret management systems for Gnome and KDE desktop environments respectively, and keyctl is for kernel-level key management which can be used for various purposes, including kernel module authentication to conform to Secure boot requirements. In other words, most of these are completely separate systems; among those listed, only gnome-keyring and kwallet are fully general-purpose.

    – telcoM
    Feb 2 at 11:11

















  • Note that ssh-agent and keychain are for SSH keys only, gpg-agent can be used for GPG keys and optionally also for SSH keys, gnome-keyring and kwallet aim to be generic password/key/secret management systems for Gnome and KDE desktop environments respectively, and keyctl is for kernel-level key management which can be used for various purposes, including kernel module authentication to conform to Secure boot requirements. In other words, most of these are completely separate systems; among those listed, only gnome-keyring and kwallet are fully general-purpose.

    – telcoM
    Feb 2 at 11:11
















Note that ssh-agent and keychain are for SSH keys only, gpg-agent can be used for GPG keys and optionally also for SSH keys, gnome-keyring and kwallet aim to be generic password/key/secret management systems for Gnome and KDE desktop environments respectively, and keyctl is for kernel-level key management which can be used for various purposes, including kernel module authentication to conform to Secure boot requirements. In other words, most of these are completely separate systems; among those listed, only gnome-keyring and kwallet are fully general-purpose.

– telcoM
Feb 2 at 11:11





Note that ssh-agent and keychain are for SSH keys only, gpg-agent can be used for GPG keys and optionally also for SSH keys, gnome-keyring and kwallet aim to be generic password/key/secret management systems for Gnome and KDE desktop environments respectively, and keyctl is for kernel-level key management which can be used for various purposes, including kernel module authentication to conform to Secure boot requirements. In other words, most of these are completely separate systems; among those listed, only gnome-keyring and kwallet are fully general-purpose.

– telcoM
Feb 2 at 11:11










1 Answer
1






active

oldest

votes


















0














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






share|improve this answer






















    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
    );



    );













    draft saved

    draft discarded


















    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









    0














    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






    share|improve this answer



























      0














      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






      share|improve this answer

























        0












        0








        0







        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






        share|improve this answer













        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







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Dec 6 '17 at 10:57









        BigonBigon

        1,267713




        1,267713



























            draft saved

            draft discarded
















































            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.




            draft saved


            draft discarded














            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





















































            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






            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Bahrain

            Postfix configuration issue with fips on centos 7; mailgun relay