I agree with alexm, you should use ssh , otherwise any attempt to hide the password will be utterly useless (for example, the user and anyone else on the network could simply listen to the network traffic generated by your script and read the password that way).

Also, ssh gives you the possibility to execute only a specific script/command on the remote machine, via the "forced command" mechanism. You could generate an ssh keypair on the local machine, transfer the public part to the remote machine and assign it a script to execute. Your local script would then work without a password, but only enable the running of a single command on the remote server (which I think is what you're after).

I agree with the other posters that using telnet and sending passwords in the clear is certainly suboptimal... but I'd like to comment on the technique of making code 'execute-only', which is sometimes mentioned as an option in this context.

Generally, AFAIK, it's not possible (under Unix — not sure about Windows) to give anyone privileges to run a script, but not allow them to read the script source (without resorting to some SUID trickery, which might bring about its own set of other potential problems). Reason is that the script interpreter itself would always need to be able to read the source.

You can however have execute-only binary executables, which could provide low/moderate protection with respect to hiding sensitive information embedded in the code (in particular, when combined with obfuscation). I.e., the 'x' bit would be the only bit allowed for the intended users (e.g. -r-x--x--x or ---x--x--x), and the binary would be owned by someone else, so read-access is not possible for 'normal' users.

IOW, if you don't want people to pry on sensitive data, you could in principle wrap the script into a binary with its own embedded Perl interpreter (and with the script source embedded in the binary as well). Or create an XS module that you statically link with the Perl binary, which you then set execute-only...

BUT, don't be fooled into thinking this would be secure! It's not, it's just making things more difficult, depending on how well the users know the system. For example, one way to compromise the protection would be to have the binary load some modified shared library (e.g. the ubiquitous libc.so) via LD_LIBRARY_PATH, which then dumps the program image, or some such. You could of course counter that by static linking, but it shouldn't be too hard to come up with other ways...  (feel free to discuss, if you know of any)

Of course, any decent programmer will be able to get the keys out, but a casual office worker will be stymied. And you can remove the Tk stuff and run it from a commandline. The subs that do the obscuring/deobscuring are included.

zentara, Thanks a bunch. This is exactly what I was looking for, implemented and working well!!

Cheers,

JohnGG

Update: Looks like I may have misunderstood the question. I thought the requirement was to stop the password being echoed, not to hide it in the script. To do that (in a *nix environment) I'd place the password in a file owned by the process with rwx------ permissions under a directory with the same ownership and permissions so others couldn't browse, then read the file in the script.