Comments on: sshpass - Non-interactive ssh password authentication

By: ML

ML — Tue, 20 Sep 2011 17:33:36 +0000

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.

By: Brett

Brett — Tue, 20 Sep 2011 15:23:20 +0000

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.

By: Anon

Anon — Sat, 06 Aug 2011 03:37:16 +0000

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.

By: Jeff Sadowski

Jeff Sadowski — Thu, 04 Aug 2011 17:30:43 +0000

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.

By: Jeff Sadowski

Jeff Sadowski — Thu, 04 Aug 2011 16:35:52 +0000

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).

By: Harry Hartynger

Harry Hartynger — Thu, 12 May 2011 11:11:37 +0000

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

By: Nick

Nick — Wed, 19 May 2010 16:50:13 +0000

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.

By: TK

TK — Tue, 01 Dec 2009 17:38:17 +0000

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.

By: jmm

jmm — Fri, 26 Jun 2009 05:05:37 +0000

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.

By: John

John — Fri, 17 Apr 2009 10:19:37 +0000

Drink, thanks. you saved a lot of time for me.

By: Shachar Shemesh

Shachar Shemesh — Tue, 14 Oct 2008 09:18:04 +0000

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

By: Drink

Drink — Wed, 10 Sep 2008 07:43:21 +0000

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

By: Paul

Paul — Tue, 20 May 2008 19:06:40 +0000

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.

By: Karl O. Pinc

Karl O. Pinc — Sat, 10 May 2008 06:41:53 +0000

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?

By: Noisome

Noisome — Mon, 05 May 2008 14:14:33 +0000

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

By: Tad Marko

Tad Marko — Mon, 05 May 2008 12:57:11 +0000

Also, note that you can accomplish a more secure version of this using SSH key pairs as James Harr said in conjunction with keychain.

By: Will

Will — Mon, 05 May 2008 10:04:01 +0000

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.

By: James Harr

James Harr — Sun, 06 Apr 2008 17:28:32 +0000

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.