sudo or ssh

[TMcB]

Hi everyone - i'm looking for some advice

I have one server, and I would like user b to start a program in user b's crontab without having to enter a password. (this program is owned by user a)

I know SUDO would do this, but I've also seen postings on the forum which recommend ssh.

Could anyone advise me which would be the most secure - sudo or ssh.
Are there any major advantages / disadvantages to either.
Thanks

[Doug O'Leary]

Hey;

Maybe I'm missing something but why would you need either? As long as user b has access to user a's program, he can simply execute it in the same way that user b can run ls (owned by bin:bin)

Unless you want user b to execute the script AS user a in b's crontab? Assuming that's the case, my suggestion would be to use ssh.

sudo would work; however, you'd have to use the nopassword option. My personal opinion is that this option should never be used. If someone comes across an open terminal logged in as user b, they can run whatever is configured in sudo with no authentication whatsoever.

ssh with publich key authentication is 2-factor authentication which is more secure because you have to have something (the private key) and know something (the passphrase) vs just knowing something (user b's password).

Now, that being said, in order to use ssh/pka via cron, you have to configure the keys to have a null pass-phrase which effectively nullifies one of the two authentication factors. Whenever I do this, though, I use an alternate identity such that the user must execute

ssh -i ${abs_path_to_null_key} ${host} ${command}

instead of simply

ssh ${host} ${command}

This provides a least a little more security in that the black hat would have to get access to an open terminal and know about and use the alternate identity to access the other system/account.

Just to provide some balance: sudo is easier to configure. So, while ssh/pka will null pass-phrased keys, if correctly implemented, is a more secure, sudo is easier to configure. Fairly typical trade off between security and usability.

HTH;

Doug

[TMcB]

Thanks Doug, thats what i suspected.

As far as the null passphrase goes, is it not possible to do anything with the ssh-agent in the cron job?

Also, can you explain what you mean about using an alterantive identity.

Cheers

[Doug O'Leary · Accepted solution]

>>As far as the null passphrase goes, is it not possible to do anything with the ssh-agent in the cron job?

That's possible, but I've had mixed results doing it. Since cron doesn't start with an environment, you'd have to source in an environment file that has the information. Additionally, there's the issue of the agent not running, key not in the agent, etc,etc. Radically increases the complexity of the script due to the requirement to check for all these conditions.

null passphrased keys circumvent all these issues but at the expense of reduced security.

>>Also, can you explain what you mean about using an alterantive identity.

Each key pair defines an identity. The standard "identities" are id_dsa and id_rsa. You can create alternate key pairs (identities) by specifying a different file name in the ssh-keygen dialogue or via cli args:

ssh-keygen -t dsa -f ./ego -P ""

generates ./ego and ./ego.pub with a null passphrase. Append ego.pub to the appropriate authorized_keys file and you will then be able to:

ssh -i ./ego ${host} ${command}

w/o being asked for a passphrase or a password. NOTE: the argument to -i will usually end up being an absolute path name.

Just to reiterate: Using null passphrased keys eliminates one of the two factors of authentication that make PKA such a good deal. The only valid use for these is for situations such as what you're describing.

HTH;

Doug

[TMcB]

Thanks Doug
Youve cleared things up!