You'll have to clarify "better" and "cheesy" and "remote" to get any serious answers.
| [reply] |
Talk to a remote box. That's a pretty nebulous topic. Do you need to execute commands on a remote system? Do you need to transfer files? What OS is on each of the systems. Describe your situation in a lot more detail and someone may be able to point you in the right direction. | [reply] |
"talk to the other box remotely" isn't really helpful. What exactly would you like to accomplish here? Yes, SSH tunnels are nice (not cheesy at all, IMHO), but sometime overkill. Sometimes, a simple CGI script will help out too, or the Jabber protocol, or SMTP, or SNMP, it all depends on what you want 'the other box' to reply.
--
b10m
All code is usually tested, but rarely trusted.
| [reply] |
How do you want it to be better? Do you want to use less bandwidth? Do you want to start the script running and not have to keep a network connection open? Do you care if anyone else on the network can run the script? Do you care if people watching the network traffic are able to see something the script prints out? Are you tired of having to type in a password each time you run the script? Do you not like having to keep SSH keys on one of the machines for logging into the other?
Answers to the above questions indicate the mechanisms you should be using for running scripts on a remote machine.
I often use ssh with a password when I want to run the command manually.
For periodic cron jobs like backing up data I use ssh keys to keep the data encrypted and not require a login. (Just use rsync with --rsh=ssh.)
If I just wanted to grab the machine's load average and vital stats I would consider using a CGI because it doesn't require a login and I don't care if anyone sees the data. | [reply]
[d/l]
[select] |
| [reply] |
-- for saying SSH is cheesy. Check out [id://How (Not) To Ask A Question] | [reply] |
