Linux: ssh para hospedar e usar o sudo para executar um script, é executado mas parte do script falha

3

Pesquisei alto e baixo para obter uma resposta para isso. Eu tenho a configuração de chaves, portanto, nenhuma senha é necessária para o ssh no host remoto. Eu tenho o sudo configurado com esse usuário para que eu possa executar os comandos necessários como root sem senha. Eu só tenho usado o ssh para executar comandos remotos por alguns dias (que descoberta gloriosa!).

Um pouco de fundo: O script que está sendo executado no host remoto é um típico script de início / parada de um programa. Em algum lugar no programa real, um arquivo de log é aberto para gravação. No host remoto, tudo está bem se eu executar o script como root. Se eu o executar como usuário, recebo um erro: log4cplus:ERROR Unable to open file: appname.log . Faz sentido, já que o log é de propriedade do root.

Agora, a situação: Eu tenho um script no meu host local que irá ssh para o host remoto e usando o sudo irá executar esse script. O script pode ser executado. No entanto, depois de iniciado, recebo o mesmo erro acima do arquivo de log. Eu tentei o seguinte, que todos executam com sucesso o script, mas recebo o erro. Eu sei que alguns não são necessários, mas eu queria cobrir TODAS as bases que eu poderia encontrar (eu tentei com -t assim, mas nenhuma diferença. Eu não pensaria que haveria, mas ...):

/usr/bin/ssh username@remotehost sh -c sudo "/etc/rc3.d/S99script start"

/usr/bin/ssh username@remotehost sh -c sudo "/etc/rc3.d/S99script start"

/usr/bin/ssh username@remotehost 'sh -c sudo "/etc/rc3.d/S99script start"'

/usr/bin/ssh username@remotehost sudo /etc/rc3.d/S99script start

/usr/bin/ssh username@remotehost "sudo /etc/rc3.d/S99script start"

/usr/bin/ssh username@remotehost sudo "/etc/rc3.d/S99script start"

/usr/bin/ssh username@remotehost 'sudo "/etc/rc3.d/S99script start"'

/usr/bin/ssh username@remotehost sudo su - -c "/etc/rc3.d/S99script start"

/usr/bin/ssh username@remotehost 'sudo su - -c "/etc/rc3.d/S99script start"'

Eu sei que existem outras coisas que tentei, mas não documentei todas elas. Não ria da minha tentativa de todas as citações diferentes, eu tenho uma compreensão decente de quando usar o que, em geral, mas eu não estava tomando nenhuma mudança em tentar coisas diferentes:)

Algo que notei ao executá-los, é se eu fizer um ps -ef | grep para o nome do script, ele mostra o seguinte:

[username's UID]  3070  3069  0 14:42 ?   00:00:00 bash -c /etc/rc3.d/S99script start

Isso é mesmo para os que eu faço "sh -c sudo". O fato de ele estar rodando como bash -c é interessante, mas também interessante (eu pensei?) É que ele tem o UID do usuário em vez do nome de usuário listado.

** Adicionar: Eu também tentei criar um script no diretório pessoal do "username" que apenas faz: %código% E eu obtenho o mesmo resultado.

    
por Sama 05.01.2012 / 21:48

2 respostas

0

primeiro, altere sua autenticação baseada em chave de forma que seu login no sistema remoto seja o usuário em questão - então não há necessidade de usar o sudo (já que você já indicou que o serviço não está sendo executado como root, deve não há problemas de segurança com logins automatizados baseados em chaves).

em segundo lugar, dê uma olhada no ForceCommand em sshd_config (5) - isso fornece segurança extra se você estiver trabalhando com uma conta de serviço que só deve ser capaz de fazer uma coisa. Observe bem a referência à diretiva Match.

finalmente, o sudo pode ter resultados inesperados ao executar comandos que também envolvem modificação de arquivos no sistema - é por isso que coisas como "sudo echo foobar > > / etc / passwd" não funcionam como você acho que eles iriam. Isso é provável (embora eu não possa ter certeza sem ver o script em questão) um fator em sua situação atual. siga minha primeira sugestão acima e você ignorará essa questão completamente. :)

    
por 05.01.2012 / 22:25
4

Você está tornando isso muito complicado. ssh -t user@host sudo /path/to/command deve ser tudo o que você precisa fazer (sem citações, escape, executando su e sub-shells - apenas o comando exatamente como você o digitaria no final remoto se estivesse executando-o manualmente)
Se você começar a usar comandos mais complicados, talvez seja necessário citar e escapar, mas para algo simples não é necessário.

Observe que o sinal -t para SSH é necessário se você precisar inserir uma senha para sudo : por padrão, o SSH não alocará um tty para uma sessão de comando remoto (o sudo reclamará amargamente por não conseguir obter sua senha). -t força um terminal a ser alocado, então sudo tem algo para interagir. Pode não ser necessário no seu caso, mas realmente não vai doer nada.

    
por 05.01.2012 / 22:00