sshpass – Non-interactive ssh password authentication
Posted by Admin on April 6th, 2008
If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!
SECURITY NOTE: There is a reason openssh insists that passwords be typed interactively. Passwords are harder to store securely and to pass around securely between programs. If you
Install sshpass in debian
#aptitude install sshpass
This will complete the installation
Using sshpass
Syntax
sshpass [options] command arguments
Options
If not option is given, sshpass reads the password from the standard input. The user may give at most one alternative source for the password:
-p password - The password is given on the command line. Please note the section titled “SECURITY CONSIDERATIONS”.
-f filename – The password is the first line of the file filename.
-d number – number is a file descriptor inherited by sshpass from the runner. The password is read from the open file descriptor.
-e – The password is taken from the environment variable “SSHPASS”.
Security Considerations
First and foremost, users of sshpass should realize that ssh’s insistance on only getting the password interactively is not without reason. It is close to impossible to securely store the password, and users of sshpass should consider whether ssh’s public key authentication provides the same end-user experience, while involving less hassle and being more secure.
The -p option should be considered the least secure of all of sshpass’s options. All system users can see the password in the command line with a simple “ps” command. Sshpass makes no attempt to hide the password, as such attempts create race conditions without actually solving the problem. Users of sshpass are encouraged to use one of the other password passing techniques, which are all more secure.
In particular, people writing programs that are meant to communicate the password programatically are encouraged to use an anonymous pipe and pass the pipe’s reading end to sshpass using the -d option.
sshpass Examples
1) Run rsync over SSH using password authentication, passing the password on the command line:
rsync –rsh=’sshpass -p 12345 ssh -l test’ host.example.com:path
2)sshpass -p [yourpassword] ssh [yourusername]@[host]
April 6th, 2008 at 6:28 pm
It should be noted that the use of a public/private key pair can achieve the same goal, but in a much more secure fashion.
http://linuxproblem.org/art_9.html
When you log in via ssh, the password is sent in plain-text though the encryption tunnel. This means that people watching the connection cannot see your password, however, if the server you are logging into is compromised, the server can see your password. This can be done simply by installing a rogue pam module. See pam_storepw here for more details: http://www.kernel.org/pub/linux/libs/pam/modules.html
For those seeking secure password solutions (without copying public keys around everywhere), you should probably read up on the Kerberos protocol a little bit. And note that most ssh + kerberos howtos implement the idea incorrectly if it does not involve the terms GSSAPI somewhere.
But yes, sshpass is a very nice tool for use in certain situations. I have used it in many. But, I thought I’d add the standard “insecure method” disclaimer.
May 5th, 2008 at 11:04 am
I completely agree with Mr. Harr. It would be much more better ( and simpler ) to setup public key authentication :
1. Generate key with ssh-keygen
2. Put the generated public key ( ~/.ssh/id_rsa.pub ) to the authorized_keys file in the target host ( ~/.ssh/authorized_keys )
That’s it ! Simple, effective, and more secure.
May 5th, 2008 at 1:57 pm
Also, note that you can accomplish a more secure version of this using SSH key pairs as James Harr said in conjunction with keychain.
May 5th, 2008 at 3:14 pm
To Will, Harr, Marko:
Those who want sshpass do not want to setup the public key. Most people know of that “solution” but in most instances where once is all that is needed or in testing environments where it is impractical to do setup public keys is where this shines. Imagine 64 machines doing a public-key on……every day. So please, note once of what is secure, but don’t disown that idea that this is a good solution for where it is needed.
Noisome
May 10th, 2008 at 7:41 am
Hi,
I’m having trouble imagining when sshpass is a good idea. If you’re “doing 64 machines doing a public-key on….every day” then there’s clearly an automated process involved. The public/private keypair can run without user interaction and can be added to the automation.
When there is no particular advantage to public/private keys vs. sshpass then public/private keys should be used, because you may as well use the solution that works in the most cases so as to minimize the number of different technologies you’re working with. In fact, “worse is better”, even if sshpass has a slight advantage your going to be better off using public/private keys. Under what circumstances does sshpass have a significant advantage? No doubt there are some, but I can’t think of any. Can you elaborate?
May 20th, 2008 at 8:06 pm
if you need to comply to the PCI-DSS standards for auditing, which means no automated key logins, yet you need to login to 100 machines to do sysadmin maintenance. Yes it sucks. Yes keys are better. no i have no choice.
See also: http://lostcompany.wunit.net/tech/dssh.html
September 10th, 2008 at 8:43 am
When you connect for first time (RSA key is not in your .ssh/known_hosts file), you get this:
The authenticity of host ’some_hostname (192.168…..)’ can’t be established
Are you sure you want to continue connecting (yes/no)?, and sshpass will hang.
Solution: use this ssh option: -o StrictHostKeyChecking=no:
ex: sshpass -p 1234 ssh -o StrictHostKeyChecking=no pw@some_hostname who
October 14th, 2008 at 10:18 am
As upstream and Debian maintainer, I should point out that had the package description not been truncated, the warning about only using sshpass if public key authentication is not an option would have been shown here again, possibly saving half the comments on this article
Then again, with people’s tendency not to read before they comment, maybe not.
Shachar
April 17th, 2009 at 10:19 am
Drink, thanks. you saved a lot of time for me.
June 26th, 2009 at 5:05 am
Everyone knows this is insecure, but not any less secure then having an sshd server listening on the internet on port 22 with password login, yet tons of people do so for simplicity sake. For low security situations sshpass blows trying to do this with expect out of the water. If this is not secure enough for your situation, I would hope you already know so or I bet you have been SOL for long time. Thanks for the great simple app.