views:

45

answers:

3

I found the following claim in the documentation for Net::OpenSSH:

Note that using password authentication in automated scripts is a very bad idea. When possible, you should use public key authentication instead.

What's flawed in using password authentication in automated scripts?

A: 

Probably because with password authentication, you have to hard code the password itself into the script or at least into some sort of configuration file. It's never a good idea to hard code your plain ssh password i think :)

Simone Margaritelli
But why is it worse than storing your private key on the hard disk?
codeholic
While you can put the private key into a secure part of the filesystem (setting appropriate file/dir permissions on it), with the plain password you cant, or at least it would be more complicated .
Simone Margaritelli
There's nothing complicated in setting permissions for your script or a configuration file, at least nothing more complicated than setting permissions for `.ssh` and `.ssh/id_rsa`
codeholic
Like MK said :"ssh won't work when the private key is not 600."
Simone Margaritelli
And I parried :)
codeholic
+2  A: 

Passwords are easier to guess/brute force than private keys (unless you are running Debian ;)

Imagine you have a user account which runs 120 different automated scripts. If you hardcode password into each of them you now have 120 places to change it.

If you place the password into a config file and have all 120 scripts read it from the file sooner or later somebody will accidentally make that file world readable. ssh won't work when the private key is not 600.

Somebody can decide to change user's password without thinking about the possibility of it being hardcoded in some script. You are more likely to stop and think before changing the private key.

MK
`ssh won't work when the private key is not 600.` - With password authentication you can check in your script if the config file is 600.`Somebody can decide to change user's password without thinking about the possibility of it being hardcoded in some script.` - Somebody can accidentally overwrite `.ssh/authorized_keys`
codeholic
You can't centrally enforce all people writing scripts to check the permissions, but you can disable the password authentication on your server and then you *know* that every script that accesses it does so using public/private key pair and doesn't have the password set to g0d in a world readable file. Part of security is about not trusting anybody, including yourself. And definitely the coworkers.
MK
Ok, that's clear. But I'd like to know, if there are any other advantages except that human factor stuff you mentioned. Technical advantages, if you wish.
codeholic
OK, here's a thought, but it's pretty ridiculous and I'm not even sure it is true: when doing password authentication ssh protocol needs to establish a private key using something like Diffie-Hellman key exchange before it can actually begin secure communications. With public/private key pair it is easier to establish a shared private key, so you save some processing power. Happy now? ;)
MK
Maybe :) I'll wait a couple of days and see if others say something else ;)
codeholic
@MK you are incorrect about the inner workings of SSH a private key will never be transmitted and the key pairs must be generated ahead of time. SSH does establish a shared secret using DH, but it is not a private key rather it is used for a symmetric cipher which is MUCH more efficient. Your answer is a partial truth, and Debian patched their random number generator a looooong time ago.
Rook
A: 

Public key authentication should always be preferred for any remote resource. It is statistically impossible to guess the challenge response and can thwart MITM attacks. Although this does not rule out the possibility of the attacker being extremely lucky.

If the attacker can read files on the remote system, the password or the private key must be in plain text and there for can be read. Asymmetric cryptography isn't a magic wand that solves all problems.

One possibility for this warning in the docs is that if you use a password and the script isn't checking the sshd's public key then a MITM attack could obtain the clear text password. You should be checking the remote servers authentication by hard-coding the public key. The ssh command on the cli does this automatically and will throw a warning if a server's key changes. If you aren't checking the authentication credentials of the remote server and you are using public key authentication then an attacker can only MITM that session because the attacker will not be able to obtain the client's private key to re-auth.

Rook