Eu uso um script wrapper rsync para sincronizar ou fazer backup de/para vários diretórios em diferentes servidores. O script invoca rsync(obviamente), e em algumas configurações lnno servidor.
Restringir o acesso SSH usando o commandparâmetro in authorized_keyspara uma única chave with rrsync(conforme recomendado aqui ) ou chrooting o usuário nos servidores não é viável, pois preciso acessar (ler ou escrever) diretórios em muitos lugares diferentes. Usar um script wrapper para avaliar $SSH_ORIGINAL_COMMAND(conforme sugerido aqui ) permitiria chamadas estáticas para rsyncand ln, mas não para todos os parâmetros diferentes rsynccriados pelo meu script local.
Existe outra maneira de bloquear o acesso nessas circunstâncias?
O OpenSSH ForceCommand é seguro porque o servidor aplica o comando e as opções. Ele não permitirá que o usuário remoto emita uma série de vários comandos. Como seus comandos de backup, como fazer uma série de comandos rsync e relacionados a arquivos com vários parâmetros. Este é um desafio semelhante ao da ferramenta de automação Ansible, que gera e executa scripts e, portanto, também tem problemas quando seus comandos permitidos são limitados.
Scripts wrapper pré-instalados no remoto podem cuidar disso com um comando. Digamos que você escreveu /usr/local/bin/custombackup, que sabe os caminhos para backup e onde arquivá-los. Permita o script em um comando authorized_keys. Também desabilite o shell configurando o usuário para nologin.
No entanto, você pode ter outros cenários ou variações sobre o que fazer backup e como. Em ambientes menos restritivos, isso pode ser resolvido estendendo o script para tomar opções. No entanto, ForceCommand exige uma linha de comando estática. Considere instalar outra chave com um comando forçado diferente, por mais bobo que isso possa parecer.
Cuidado para não ficar esperto demais com a variável de ambiente ${SSH_ORIGINAL_COMMAND}. Se você executasse o comando original sem sanitizá-lo, isso poderia ser um problema de injeção de comando.
E se, no final das contas, o ForceCommand não for implementado, você pode ter defesas adicionais. Remova o acesso de gravação à maioria dos arquivos do usuário de backup. Proteja a chave privada com uma frase-senha e audite todo o acesso a ela no sistema secreto. Audite e registre logins de usuários e consiga correlacioná-los com backups agendados. Se houver suspeita de comprometimento da chave ssh de backup, todos os segredos devem ser rotacionados e novos backups criados do zero.