запускать произвольные зашифрованные команды оболочки через 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 на вашем веб-сервере безопасна, вы не можете ничего лучше.

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