in reply to Moving around with password protected machines.
The easiest way to use ssh to execute commands remotely, is to create a public/private key set (that has an empty password) and then distribute those keys appropriately on all the computers you need to share between.
Before I go any further, one should note that this reduces your LAN's security to the lowest denominator: If you have one insecure box, all boxes will be equally insecure.
However, the plus here is that using ssh to obtain password-less remote executing, instead of other methods, means that the ssh isn't itself going to make the boxes insecure.
Ok so here is what you do:
First make a pub/priv key pair:
ssh-keygen -b 1024 -N "" -C "equality" -f equal -q
(1024 bits, no password, comment="equality", filename = "equal" and "equal.pub", quiet)
Now, these two files need to be put onto all computers involved as ~/.ssh/identity and ~/.ssh/identity.pub respectively. Also copy equal.pub to the file ~/.ssh/authorized_keys (if this file already exists for some reason, append equal.pub to this file -- but it probably doesn't exist if you are reading this).
This is it, you are done. This is done on a per user@host basis, so each involved now can access each other without passwords using ssh. (This means user names do not need to be the same between each account as well, which is a nice plus).
The main caveat is this: the /etc/ssh_known_hosts and the ~/.ssh/known_hosts files, which list which hosts the computer "knows" (used to prevent spoof attacks). On some systems this will not be a problem, unknown hosts are added automatically to ~/.ssh/known_hosts, the first them they are seen.
However some systems are configured to prompt, or even refuse, the automatic addition of a host to the ~/.ssh/known_hosts. If this is the case you will need to just log in once manually between each computer that needs automation.
Of course, if you need all computers to talk to all other computers, that's O(N^2) manual logins, so I wouldn't suggest doing that then. If that's the case, then it would probably easier to, from one computer login to all other computers (including itself), which will generate the ~/.ssh/known_hosts file for you. You can then distributed this file to all other computers, with the same method you used to get the equal{,.pub} files onto all the systems.
There is also the .rhosts file which lists simply usernames and hosts that are allowed to connect. ssh will read this file, and since it is easy to create by hand, you can then distribute it to all involved computers as well. However I would strongly recommend against using this method, as it is highly insecure! (You might as well turn off server keys, this bypasses your spoof detection).
Well that's all I got,
Gryn
p.s. I would have posted sooner, but the site went down sometime in the middle of me writing this response :) .
RE: Setting up SSH to execute commands remotely (without passwords)
by mdillon (Priest) on Jul 07, 2000 at 07:44 UTC
|
even without taking the risk of leaving your private key
unprotected by a passphrase, it is possible to get
unattended logins using SSH with the public key method by
using the ssh_agent program.
ssh_agent allows you to leave your private key
encrypted on disk by prompting you for your passphrase when
run and keeping it in mlock'd memory (i think) to provide
to SSH whenever it is necessary to decrypt your private key
from disk. this is not considerably more secure than the
empty passphrase method while the ssh-agent has your
passphrase in memory, but it is equally secure to a plain
passphrase/private key login when the agent does not have
the passphrase in memory.
with this in consideration, many people run
ssh_agent from their .login or
.Xclients file to start it up as soon as they log
in. it takes their passphrase immediately and acts from then
on as if the private key is not protected (i.e. they are not
prompted every time they need to use the key, ssh_agent
supplies it instead). | [reply] |
|
|
Ah well you learn something new everyday.
ssh-agent sounds good for a lot of uses. However, I do not think it would buy much in what I'm guessing is Pearte's situation. He suggests that this will be most likely (and hopefully) run by a separate non-human userid. As long as you give that account the minimum security permissions (as you do with all of your accounts anyway, right? :) ), then ssh with empty password'ed keys should be as secure as you need.
But thanks mdillon for pointing that out!!! :)
Ciao,
Gryn
| [reply] |