In a shell script file I am using some commands like scp and make install which ask for my password.
I run a shell script to compile a big project, and after some time it asks for my password for using scp. I need to wait for that process and give the password after that.
I just want to do it all by shell script without interaction, so how can I avoid being prompted for the password here?
Short answer: DON'T
Use public key authentication for SCP and sudo with NOPASSWD directive for make install
If you can't use ssh trust and must enter the password later on in your script, use read -s -p "Password:" USER_PASSWORD to silently read in the password. You can then export USER_PASSWORD to an expect script, avoiding it being displayed in ps:
#!/usr/bin/expect -f
spawn scp some.file USER#otherhost:~
expect "assword:"
send -- "$env(USER_PASSWORD)\r"
expect eof
I think it's a better idea to generate an authentication key, and use this key based authentication instead of writing plain text passwords into your scripts.
No, you won't find any method to use SSH config files or a command line option to have a password hard coded and I'm sure this is by design.
If you environment makes this difficult, perhaps it would be helpful to know that the script can specify an identity file using the -i argument so you don't have to have a whole home directory setup or anything like that. There are other options that help use the key authentication that ssh really encourages over password authentication.
If you are using this across several users who you don't want to be bothered to create keys and copy them to the server, you could script that also. It wouldn't be hard to check for an existing key and do a quick test to see if you can make a connection with it. If you can't without a password, then you'd ssh-copy-id to the server asking for the ssh password that one time and at the beginning of the script so very little lag would occur between starting and running the script and it would be only once. You could even setup a separate key for each user for just the script in their own ~/.script/key/ directory so that you would discourage users access to the SSH server.
If you want to really restrict what can be done on the remote server by that user, you could use rssh as the shell on the remote account which will limit the user access to transferring files.
A good way we did this in the past to provide passwords to needed scripts when using key based authentication was impossible or needed to use passwords for apps, services, mysql, whatever...we stored passwords in an encrypted file and then decrypted this file at runtime to provide the password to the scripts.
The password decryption script, let's call it, yourcreds.rb, was restricted to root use only of course and the unencrypted passwords wern't stored anywhere. So for example you could run:
root#host:~# yourcreds.rb | grep mysql | awk {'print $3'}
Which without awk would for example output the stored line:
service | user | password | description | etc...
mysql mysqluser password ....
With yourcreds.rb (or whatever) you can output just the password and easily incorporate this method into scripts / cron jobs in larger or more complex environments.
Also if I remember correctly we didn't have to use grep / awk or anything. We just programmed in opts parse stuff like: yourcreds.rb list mysql or yourcreds.rb -l, etc.
We used blowfish and yamls to store the encrypted passwords. I'm sure you can be creative. Just make sure it's bullet proof to anyone but root.
Related
I am connecting from a UNIX server to a third party server (EFT on client side).
EFT supports only dual authentication.
So client has provided us the userid and password and we have shared the public key to them.
My shell script has to push and pull the files from third party.
I don't have expect, lftp, curl, sshpass in my server, cannot install then either.
How do I pass the password for the sftp command in the shell script to connect to remote server?
Now I am keying the password manually for the file transfer to happen, which is working.
But need to automate this.
Please advise.
If you really need a password authentication (in addition to the public key authentication), you cannot use vanilla OpenSSH ssh. It is purposefully built in a way not to allow automating password authentication.
Either you need to hack the password input for ssh using tools like expect and sshpass:
Automatically enter SSH password with script
How to run the sftp command with a password from Bash script?
(it seems that you know this);
Or use another SFTP client (it seems that you have none and you cannot install any);
That basically leaves you with implementing something. Either you will have to implement expect/sshpass equivalent. Or use your favourite programing language that is available on your server to implement the SFTP: Python/Perl/Ruby/PHP/C/C++. There are SFTP libraries for all of them.
My .passwd file contains 2 usernames and 2 passwords.
userNameX:$apr1$F3EFwwfP$W4gD4e/W98FerHQWDErfX0
userNameY:$apr1$Nq21ft8f$CRW4OdeRDVLsLnFwFaXyE0
They have been automatically generated by the old server just providing username and clear password.
Now I have just moved to the AWS Elastic Beanstalk, these two usernames/passwords work very well, but I would like to create more users and passwords. How should I do?
If you want to use htpasswd, look at htpasswd - Options.
There, you have the warning about password on the command line
-b
Use batch mode; i.e., get the password from the command line rather than prompting for it. This option should be used with extreme care, since the password is clearly visible on the command line. For script use see the -i option. Available in 2.4.4 and later.
And the recommended option -i:
-i
Read the password from stdin without verification (for script usage).
This way, you can pass the password through standard input through a pipe (e.g. popen).
You can also look at some authentication module, depending on the language and web framework you use.
I have a script that adds users to a linux system. I was intending to have a step that sets the root pw to a default but how can I do this without having that pw in cleartext in the script?
Take a look at usermod's option "-p" in the manpage:
-p, --password PASSWORD
The encrypted password, as returned by crypt(3).
Note: This option is not recommended because the password (or encrypted
password) will be visible by users listing the processes.
The password will be written in the local /etc/passwd or /etc/shadow file.
This might differ from the password database configured in your PAM
configuration. You should make sure the password respects the system's
password policy.
One way might be to have your script write the new user info to a file. Then, have another script (executed by root) which actually adds the new users using the useradd command. Perhaps the second script can be a cron job that runs every couple of minutes. It wouldn't be in real time, but I would feel better about the security of doing it this way, rather than having a root password in a public-facing script.
I have a remote server to which I login using ssh. Is there a way to be notified through email (using a bash script) when someone changes the user password using passwd including the new password?
I am guessing it has to do with /etc/pam/passwd, but not entirely sure what the trigger and flags should be.
This would be useful if for example I give my access to a "friend" and they decide to lock me out of my account. Of course I could create a new account for them etc, but this is more of a "it should be possible" task rather than a practical one.
First, a Dope Slap
There's a rule that this question reminds me of... What is it? Oh yeah...
NEVER SHARE YOUR PASSWORDS WITH ANYONE!
Which also goes well with the rule.
NEVER SEND SOMETHING SECRET THROUGH EMAIL!
Sorry for the shouting. There's a rule in security that the likelihood a secret will get out is the square of the number of people who know it. My corollary is:
if ( people_who_know_secret > 1 ) {
It ain't a secret any more
}
In Unix, even the system administrator, the all powerful root, doesn't know your password.
Even worse, you want to email your password. Email is far from secure. It's normally just plain text sent over the Aether where anyone who's a wee bit curious can peek at it.
Method One: Allowing Users to use SSH without Knowing Your Password
Since you're using SSH, you should know that SSH has an alternate mechanism for verifying a user called Private/Public keys. It varies from system to system, but what you do is create a public/private key pair. You share your public key with the system you want to log into, but keep your private key private.
Once the remote machine has your public key, you can log into that system via ssh without knowing the password of that system.
The exact mechanism varies from machine to machine and it doesn't help that there are two different ssh protocols, so getting it to work will vary from system to system. On Linux and Macs, you generate your public/private key pair through the ssh-keygen command.
By default, ssh-keygen will produce a file called $HOME/.ssh/id_rsa.pub and $HOME/.ssh/id_rsa. The first one is your public key. You run ssh-keygen on both your machine and the machine you want to log into.
On the machine you're logging into, create a file called $HOME/.ssh/authorized_keys, and copy and paste your public key into this file. Have your friend also send you his public key, and paste that into the file too. Each public key will take up one line in the file.
If everything works, both you and your friend can use ssh to log into that remote machine without being asked for a password. This is very secure since your public key has to match your corresponding private key. If it doesn't you can't log in. That means even if other popel find your public key, they won't be able to log into that remote system.
Both you and your friend can log into that system without worrying about sharing a password.
Method Two: A Better Solution: Using SUDO
The other way to do this is to use sudo to allow your friend to act as you in certain respects. Sudo has a few advantages over actually sharing the account:
All use of SUDO is logged, so you have traceability. If something goes wrong, you know who to blame.
You can limit what people can do as SUDO. For example, your friend has to run a particular command as you, and nothing else. In this case, you can specify in the /etc/sudoers file that your friend can only run that one particular command. You can even specify if your friend can simply run the command, or require your friend to enter their password in order to run that command.
On Ubuntu Linux and on Macintoshes, the root password is locked, so you cannot log in as root. If you need to do something as root, you set yourself up as an administrator (I believe by putting yourself in the wheel group) and then using sudo to run required administrator functions.
The big disadvantage of Sudo is that it's more complex to setup and requires administrator access on the machine.
Try setting up public/private keys using SSH. It might take some tweaking to get it to work, but once it works, it's beautiful. Even better, you can run remote commands and use sep to copy files from one machine to the other -- all without the password prompt. This means that you can write shell scripts to do your work for you.
By the way, a sneaky trick is to set your remote shell to /bin/false. That way, you can't log into that system -- even using ssh, but you can run remote commands using ssh and use sep to copy files back and forth between systems.
Personal passwords are only supposed to be known by the user themselves. Not even the root user is supposed to know them, which is why they are stored encrypted. Of course, the root user has sufficient access to decrypt them, but the principle is the same.
If you are giving your "friend" access, them assign them proper privileges! Do not make them a root user, and you shouldn't be a root user either. Then you're "friend" won't have access to change your password, let along muck about in areas they aren't supposed to be in.
If you absolutely must monitor the passwd and shadow files, install iwatch. Then set it to watch the /etc/passwd and /etc/shadow files. If they change, it runs a script that decrypts the file and emails someone. If you keep a copy to diff against, you'll even know who changed. You should probably also gpg the email, so that it does not go over the internet in plain text, since it has everyone's password in it. Please note that any other users on the system will be upset by the dystopian world they find themselves in.
Just because root is the law of the land does not mean we want to be living in 1984.
Try some kind of:
alias passwd='passwd && echo 'Alert! Alert! Alert!' | mail -s 'pass change' alert#example.com'
Should be enough for you:)
Another possible solutions for those, who think, that alias is too mainstream)) :
1) You could make a cron job, that will be checking your /etc/shadow file every, for example, minute, and when the file changes, it will send you an alert-email. The easiest way here, I think, will be making md5 checksum
2) You can move /usr/bin/passwd to /usr/bin/passwd.sys and make a script with /usr/bin/passwd.sys && echo 'Alert! Alert! Alert!' | mail -s 'pass change' on it's place. And yes, this way is also could be discovered be the user and scrubed round:)
I'm new to shellscripting (and not well traveled in the world of Linux) and are trying to get a shellscript to automaticly log into an sftp server with my given. Now this is how far I've gotten
#!/bin/bash
HOST='somehost.com'
USER='someusername'
PASSWD='somepass'
sftp $USER#$HOST
Now this is where I run into trouble. At this point I will be prompted for a password. So how do I get the script to automaticly reply with the password when prompted for it? I also tried finding a way to pass along the password with the sftp command, but with no luck. Can anyone help me figure this out?
Use this code:
#!/bin/bash
HOST='somehost.com'
USER='someusername'
PASSWD='somepass'
echo $PASSWD | sftp $USER#$HOST
It's not a good idea to include the password in a command line or such a script. Anyone who has access to the list of running processes could see your password, it could end up in your shell history and log files. So this would create a security hole.
There is more info in this thread where key based authentication is recommended over your proposed method.
Do not store passwords in script files, unless you are compulsive obsessive about keeping your permissions absolutely tight.
For all things ssh/sftp/scp, use public key authentication. Learn about the settings you can set on both the client and the server ends to make it more secure (ip restrictions, user restrictions, cipher restrictions, number of retries, number of simultaneous logins, etc) That alone should eliminate a lot of insecurity due to scripting issues.
If you absolutely must store a password in a variable, do not export it, and unset it the moment you get done using it.
on local host (where the script will be executed) generate ssh key pair:
scriptuser#scripthost:/~$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/michal/.ssh/id_rsa): {press ENTER!}
(...)
copy generated public key from scripthost to the somehost.com and append it to the list of authenticated hosts:
scriptuser#scripthost:/~$ cat ~/.ssh/id_rsa.pub | ssh someuser#somehost.com 'cat >> .ssh/authorized_keys'
now you should be able to use scp or sftp without password:
scriptuser#scripthost:/~$ scp /any/local/file someuser#somehost.com:/remote/location/
use sshpass command.
you can give password along with command