# How to avoid password prompt in shell script



## fred974 (Dec 4, 2013)

Hello everyone,

I normally use the following command to encrypt my file: `tar cfz - important_backups | openssl enc -aes-256-cbc -e > important_backups_encrypted.tar.gz`. I am now trying to write a script to encrypt my database backup but I haven't worked out how I can pass the password without user action. Could anyone help me please?

Thank you.

Fred


----------



## fonz (Dec 4, 2013)

Perhaps lang/expect can be of help?


----------



## SirDice (Dec 4, 2013)

Have a look at openssl(1):


> PASS PHRASE ARGUMENTS
> Several commands accept password arguments, typically using -passin and
> -passout for input and output passwords respectively. These allow the
> password to be obtained from a variety of sources. Both of these
> ...


----------



## fred974 (Dec 4, 2013)

Thank you all.

I finally manged to get it to work  Here is my solution: `tar cfz - important_backups | openssl enc -aes-256-cbc -e -pass file:crypt_key.txt > important_backups_encrypted.tar.gz`.

Please submit your version if you can improve on it.

Fred


----------



## ShelLuser (Dec 4, 2013)

Why rely on insecure passwords when we have options such as public key encryption available? 

My solution would be to rely on security/gnupg1 instead; set up a key trust structure and use it. You'll never have to specify passwords whenever you're encrypting data because you're using a specific (public) key. The only moment when passwords are required is whenever you need to decrypt the data because decryption is done by using the matching private key which is obviously protected.

I sometimes use this setup myself whenever I need to deal with sensitive data. I have a user account on all my servers (obviously) and all of them have a specific GPG key assigned for that particular server. For example:


```
smtp2:/home/peter $ gpg --list-keys SMTP
pub   2048R/C5AEAED9 2013-04-20 [expires: 2015-04-20]
uid                  FreeBSD administrator (SMTP server) <admin@xxx.com>
sub   2048R/9A9F45C0 2013-04-20 [expires: 2015-04-20]
```
Now, in my scenario I sometimes also backup sensitive data and in those cases I don't want the data to become available on other places but this particular server where it might be needed. Should I need the data elsewhere then I know what I need to make it available.

As you probably can understand I'm obviously not going to show any real usage here, so let's assume that /usr/ports/Mk contains secured data, specific for this SMTP server, and I need to make a secured backup:


```
smtp2:/home/peter $ tar czf - /usr/ports/Mk | gpg --encrypt --recipient SMTP > mk.tar.gz.enc
tar: Removing leading '/' from member names
smtp2:/home/peter $ file mk.tar.gz.enc
mk.tar.gz.enc: data
```
And I'm done. No messy passwords, no single point of security failure, no nothing. And the best part is that I can be sure that this data will only be accessible on this particular server (or any other location where I have this specific SMTP key available of course).

When I do need to access the data again it's pretty simple:


```
smtp2:/home/peter/temp $ gpg --decrypt ../mk.tar.gz.enc | tar xzf -
You need a passphrase to unlock the secret key for
user: "FreeBSD administrator (SMTP server) <admin@xxx.com>"
2048-bit RSA key, ID 9A9F45C0, created 2013-04-20 (main key ID C5AEAED9)

Enter passphrase:
gpg: encrypted with 2048-bit RSA key, ID 9A9F45C0, created 2013-04-20
      "FreeBSD administrator (SMTP server) <admin@xxx.com>"
smtp2:/home/peter/temp $ ls usr/ports/Mk/ | wc -l
      59
```
And there you go. No need for passwords in shell scripts. In fact; you could even opt to keep the secret key on a completely different environment and only have the several servers use the public key to encrypt said data. I use that scenario too at times whenever I have data which, when needed, will be made available using my backup server. For example; SQL data is something I'll never "just" import back into one of the main servers. So whenever I need to make a secured backup of that I simply use the public key of the backup server.

So basically I create a secured backup on a server and after I'm done that particular data won't be accessible on that server anymore. Simply because the server doesn't have the secret key.

In my opinion this is a much better solution than relying on passwords (but keep in mind that I'm a GPG nut ).


----------



## wblock@ (Dec 4, 2013)

Why security/gnupg1 instead of security/gnupg?


----------



## ShelLuser (Dec 5, 2013)

wblock@ said:
			
		

> Why security/gnupg1 instead of security/gnupg?


Security, and because it's better suited for server usage.

Basically security/gnupg1 (or GnuPG 1.4.15) is more or less a stand-alone program where encryption support is concerned whereas GnuPG 2.0.x (or security/gnupg) has a more modular approach. It also provides stuff such as the gpg-agent which is pretty much useless on a server (in my opinion anyway). Another issue is that partly because of the gpg-agent this port also has a lot more dependencies:


```
root@chihiro:/usr/ports/security/gnupg # make run-depends-list
/usr/ports/converters/libiconv
/usr/ports/devel/gettext
/usr/ports/devel/pth
/usr/ports/ftp/curl
/usr/ports/security/libassuan
/usr/ports/security/libgcrypt
/usr/ports/security/libgpg-error
/usr/ports/security/libksba
```

vs.


```
root@chihiro:/usr/ports/security/gnupg1 # make run-depends-list
/usr/ports/devel/gettext
/usr/ports/ftp/curl
```
Therefore I heavily prefer using security/gnupg1 on a server.


----------



## fred974 (Dec 5, 2013)

Cool solution 

It just worked. I've seen a way to do exactly that but using OpenSLL [probably OpenSSL -- mod.] 

To encrypt a passphrase with a public key: `openssl rsautl -encrypt -pubin -inkey key-public.pem < key.txt > enc.key.txt`. To decrypt an encrypted passphrase with a private key: `openssl rsautl -decrypt -inkey key.pem < enc.key.txt > key.txt`.

Hope these two solutions help someone.

Fred


----------

