One approach would be to use the Expect module
to launch your telnet session. The whole purpose
of expect is to allow a your program to work interactively
with another program as if it were a user at a terminal.
Also you may want to consider using Net::Telnet.
It has built-in facilities for telnetting into a remote box
and passing the username and password properly. | [reply] |
I'd recommend setting up ssh on the machines if it isn't
already. It has a couple methods for letting you skip the
password prompt. Then, you can just run something like
system("ssh machine command");
Plus, you get the added bonus of not having to have your
password sent unencrypted over the line, as it is with
telnet. The same can be done with rsh, but it's not
recommended, as rsh is known to not be very secure. | [reply]
[d/l] |
ssh is also great in that you can avoid sending your passwords around in clear text across the network. You might not care about that, but if your network is at all exposed then you should.
| [reply] |
I can use rsh and ssh to move around the network. The program has a habit of bombing once I do so.
I have a feeling that this is because I have left the machine with the code,
but this is just a rookie's idea of what is going on.
| [reply] |
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 :) . | [reply]
[d/l] |
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] |
I posted some old code I wrote to mimic rexec. We needed it to massage some data before sending it to rexecd on another machine. You may find it useful. Look for it here. It may give you some ideas. | [reply] |
How are the machines password protected? Do you usually connect via telnet? If you use telnet, you could try the Expect Module (what was the exact name for that???), which can handle interactive sessions. Or, if you're using ssh or similar, you could generate host keys on the remote machine so you don't need to enter a password. | [reply] |