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.
Related
I'm writing a script that will scp some files without requiring a password from my local database to a remote database. Currently, I've set up ssh (following these directions: http://www.linuxproblem.org/art_9.html) and I'm able to use
scp /home/oracle/sendfiles/* myUsername#remoteServer:/home/oracle/receivefiles/
To send files over. However, this requires my script to have myUsername hard-coded for it to work. I'd like to be able to run
scp /home/oracle/sendfiles/* remoteServer:/home/oracle/receivefiles/
So that other users can use my script without having to specify their username. Is there a different way to set up ssh so I don't need to specify a username? Right now when I run my script without specifying my username it prompts me for oracle#remoteServer's password.
At the moment you seem to have run ssh-keygen as oracle on your local server, but added the contents of the locally-generated /home/oracle/.ssh/id_rsa.pub file to your own authorized_keys file - i.e. /home/myUsername/.ssh/authorized_keys - on the remote server.
From context I suspect you, and other users, log in to your local and remote boxes under your own accounts and then su to the oracle account. With the way you've set up the keys, any local user who can get to the oracle account on the local server now has access to your personal account on the remote server - which is not what you intended.
And although your first command specifying the remote user name works, the files on the remote end will be owned by you rather than oracle; which means the target directory /home/oracle/receivefiles/ must be at least group- and possibly world-writable. That may not be necessary, and generally isn't a good idea - opinions vary but home directories tend to be locked down as tightly as possible, particularly for sensitive accounts like that one. (You don't want someone who gains access to the server with low privs to be able to do something nasty by, say, editing Oracle's .profile or creating some new dot file which, for instance, deletes all the DB data files next time someone logs into that account...)
The contents of id_rsa.pub need to be added to /home/oracle/.ssh/authorized_keys on the remote server (and should be removed from /home/myUsername/.ssh/authorized_keys!). Once you've done that, you and anyone else that has su'd to oracle on the local server will be able to do:
scp -p /home/oracle/sendfiles/* remoteServer:/home/oracle/receivefiles/
without being prompted for a password, and the files at the remote end will be owned by oracle instead of you. (The -p flag means permissions and timestamps will be preserved too.)
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.
I have a windows bat which is called by the Windows task scheduler every 5 mins. In there I am connecting to a network drive, something like this
net use G: \hostname\shared mypassword /user:myuserid /persistent:yes
it works with no issue, but I don't want to put the password in the bat file as a plain txt. is there anyway to protect my password or put a encrypted password or store it somewhere safe in there to make it secure?
Use an environment variable.
Net use .... %password%
Then define the variable in the context which the batch runs. This is better than script source because the script is mobile, it can be copied from this machine to that, it can end up in the source control and so on. It is not more secure against a local host attack, i.e. If one user could see the password in the script it is also likely to find it in the environment.
There are more advanced solutions if you are willing to switch to PowerShell. https://social.technet.microsoft.com/wiki/contents/articles/4546.working-with-passwords-secure-strings-and-credentials-in-windows-powershell.aspx
You could use a Md5 generator (or hash code generator written by your own) to generate a password from any file in your computer. Whenever you run it, the batch file will generate the password from that specific file by the generator.
Your password is no longer in plain text, but hidden in generator and the corresponding file.
hope it helps.
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 using a build script that calls Wise to create some install files. The problem is that the Wise license only allows it to be run under one particular user account, which is not the same account that my build script will run under. I know Windows has the runas command but this won't work for an automated script as there is no way to enter the password via the command line.
This might help: Why doesn't the RunAs program accept a password on the command line?
I recommend taking a look at CPAU.
Command line tool for starting process
in alternate security context.
Basically this is a runas replacement.
Also allows you to create job files
and encode the id, password, and
command line in a file so it can be
used by normal users.
You can use it like this (examples):
CPAU -u user [-p password] -ex "WhatToRun" [switches]
Or you can create a ".job" file which will have the user and password encoded inside of it. This way you can avoid having to put the password for the user inside your build script.
It's a bit of a workaround solution, but you can create a scheduled task that runs as your user account, and have it run regularly, maybe once every minute. Yes, you'll have to wait for it to run then.
This task can then look for some data files to process, and do the real work only if they are there.
This might help, it's a class I've used in another project to let people make their own accounts; everyone had to have access to the program, but the same account couldn't be allowed to have access to the LDAP stuff, so the program uses this class to run it as a different user.
http://www.codeproject.com/KB/dotnet/UserImpersonationInNET.aspx