executando comandos shell criptografados e arbitrários via http (s)?

Question

Gostaria de poder codificar os scripts de manutenção para serem executados sob demanda remotamente.

edit: Bom caso de uso: webhooks. por exemplo. disparar a implantação de teste de CI + sempre que alguém enviar um código para o github.

Se eu fosse para criptografar um comando shell usando uma cifra segura como aes128 + pass phrase:

por exemplo. 'mysecretwords cd ~ & & mkdir ./alguma coisa '- > 'm4tpWsuiOJT0naKkyWDdNQUKMQ7',

e, em seguida, permitir que o comando seja executado por meio de uma URL:

por exemplo. ' link '

A própria url contém o comando codificado para ser executado no servidor, que pode ser decodificado apenas pelo servidor de destino, com a frase secreta.

Tenho certeza de que esta é uma idéia terrivelmente ruim: mas por interesse como isso pode ser garantido ?

O ato de fazer essa pergunta é provavelmente uma evidência que eu não conheço o suficiente para fazer isso com segurança.

    

Answer 1

Primeiro, vamos abordar sua pergunta principal mais importante:

I'd like to be able to encode maintenance scripts to run on-demand remotely.

Isso soa como um trabalho para ( trombetas som ) Ferramentas de Automação!
marionete vem imediatamente à mente, mas há muitos outros.
Você também pode desenvolver em casa um sistema que usa chaves SSH sem senha para efetuar login nos sistemas remotos e executar comandos neles, o que é uma maneira consagrada de fazer esse tipo de coisa desde os dias anteriores ao fantoche e afins.

Agora vamos falar sobre sua ideia baseada em HTTP - você saiu e disse:

I'm pretty certain this is a horribly bad idea: but out of interest how could this be secured?

e você está certo: é uma ideia horrível. NÃO faça isso em um ambiente de produção, especialmente se a URL estiver acessível na Big Public Internet.

Permita-me enumerar o horror em detalhes terríveis:

• Você está usando uma chave pré-compartilhada ( mysecretwords ). Qualquer um pode surfar nessa (ou adivinhar) e executar comandos.
• Você está usando a segurança através da obscuridade ("Ninguém nunca vai descobrir que https://myserver.com/script é a URL que permite que você execute coisas!").
• Você está executando comandos como o usuário do servidor da Web.
  Provavelmente, isso não é o que você deseja, o que significa que o usuário do servidor da Web precisará ter algum tipo de privilégio elevado - executado como raiz, capaz de sudo , etc.
• Você está usando um protocolo sem estado (http) para executar comandos que provavelmente esperam um terminal, um ambiente de login, etc. - Isso pode ser feito, mas fazer qualquer coisa além das tarefas mais triviais significa Terá que hackear um back-end para manter o estado.
• Você está fazendo o que o ssh deve fazer.
  Não tente reinventar a roda. Eu prometo que sua roda oval não é tão boa quanto o círculo ( ssh ).
  Se você não pode usar o SSH tradicional, há muitos clientes SSH baseados na Web , e ainda mais clientes Java. Use um desses. Você pode até colocá-los por trás da autorização HTTP (nome de usuário / senha, certificados, etc.)

Quanto a como isso pode ser assegurado - você já fez praticamente tudo que pode: a chave pré-compartilhada atua como autenticação (nome de usuário e senha combinados) e fornece uma camada de criptografia, embora não seja necessário.
https:// criptografa seus dados em trânsito e elimina a chance de alguém farejar a URL mágica (embora não a chance deles deduzirem isso sozinhos). Contanto que seu servidor permita acesso somente ao URL mágico sobre https:// conexões, e sua configuração SSL em seu servidor web esteja segura, você não pode fazer muito melhor.

Tendo dito isso, qualquer esforço que você possa fazer para tornar isso mais seguro não pode eliminar as falhas fundamentais do que você está tentando fazer - você pode se safar para sempre e nunca será comprometido, mas por que adicionar uma superfície de ataque que você não precisa quando já existem ferramentas que fazem o que você quer? (Eu devo acrescentar que essas ferramentas foram escritas por especialistas, cuidadosamente examinadas / testadas por outros especialistas, e estão em amplo uso, então se um problema de segurança surgir, ele será consertado rapidamente ...)