2

I am trying to store some environment variables for S3 in an encrypted shell script (so these keys aren't stored unencrypted on my drive) like so:

export AWS_ACCESS_KEY_ID="example_key_id"
export AWS_SECRET_ACCESS_KEY="example_secret_access_key"

This is saved as a shell script setenv.sh which I've encrypted as setenv.sh.gpg.

I'm trying to run the file script with eval $(gpg --decrypt ./setenv.sh.gpg) which decrypts the file, but does not load the environment variables accordingly (a printenv confirms this).

I feel like it may have something to do with this question: Shell script to set environment variables

However, I've tried a number of different variations with source to no avail as I assume source expects a file and not the contents of a script.

How could I use a gpg encrypted shell script to set environment variables?

Community
  • 1
  • 1
waffl
  • 5,179
  • 10
  • 73
  • 123
  • [Process substitution](http://www.gnu.org/software/bash/manual/bash.html#Process-Substitution) in Bash might do it; is that available in Zsh? `source <( gpg --decrypt ./setenv.sh.gpg )`. Is the security so obtained illusory? What's to stop your user running the GPG command and seeing the output? – Jonathan Leffler Apr 05 '15 at 14:28
  • The reason I was thinking of setting up the script like this is so I can load different S3 keys for different projects without having to manually enter them each time. Security-wise, I thought this would be a good idea in case my laptop was stolen or compromised. (I have full disk encryption, but it could also be stolen while unlocked etc) – waffl Apr 06 '15 at 08:20
  • I think it qualifies as 'security through obscurity', but as long as you recognize that, and realize its limitations, no great harm is done. In particular, you should not, in my opinion, be relying on this to keep everything secure. – Jonathan Leffler Apr 06 '15 at 13:38

2 Answers2

2

As the first commenter says source <(gpg --decrypt ./setenv.sh.gpg) will accomplish what you're after. It should work in Zsh as well as bash.

N.B. Zsh also has =(...) for process substitution, but this will leave an unencrypted temp file lying around somewhere which defeats the purpose of using encryption. Stick to <(...) which uses a named pipe.

If the goal is to protect the credentials from the user using them, then this is futile. If on the other hand, you want to protect the credentials in the event your laptop gets stolen then there is some real protection here. It's a fairly common strategy to keep credentials encrypted on disk and load them into memory only when needed.

Given that your hard drive is encrypted, I'm not sure how much you'll gain from this. The only realistic benefit I can think of off the top of my head is if you keep unencrypted backups and they get stolen. Depending on how paranoid you are, it might or might not be worth the trouble.

manman
  • 4,743
  • 3
  • 30
  • 42
ouden
  • 86
  • 3
  • For some reason, running this echoes a few lines stating it needs a passphrase for the gpg decrypt but never offers a prompt to enter the password? I can't even ctrl+c out back to the shell. – waffl Apr 07 '15 at 13:12
  • Oddly enough, it works in bash, but not zsh, even when completely removing my `.zshrc` profile temporarily – waffl Apr 07 '15 at 13:57
  • I think you need to use `.` instead of `source` with zsh – RobinGower Jun 20 '19 at 16:02
0

In Zsh, you should just be able to call:

$(gpg --decrypt ./setenv.sh.gpg)

Or pop that line in a script then call that with . e.g.:

. decrypt-and-setenv.sh

This exports the env vars into your current shell and leaves the file encrypted.

RobinGower
  • 928
  • 6
  • 14