Telnet is not an encrypted protocol. Data, including login information, will be sent over the wire in the clear. Worse, in order to automate its use, you will have to store login information in a readable form for the program to use when it connects to remote systems. Maybe security isn't really an issue; maybe you are going to use this on an isolated test network. But, then again, maybe you should think about security right off the bat so you don't have to try to add it on when your boss decides that this tool would be useful on your production systems as well.

From reading CPAN telnet seems to give you a lot of functionality that may come in handy.

But, is that functionality necessary? And, how hard will it be to use?

You said that for the most part, you'll need to run a script on a remote machine and retrieve the output and exit status. So, for the most part, your requirements are met by the following two lines of Perl¹:

my $output = qx( ssh $remote_machine $command ); 
my $retval = $? >> 8;
[download]

Yes, that's it. And it doesn't even require any modules.

So, start with that and go from there. What other features do you need and how hard will the be to implement? Given that $command can be almost arbitrarily complex (though there may be some length limitations) and that you aren't restricted to a single ssh connection, there isn't much you wouldn't be able to do with this scheme. A variation on the theme that would solve limitations on command length: use scp to copy a temporary test script out to the remote machine and then use ssh to run it, gather the output, and then remove it.

So, why should anyone use Net::Telnet and/or Expect? There is, as far as I know, only one good reason: if you are required to automate an interactive process. I.e. if you must send commands to a program and the commands you send are dependent on the output you receive from earlier commands, then you'll need something like Expect. If you need to communicate with that interactive program via a TCP connection, that's what Net::Telnet is for. For example, if you want to create a bot for a MUD you frequent, Net::Telnet will certainly prove useful.

If you absolutely must interact with the shell on the remote machine, then you may actually need Net::Telnet. Given your requirements as you described them, however, I very much doubt that is the case. It seems that if you will require any interaction at all, it will most likely be across processes rather than within a single one.

Keep in mind that much of that "handy" functionality provided by Net::Telnet is really just there to help you get around its limitations and idiosyncracies. If you try to view your problem without considering interaction with the remote shell, you may find that those features aren't very "handy" at all.

Why would you recommend using ssh rather than telnet ?

In short: security and simplicity.

Good luck!

1. Assuming you've got things like your server, keys, and .shosts file configured correctly.

-sauoq
"My two cents aren't worth a dime.";