Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a small bash script which downloads a critical file, opens an SFPT connection, puts the file and closes the connection.

As you can imagine, my script has some username and password information to it.

I plan on making those sensitive bits of information environment variables so incase we get hacked that information will not be exposed.

However, I wonder if:

  • the environment variables approach is the best solution
  • the variables will be permanent and survive server resets, crashes etc
  • if my environment variables will be visible to other terminal non-root users

Thanks for your input in advance ... happy new year.

share|improve this question
a ps can show the environment variables (and their value). choose a different approcah: create a public/private ssh key pair with no passphrase, which is ONLY redable by the user needing access. This user can use the key to copy things over using scp or the like. – Olivier Dulac Jan 7 '13 at 17:05
ps can only show the environment variables if you've got the same permission as the running process, at which point you've already lost. I'll accept that my use of "private" wasn't clear. – pjc50 Jan 7 '13 at 17:11
  • no env variables : ps can show you their values

  • use a private/public key pair (with no passphrase), ensure the private key is ONLY readable by the relevant persons (ie, the one launching the script that copies values over to the other machine), and put the public key in the destination machine's authorised_keys file (on the relevant user destination account, the one files are copied to). that local user then use its local only-it-can-read private key to be able to

    scp sensitivefile  destinationuser@destinationhost:/destination/path/

In addition:

  • make the localuser and destinationuser 2 very restricted users: they can only access this area locally, that area remotely, etc. That way, if compromised, they can't give root access remotely, or the like. And have a script locally and remotely that copy the files over to the final destination (the local readable-by-localuser area, and the remote final destination). Those scripts, of course, if possible, can't be root either... (imagine you get compromised: the file copy a script over to a location, so ends up as /local/area/somefile ... but someone maliciously put a link there, with the same local filename, that link pointing to some sensitive file: /local/area/somefile -> /etc/sensitivefile) that sensitive file could be overwritten! And in some conditinos that could open security holes or denial of services. And beware also remotely, as once compromised, localuser's key can be used to ssh/scp to destinationuser@destinationhost.

iow, there are many more checks to be done to ensure it will be difficult (and not impossible...) to be used to attack the local or destination host! Share your final solution with us.

share|improve this answer
Thank you for this detailed answer. My primary issue is I have limited expertise in following your steps so I will begin studying up on the steps to take(if you have good links to tutorials I would be grateful. Just to mention, I was considering creating a database table with the sensitive information encrypted in it. However, somewhere in code that information has to be de-crypted before being send to my Bash Script. In otherwords, should we get hacked all the ingredients still exist, however fragmented, for a hacker to capitalize on. – sisko Jan 8 '13 at 9:50
you may want to do it the other way: on the remote server, containing the critical data, create the public/private key pair, and have it retrieve the data from the "local" server. + some "sanity check" on the file's name (no weird characters, ex: aname";a command, potentially creating unwanted cmd in the script) and content (contains only the expected type of data, no extra binary/commands in it) and type (ie, should be a file, not a symlink). If the secure fetch from the insecure, the insecure doesn't have easy access to the secure, and the secure only shows its public key to the insecure. – Olivier Dulac Jan 8 '13 at 10:12

Environment variables are not permanent. They are private, though. Making them permanent would involve recording them in a script.

A better solution would be to use the ssh authorized_keys mechanism; the keys will still be stolen if the machine the originates the connection is compromised, but it's easier to de-authorize them at the other end.

share|improve this answer
they are not private: a ps can show you what variable are associated with each of the process that was launched (handy to find out the pwd, and scary if one of the variables contain a password) – Olivier Dulac Jan 7 '13 at 17:06

You must log in to answer this question.

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