Comments on: sshpass - Non-interactive ssh password authentication

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.