I need to write a shell script that will login to the linux servers that have key pair and pass phrase both.
Any lead would be appreciated.
In my opinion in this scenario the use of a pass phrase for a key doesn't make sense. Because you have to put it somewhere in the script file more or less plain text. Then the pass phrase is not secure and from my perspective the whole key is compromised (more or less).
Maybe there's a way by using ssh-agent and register the keys to the agent.
Configuring a server with both a keypair and a password really isn't recommended (or any configuration where one has to store a passphrase on disk, for that matter).
Having said that, sshpass would probably do what you want. I assume you already know how and where to keep your keyfiles.
Related
I have a shell script that starts a For loop, reads from a text file with hostnames, and uses SCP to transfer files to each host. It's been very useful but what is the best way to deal with the password prompt? The only authentication I was given to the servers were a username and password.
As of now, I've had to input my password for each server. It's been duoable since the server count is low but I'd like to have a better solution in the future. Any help/suggestions would be great.
Thanks!
Most servers also support publickey authentication. Generate a keypair on your local host, then copy the ~/.ssh/id_rsa_pub to remote host's ~/.ssh/authorized_keys (or append to it if it already exists). Deal with the keyphrase locking your secret key by using ssh-agent.
For this kind of interactive action you can use Expect scripts. You can easily define a remote call where you expect for a especific string (f.e "username:") and then send the known password.
I configured msmtp with my gmail account.
I obviously want to avoid writing my password in plaintext format in the config file.
Luckily enough msmtp offer the option passwordeval which can be used to obtain the password from the output of an an executable.
The question is: how should I use it?
I found here the following suggestion:
passwordeval gpg -d /some/path/to/.msmtp.password.gpg
That doesn't make much sense to me: if someone is able to access my config file he will certainly manage to run such a command and obtain the password from gpg.
So I believe I'm left with the only option of obfuscating the password within the binary executable even if I read almost everywhere that this is bad!
My impossible-to-hack implementation is: if the sendmail process is running output the correct pass, otherwise give a fake pass.
Your suggestions?
Other (more secure) tricks different from storing the pass in the binary file?
From Sukima's comment:
The reason gpg -d works is because it requires the private key of the person the file is encrypted to. So just placing that encrypted file in the public it is still encrypted an only one person (the one with the secret key) can decrypt it. It is assumed that the secret key is locked up on the user's machine and not leaked. It also assumes that they have not setup any agents which cache the unlock password while a hacker has direct access to the same machine. All of which is highly unlikely in 99% of all attacks.
There is not a standard solution on how to save credentials with the constraint of
having to use the credentials in plain text later
and in an unattended way
on a system which is not completely controlled by you (if it is you just set appropriate rights on the files holding the secrets)
You have several solutions, none solves perfectly your problem:
encrypt your credentials in a symmetric way: you need to input the key to decrypt them
encrypt in an asymmetric way: you need to provide your private key, which must be stored somewhere (unattended approach) or keyed in
obfuscate: as you mention, this only protects from some population
get it from somewhere else - you need to identify a way or another your system
You need to take into account which risk is acceptable and go from there.
My script is going to use WMI to connect to remote systems and I was looking at this post on how to go about doing so. It looks like I may need to pass in the username and password.
I am executing my script on remote systems with a Java program that runs it and parses the STDIN output.
Is it safe to pass in a password as a variable?
From the Java side the password will be in a property file (or a different method -- I'm not yet sure the best way to go about that, but its a different story) and I'll pass it in when I call the script.
never ever send passwords in plain. Use always a one way hash algorithm like MD5 to encrypt the password entered by a user.
Further never save a password as plain text anywhere. Always store the hash and compare this with the hashed input of the user.
Some articles to start with VBScript:
Is there a method to encrypt passwords stored in a VBS
Encrypting/Hashing plain text passwords in database
http://www.edugeek.net/forums/coding/6951-masking-password-inputbox-vbscript.html
http://social.technet.microsoft.com/Forums/scriptcenter/en-US/1d132da1-2014-4f34-87f5-d787e764995f/save-encrypted-password-in-vbscript
If you are worried about sending the password in plaintext via network for a WMI request:
This link says that if you have Kerberos authentication in use, password/username
cannot be intercepted on the network.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa393720(v=vs.85).aspx
Check if this helps you out.
If you are worried about saving the password on the machine (which you want use for a WMI request):
Encrypt it and store in some db/file, decrypt it whenever you want to send it across
And yes, you should use existing standard encryption mechanisms.
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:)
Hi I am accessing a repository through a URL of type svn+ssh://
Reading the following quote from SVN and SSH from Adobe I am a little confused
"Before you configure Subversion or Dreamweaver for SVN+SSH, create an RSA key pair and configure the public key on the server. This public/private key pair is used to authenticate with the server, instead of storing and passing your password in plain text."
So if I just acces a repository by svn+ssh:// pe. from command line, my password is send in clear text ? I thought part of ssh was to encrypt the password, no ?
Maybe I was unclear, I have not generated any keypairs so use my password every time, does that change anything or is the quote written in confusing way ? Thank you.
Part of ssh is to encrypt everything, not just your password. So, your password would not be going over the wire in plain text.
SSH never sends passwords in plain text. However, non-SSH protocols such as svn:// may send the password in plain text. Adobe is recommending that users use SSH. Adobe also recommends that if SSH is used, then RSA key pairs are also used. Key pairs are easier because you don't have to keep typing your password for every operation (when used with an SSH agent).
There is no password at all in this case. All authentication happens based on key pair. One key is on your client machine, another one lies on the server. All traffic is also encrypted.