77
submitted 1 year ago* (last edited 1 year ago) by csm10495@sh.itjust.works to c/selfhosted@lemmy.world

Say you have a script or something that gets run in cron/task scheduler and it needs a password.. say to ssh to a raspberry pi elsewhere in your house.

How do you save that password in a way that automation can access it?

Some ideas:

  • Plaintext file. Not a fan because its sitting unencrypted on the box somewhere.
  • Environment variable. Not a fan because its still unencrypted somewhere to someone on the box (albeit likely the same user or an admin).
  • A secrets manager. If I use something locally like hashicorp vault or infisical, I can get to a point where a cli/api call gets the password. Though in this case I still need a vault password/secret to get my password. So I fall back to needing one of the above to get this to work.

If the secrets manager is easily available, the secret to get into the secrets manager is available as well leading to a feeling of security by obscurity.

If someone breaks into my system via SSH/etc. then they can get the passwords either way.

.. How do people normally do this? I'm not sure I actually get anything out of a secrets manager if its local and I have the disk itself encrypted before login.

What actually makes sense at a personal/home scale?

(Edit: I know using SSH key probably is better for getting to the raspberry pi, but still the question is the same idea).

you are viewing a single comment's thread
view the rest of the comments
[-] BigDev@lemmy.world 1 points 1 year ago* (last edited 1 year ago)

Yes, there has to be a minimal level of trust between the server and devices/users. You're level of security defines what point the computer decides "yep, that's good enough, I can trust this is the real user accessing me." A true, perfectly secure system has no access, it's a black box that nothing can interact with, because it can only trust itself.

At some point you have to trust yourself not to mess up too bad, you are the weak point in security, since I'm assuming you're the only one who's accessing the system right now.

I personally use plaintext password files, with appropriately managed permissions (only the owner can see or read the file.) As long as the user login is secure, and root/admin access is secure, I feel comfortable that no one but me can access the credentials. To manage remote access to the system, I use hardware (YubiKey) to store my SSH keys, with a PIN code lock that wipes the keys if entered incorrectly 5 times. I don't have any government agencies coming after me (as far as i know) so no one has a practical way to extract the keys if the device were stolen off me, and the PIN retry limit prevents brute forcing. I trust myself to manage these hardware keys appropriately.

*Edit: to add to the "appropriately managed" bit there, each sub system (home automation, file server, media hosting, etc) should be properly containerized or isolated (using different user accounts) so that if one service is compromised, the others are still somewhat protected. *

Physical access to your server is endgame. If an attacker can physically mess with your system, you've lost, and that can only be fixed externally with home security improvements. A skilled attacker doesn't need your ssh tokens to gain access if they can plug a keyboard into the server itself. I've also seen a demo of a neat little kit the feds use to seamlessly move a computer power cord from the wall to a portable battery pack, so they can simply walk out, with the device still powered up, and do what they want to it back at home base (it's used mainly for raids on various computer fraudsters, but still, it exists, and can be used on you). I trust myself not to do stupid stuff that gets me targeted by a hacker group, or raided by the FBI.

Something less targeted, like a burglary (not focused on your server), can be protected against by disk encryption. I don't use any disk encryption, but I probably should. I like the idea other user's wrote down here, of using a TPM module to store disk encryption keys, so it can detect if the hardware or OS changed between boots and deny decryption. I'd also take it one step further and encrypt the data/password files with an encryption method that requires someone to log in and type a password, that way if someone were to steal the device and power it up elsewhere, the passwords are still safe until you OK it, essentially authorizing unexpected reboots, at the cost of having to log into the server every time it starts (not fun if you're doing maintenance.) if you do this bit right, you don't have to trust yourself to do anything but remember the password.

Sorry about the length there, but security and access management is a complicated topic, so it requires a lot of talking. Hopefully it helped!

[-] csm10495@sh.itjust.works 1 points 1 year ago

I think you hit the nail on the head with the true security being black box. The moment I need access, I'm making a hole.

this post was submitted on 16 Jul 2023
77 points (98.7% liked)

Selfhosted

39677 readers
199 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago
MODERATORS