First lets address your more important core question:
I'd like to be able to encode maintenance scripts to run on-demand remotely.
This sounds like a job for (trumpets sound) Automation Tools!
puppet springs immediately to mind, but there are many others.
You can also home-grow a system which uses passwordless SSH keys to log in to the remote systems and run commands on them, which is a time-honored way of doing this sort of stuff from the days before puppet and the like.
Now let's talk about your HTTP-based idea -- you came right out and said it:
I'm pretty certain this is a horribly bad idea: but out of interest how could this be secured?
and you're right: it is a horrible idea. DO NOT do this in a production environment, especially if the URL is accessible on the Big Bad Public Internet.
Allow me to enumerate the horror in grisly detail:
- You are using a pre-shared key (
mysecretwords). Anyone can shoulder-surf this (or guess it) and run commands.
- You are using security through obscurity ("Nobody will ever figure out that
https://myserver.com/script is the URL that lets you run stuff!").
- You are running commands as the web server user.
This is probably not what you want, which means the web server user will need to have some sort of elevated privileges - running as root, able to
- You are using a stateless protocol (http) to run commands which probably expect a terminal, login environment, etc. -- This can be done, but doing anything but the most trivial tasks means you'll have to hack up a back-end to maintain state.
- You are doing what
ssh is supposed to do.
Do not try to re-invent the wheel. I promise your oval wheel is not as good as the circle (
If you can't use traditional SSH there are many web-based SSH clients,and even more Java clients. Use one of those. You can even put them behind HTTP authorization (username/password, certificates, etc.)
As for how this can be secured - you've already done pretty much everything you can: The pre-shared key acts as authentication (combined username and password) and gives a layer of encryption, though it's not necessary.
https:// encrypts your data in transit and eliminates the chance of someone sniffing the magic URL (though not the chance of them deducing it themselves).
As long as your server only allows access to the magic URL over
https:// connections, and your SSL configuration on your web server is secure, you can't do much better.
Having said that, any effort you might put forth to make this more secure can't eliminate the fundamental flaws of what you're trying to do -- you may get away with it forever and never be compromised, but why add an attack surface you don't need when there are already tools that do what you want? (I might add that those tools have been written by experts, thoroughly vetted/tested by other experts, and are in wide use so if a security problem surfaces it gets fixed in a hurry...)