SSH’s (secure shell) most common authentication mode is called “interactive keyboard password authentication”, so called both because it is typically done via keyboard, and because openssh takes active measures to make sure that the password is, indeed, typed interactively by the keyboard. Sometimes, however, it is necessary to fool ssh into accepting an interactive password non-interactively. This is where sshpass comes in.
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]
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.
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.
Also, note that you can accomplish a more secure version of this using SSH key pairs as James Harr said in conjunction with keychain.
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
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?
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
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
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
Drink, thanks. you saved a lot of time for me.
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.
Imagine you need to access a computer behind a ‘login’ machine (or whatever would be the right name – firewall?). You can ssh into login and then ssh into the desired computer on the “other side” of the network. But, you’re not allowed to read/write anything on login – then you can’t use keys. The only solution is a program like this or an Expect script.
Pardon my informal writing, i’m not an admin, just a user.
There ARE reasons to do this. One that I use is with embedded development. I am using ssh tools only to move newer versions of software to the embedded device. Until release time, the password is something pointless like “easypass”, and I could care less if anyone can see the password running ps.
public key authentification might not always be available (virtual user accounts who end up in a shared login session of _one_ real system account)
Additionally in those scenarios you often have to face a password strategy which forces you to change your password every X days (often via some web interface before being able to log in) – clearly a policy like that won’t work if the user simply could bypass this requirement by using ssh-agent and public key authentification
I’m hoping that I can use this in scripts that I run from crontab (this is the trouble I had with expect scripts they needed a console) and connecting to older cisco routers (the cisco routers did not support key logins).
Works beautifully with older cisco routers just as I expected it to and I can run it from a crontab job.
Now I can have my linux machine automate some of the tasks I have needed to run on my cisco routers.
Thank you so much.
The right solution is to use this really complicated ssh-agent configuration, which requires an extra login password to start the ssh-agent, and a bunch of shell scripting. It consists of many parts each of which could break. Let’s be realistic people, no one is going to want to do the right thing. If we lived in the right world all men would be angels, there would be no government, and we’d all use Lisp.
sshpass is a lifesaver when dealing with LDAP-authenticated accounts on a Solaris server. The LDAP server won’t disclose any account details without a password, so passwords are still required even when public key authentication is set up properly.
The instance I am using this in is that we manage 500+ servers, and we can only make changes that are approved. I have to install an update to all of them, and we have no SSH key approval. Hence, this.
Yes, public key authentication is better, but not always available. For example, I have Draytek Vigor wifi-router with has ssh-server but I don’t know whether it supports public key authentication (and I almost sure that it does not). So sshpass is ideal soulution in this case. Thanks to author for this post!
Its about free software in a free world of free human beings. After considering all options choose the one you like best. There is no wrong or right for everybody the same.
Wrong, sshpass show zzzzzzz for the password with -p. It’s secure as any other.