Запуск произвольных, зашифрованных команд оболочки через http(s)?

Сначала давайте рассмотрим ваш более важный основной вопрос:

Я хотел бы иметь возможность кодировать сценарии обслуживания для удаленного запуска по требованию.

Это звучит как работа для (звука труб) инструментов автоматизации!
Кукольный приходит на ум сразу, но есть много других.
Вы также можете самостоятельно вырастить систему, которая использует SSH-ключи без пароля для входа в удаленные системы и запуска команд на них, что является проверенным временем способом выполнения такого рода вещей со времен до марионеток и тому подобного.

Теперь давайте поговорим о вашей идее, основанной на HTTP- вы пришли прямо и сказали:

Я почти уверен, что это ужасно плохая идея: но из интереса, как это можно обеспечить?

и ты прав: это ужасная идея. НЕ делайте этого в производственной среде, особенно если URL доступен в Big Bad Public Internet.

Позвольте мне перечислить ужас в ужасных деталях:

• Вы используете предварительный общий ключ (mysecretwords). Любой может заняться этим (или угадать) и запустить команды.
• Вы используете безопасность через неизвестность ("Никто никогда не поймет, что https://myserver.com/script это URL, который позволяет вам запускать вещи!").
• Вы запускаете команды как пользователь веб-сервера.
  Это, вероятно, не то, что вы хотите, а это означает, что пользователь веб-сервера должен иметь какие-то повышенные привилегии - запуск от имени root, способный sudo, так далее.
• Вы используете протокол без сохранения состояния (http) для запуска команд, которые, вероятно, ожидают наличие терминала, среды входа в систему и т. Д. - Это можно сделать, но выполнение чего угодно, кроме самых тривиальных задач, означает, что вам придется взломать бэкэнд поддерживать состояние.
• Вы делаете то, что ssh должен делать.
  Не пытайтесь заново изобрести колесо. Обещаю, ваше овальное колесо не так хорошо, как круг (ssh).
  Если вы не можете использовать традиционный SSH, есть много веб-клиентов SSH и даже больше клиентов Java. Используйте один из них. Вы даже можете оставить их за HTTP-авторизацией (имя пользователя / пароль, сертификаты и т. Д.)

Что касается того, как это можно защитить - вы уже сделали почти все, что можете: предварительный общий ключ действует как аутентификация (объединенные имя пользователя и пароль) и обеспечивает уровень шифрования, хотя это и не обязательно.
https:// шифрует ваши данные при передаче и исключает вероятность того, что кто-то прослушает магический URL-адрес (хотя не исключено, что они сами получат его).
Пока ваш сервер разрешает доступ только к волшебному URL https:// соединения, и ваша конфигурация SSL на вашем веб-сервере безопасна, вы не можете сделать намного лучше.

Сказав это, любое усилие, которое вы можете предпринять, чтобы сделать это более безопасным, не может устранить фундаментальные недостатки того, что вы пытаетесь сделать - вы можете сойти с рук навсегда и никогда не быть скомпрометированными, но зачем добавлять поверхность атаки вам не нужно, когда уже есть инструменты, которые делают то, что вы хотите? (Могу добавить, что эти инструменты были написаны экспертами, тщательно проверены / протестированы другими экспертами и широко используются, поэтому, если возникает проблема с безопасностью, она решается в спешке...)