I'm writing a bash script that needs login credentials (username and password) to make an API call. The script will eventually become a cron job, so it's not feasible to prompt the user for login credentials. What is the best way to hide the credentials in a bash script?
If you can't set up restricted read permissions on the bash script itself (e.g. only root can read it), the usual approach is to use a separate file, with said restrictions (only root or a dedicated user can read it (chmod 400 filename)).
This is how you store your ssh keys in ~/.ssh/, as well.
If you are worried about someone having full access to your drive, e.g. someone stealing it, try cryptsetup/luks.
If you are worried about someone reading the unencrypted raw device, you might try breaking up the password, and assemble it in memory when needed...
SSHPASS=$_pass sshpass -e ssh -o StrictHostKeyChecking=no $_host
I use this bit for instance and prompt user input to a restricted file, a bit more security not actually passing the variable during SSH session, but instead defining as an env variable. Haven't had many concerns from my work place Security Engineers. You can always do as others stated and have that file already containing creds rather than prompting and do the same here.
Related
Hi I'm using makefile to do lots of compiling and remote works.
In many occasion I would need to type in username and password for remote connection, VPN, code upload and other stuffs.
May it be possible to use makefile to auto type in the credential information?
Thanks a lot!
It is not the role of make to do this kind of thing. So there is no special support in a Makefile for handling credentials.
However, if you can get a shell script to do the "auto-typing" or provide the required credentials some other way, then you should be able to use the same approach in a Makefile.
We can't advise you on how the script would work, because you have given no actual details of the commands etc that you are using for remote access.
But if you are using ssh from a Linux box, you could use public key authentication and ssh-agent and avoid the problem entirely. This would be a lot more secure than:
using user / password auth at all, and
embedding passwords in your makefiles ... for someone else to find when they steal your laptop or whatever.
I have a number of Unix Shell scripts that logon to SQLPLUS in a batch environment. In order to logon to SQLPLUS the user and password are currently available to the shell script in plain text from a text file. Not Good ! I need to change this so that the password is protected and possibly encrypted, but the shell script can pick up the password and decrpyt to use. I'm not really sure how I would go about achieving my objectives, other than I presume I need to write some shell script code that can be in a library and pulled into all my shell scripts as required. Any suggestions would be welcome.
Probably not what you want to hear.
Encrypting or otherwise obfuscating the password in your shell script does not provide any real security: only "security by obscurity" which isn't actually secure. This is a good reading about passwords in plaintext.
So in my opinion it would be best, that as less people as possible have access to the shell script.
IMHO best possible solution in this case something like HashiCorp Vault Vault
You are setting up Vault server in secure/audited network/host and store your password there (vault will encrypt it for you). Then you generating vault access token with rights to read db password. With Vault you have http(s) API which will give your secret if you have correct token (curl inside shell script). Examples: api documentation
It is not best solution but with this you centralizing your secrets storage, everything encrypted, you can audit and revoke access to your secrets. This is way better than db passwords in plaintext all over your infrastructure.
I have a situation where I need to give a bunch of administrators a command to run from a Windows command line that contains a password. There is no workaround for this application to avoid having a password on the command line.
For example:
c:>mycommand -P mypassword
I just want to give them an encrypted string that decrypts to "mycommand -P mypassword" and executes that command with its parameters without displaying the unencrypted text.
Say like this:
c:>mycommanddecoder efouhpefibhusdvn,iu3r3ksjdfdfbpisiegf
I've googled but results tend to come up with PGP command line utilities and the like.
I could just write a custom executable to do the job but that wouldn't stop a savvy operator from viewing the object code. I could encrypt it internally but then there would still be a visible key unless I used a certificate ... and you get the idea. It quickly becomes a mission!
Any thoughts?
Thanks,
Mark
Your problem is that in the end you want the script / program / command line to result in a system call that spawns the mycommand executive with the password as a parameter. And this syscall can be observed. Whatever you do beforehand you will not get around this attack point. You probably should look for a solution where the password never needs to be stored on the computer at all, maybe outsource the functionality into a service running somewhere else.
I'm working on a shell script where it zips up a file then uploads it to a server i have.
So far i have it so it asks for the server password and then keeps that variable. After it does that the script zips up a folder with a bunch of files in it. Then it dose the "scp" command to send it to my server.
Now, this is where i need help... I want it to fill in the password that was provided earlier in the script when it asks for the server password. I'm sure your asking "why doesn't just put in the password when the "scp" command asks for it. The reason being is that the file i have is going to be large, and i dont want to sit around and watch it zip up. So thats why i provide the password early on.
here are the steps:
1) user provides server password which is saved as the variable "password"
2) the script zips up the file
3) the script sends the file to the server (when i run this part in the script it asks for the password. i have to put in the password variable here.)
Any ideas on how to do this? thanks so much, will,
Step 1 is flawed, for several reasons, both security-related and technical.
What you should do is to create a "null" SSH session in the background that generates a master connection (see the ControlPath and ControlMaster options in the ssh_config(5) man page). Using the same control settings for the subsequent SCP operation will use this connection without having to ask for the password. Don't forget to kill the null session once the script is done.
I'd like to write a shell script that does something like the following
while read line; do
echo $line
done<input.txt | ssh > output.txt
This is a bit pseudo codey at the moment (the original is at work), but you should be able to tell what it's doing. For simple applications this works a treat, but ssh checks the input to see whether it's stdin is a terminal.
Is there a way to fool ssh into thinking that the contents of my piped loop are a terminal rather than a pipe?
EDIT : Sorry for not adding this originally, this is intended to allow ssh to log in via the shell script (answering the password prompt)
ssh -t -t will do what you want - this tells ssh to allocate a pseudo terminal no matter whether it is actually running in one.
Update
This problem (after updating your question and various comments, it became clear you are looking for a way to conveniently get public key encryption into place) could perhaps be solved by 'thinking upside down'.
Instead of trying very hard to get your clients public key onto a server that doesn't yet authenticate the client, you can try to receive an authenticated identity (private key) from that server.
Simple terms: generate a keypair on the server instead of the client, and then find a way to get the keypair on the client. The server can put the public key in it's authorized_keys in advance, so the client can connect right away.
Chances are that
the problem of getting the key across is more easily solved (you could even use a 'group' key for access from various clients)
if a less-secure mechanism is chosen (convenience over security) at least only the security of the client is reduced, not as-much that of the server (directly).
Original answer:
Short answer: Nope. (it would be a security hole for ssh, because ssh 'trusts' the tty for password entry, and the tty only)
Long answer, you could try to subvert/creatively use a terminal emulator (look at script/scriptreplay for inspiration).
Why would you want to do it?