I have a server that requires certain credentials to boot up. Currently, the server reads a key-value pair file for these credentials. I'm looking for some component which can actually avoid the usage of key-value pair file.

The component should:

  • Cache the password in keyring
  • Start my server with proper credentials from keyring
  • Restart my server if it stops/killed

When initially starting or restarting this component, it is fine to prompt the user for the different passwords. But, it should not prompt if my server process restarts.

I was reading about watchdogs and systemd. Systemd unit files kind of fits my need but I couldn't find a way to store and retrieve the credentials in the keyring.

Update: I was also reading about systemd-ask-password to cache my password. But, it seems that it will cache the password only for 2.5 mins. I want to cache it till the unit is stopped/restarted.

Update 2: By server, I mean my server process. It is fine to prompt for passwords on a machine reboot.

  • Perhaps it is a typo, but you have "not prompt if my server restarts". Did you mean a particular Systemd unit (service)? Or did you intend something that persists across server reboots?
    – KevinO
    Nov 13, 2018 at 19:05
  • Yeah that was ambiguous. I corrected it. It's fine to prompt on system reboot. But, when my server systemd unit restarts, it shouldn't prompt the user for password.
    – SilleBille
    Nov 13, 2018 at 19:35

1 Answer 1


It seems systemd-ask-password does most of what you want, except for the expiration of the key, which is hardcoded at 2.5 minutes as you found out yourself:


One option is for you to build your own ask-password program, that stores it in the kernel keyring for a longer time period (or perhaps indefinitely.) You can maybe even use systemd-ask-password as a starting point for it. You could call such an agent from the ExecStartPre= in your unit. (Of course, one possible option is even to just build it into your main program itself, since it's going to access the keyring to fetch the password, it could prompt at that point if it's not found.)

Another option would be to propose a modification to systemd-ask-password in upstream systemd itself, keeping the 2.5 minute expiration by default, but introducing an additional command line argument to allow tweaking that expiration time, which would then make it usable for your particular use case.

  • the 1st option will require a maintainer. 2nd option seems feasible. Thanks for the tip. I am wondering what are adv/disadv of using keyctl command directly to store passwords in the keyring.
    – SilleBille
    Nov 14, 2018 at 17:30
  • I really recommend you file a detailed feature request with systemd, to get more feedback from the developers. It's quite possible that this will be well received and might be quite simple to implement. (Also, yours truly happens to be a maintainer of systemd.)
    – filbranden
    Nov 15, 2018 at 4:14
  • Yes, if you implement your password prompter in shell you'll likely end up using keyctl. I think implementing this in shell might be tricky (messing with terminal settings to hide the typed characters, etc., even calling keyctl without passing the password in an insecure way is a challenge!) A C implementation calling the APIs directly is more likely to be robust. But I don't know, maybe you'll end up finding that a shell script can get the job done! Hopefully that's the case...
    – filbranden
    Nov 15, 2018 at 4:16
  • do you mean myprogram ----> systemd -----> keyctl is a better way (and possibly robust) than myprogram ----> keyctl?
    – SilleBille
    Nov 15, 2018 at 16:34
  • I just meant using keyctl command from a script might be problematic if you're handling sensitive data such as credentials... You're better off using the C API for it. You need your program to access the kernel keyring directly, since it's being used to transfer the keys to your program...
    – filbranden
    Nov 15, 2018 at 18:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .