Um servidor pode sinalizar um cliente para executar um script SEM tunelamento reverso SSH?

Question

Estou tentando configurar um sistema de sincronização de arquivos personalizado e leve para mim. Gostaria que o servidor observasse as alterações em uma determinada pasta (com inotify -m ) e, quando detectasse alguma, propagasse-as para clientes conectados a ela.

Meu primeiro pensamento foi para os computadores clientes iniciarem um túnel SSH (com ssh -R 2222:127.0.0.1:22 ) e, em seguida, para o servidor scp os arquivos de volta para os clientes sempre que necessário. Mas para automatizar o processo, eu precisaria configurar chaves SSH, o que significa que, se o servidor fosse comprometido sem meu conhecimento, meu computador seria exposto em seguida. Eu entendo que existem maneiras de mitigar esses riscos, como chroot jail ou scponly , mas parece um pouco desajeitado abrir um grande buraco apenas para remendá-lo até 99% do caminho.

Ocorreu-me que o problema de segurança surge quando se permite que o servidor envie para o cliente , em vez de ter o cliente puxado do servidor . Então existe algum outro programa ou protocolo que eu possa usar para abrir um túnel para que o cliente, escondido atrás de um IP dinâmico e roteador doméstico, possa monitorar uma determinada porta por um sinal do servidor sem abrindo até manipulação como um túnel SSH faria?

    

Answer 1

Para começar, note que qualquer "solução de sinalização" pode ter condições de corrida não óbvias. Cuidado para não perder um sinal enquanto processa o último sinal!

Uma ideia simples poderia ser o seu servidor anexar linhas a um arquivo local. Então, cada inotify causaria:

date +"%s" >> /path/to/sync-signals.log

Em seus clientes, assista a esse arquivo via ssh / tail, mas qualquer ação de pull é invocada no cliente.

ssh server "tail -n1 -f /path/to/sync-signals.log" | while read -r sigdate; do
    pull from server
done

Observe que esta solução nunca deve perder nenhum "sinal", mas pode causar muitos "traps" desnecessários, caso o servidor acrescente muitos sinais em um curto espaço de tempo. Então, os clientes enquanto loop também deve comparar o último "sigdate" com a data atual de alguma forma. Ou melhor, o servidor atrasaria o sinal de alguma forma (apenas acrescentar uma linha se nada mudou desde alguns segundos.)