Adequação de comando sudo /bin/su -

Galera bom dia,

Preciso de uma ajuda.. Tenho o script abaixo e tenho que adicionar o comando (sudo /bin/su - ). Porém quando eu adiciono, ele executa e para no prompt .

read -r year
if [ "$year" = "" ]
then
year="$default_year"
fi


default_month=$(date +%m)
echo -n "Digite o mês da coleta [Default: $default_month]: "

read -r month
if [ "$month" = "" ]
then
month="$default_month"
fi


default_day=$(date +%d)
echo -n "Digite o dia da coleta [Default: $default_day]: "
read -r day
if [ "$day" = "" ]
then
day="$default_day"
fi

echo -n "Digite o usuário: "
read -r user
echo -n "Digite a senha: "
read -r password


for i in `cat $1`
do
sshpass -p$password scp -o ConnectTimeout=4 -o StrictHostKeyChecking=no ./pr.sh $user@$i:~ && sshpass -p$password ssh -o ConnectTimeout=4 -o StrictHostKeyChecking=no -t $user@$i "sudo /bin/su - " "sudo sh pr.sh" && sshpass -p$password ssh -o ConnectTimeout=4 -o StrictHostKeyChecking=no -t $user@$i "sudo /bin/su -" && sshpass -p$password ssh -o ConnectTimeout=4 -o StrictHostKeyChecking=no -t $user@$i "sudo /bin/chown user:user *.bz2" && sshpass -p$password scp -o ConnectTimeout=4 -o StrictHostKeyChecking=no $user@$i:~/*$year$month$day* . && sshpass -p$password ssh -o ConnectTimeout=4 -o StrictHostKeyChecking=no $user@$i "rm ~/*$year$month$day*" && echo $i >> coletados.txt
echo "$i finalizado."
echo " "
done
fi

Aonde estou errando ?

Para que usar sudo su - comando em lugar de apenas sudo comando?

Aqui na empresa os usuários são amarrados por binários.

Com a devida vênia, “su -” está mais para liberação do que para amarração.

Olhando rapidamente seu script, pareceu-me que você quer enviar um script arbitrário para a máquina destino e depois executá-lo como superusuário. É isso mesmo?

Eu particularmente desconfio de tudo que use sshpass. Se o que você quer é realmente o que parece, e se o usuário que vai tentar fazê-lo tiver o direito de o fazer, talvez haja maneiras mais simples de proceder, possivelmente com uma quantidade menor de ferramentas, usando tão-somente autenticação por chave pública de SSH, em lugar de sudo.

É isso mesmo que eu quero fazer.. Executar o comando lá. Porém são em 4 mil máquinas. Fica inviável nesse momento gerar chave.

Bem, se você fez configuração de sudo em 4000 máquinas, por que não a fazer para o SSH? Com um parque desses, você não tem nenhuma ferramenta de centralização de configuração?

Como eu disse acima, eu tenho um pé atrás bem grande com o sshpass, de modo que não conheço nem mesmo a sintaxe dele. Contudo, isolando pedaços da sua linha de comando, eu vejo o seguinte, por exemplo:

sshpass -p$password ssh -o ConnectTimeout=4 -o StrictHostKeyChecking=no -t $user@$i "sudo /bin/su - " "sudo sh pr.sh" 

Os dois últimos argumentos da linha de comando são “sudo /bin/su - ” (incluindo um espaço após o “-”) e “sudo sh pr.sh”. Eu não sei se o sshpass intercepta essas argumentos ou se os passa diretamente para o ssh. Se eles forem passados diretamente para o ssh e, através dele, para o “sudo su -” remoto, observo algumas coisas esquisitas:

  • É impressão minha, ou você está usando sudo para chamar su para, de novo, chamar um sudo, que finalmente chama o script? Por que não chamar o script diretamente pelo su (que também poderia ser evitado, com ajustes no /etc/sudoers e/ou na configuração de SSH de cada máquina destino).

  • Para essa linha funcionar sem que se peça senha em nenhum momento, tanto o usuário $user (ou grupo do qual ele faça parte) quanto o root na máquina $i tem de ter sido adicionados ao /etc/sudoers com a opção NOPASSWD, por causa, respectivamente do primeiro e do segundo sudos na sua linha de comando. O root geralmente vem configurado assim por padrão, mas isso pode ter sido trocado sem querer (ou mesmo de propósito).

  • Quando você usa o argumento “-” com o su, o próximo argumento é interpretado como um nome de usuário (especialmente verdadeiro com versões do su de outros sistemas UNIX, diferentes do Linux). Se o sshpass tiver interceptado seu último argumento e o tiver quebrado em três (i.e. “sudo”, “sh” e “pr.sh”) para passar ao ssh, o nome do usuário remoto para o su será sudo. Se não houver a quebra, esse nome poderá vir a ser “sudo sh pr.sh”.

Se não houvesse sshpass na jogada, mas paenas ssh, eis como eu adaptaria a linha de comando acima.

ssh -o ConnectTimeout=4 -o StrictHostKeyChecking=no -t $user@$i sudo /bin/su - root -c \''sudo sh pr.sh'\' 

Mas se eu pudesse ir além, eu tentaria minimizar o número de escaladas de privilégios, com uma das formas alternativas abaixo.

ssh -o ConnectTimeout=4 -o StrictHostKeyChecking=no -t $user@$i sudo /bin/su - root -c \''sh pr.sh'\' - 

ssh -o ConnectTimeout=4 -o StrictHostKeyChecking=no -t $user@$i sudo /bin/su - root -c caminho/pr.sh 

ssh -o ConnectTimeout=4 -o StrictHostKeyChecking=no -t $user@$i sudo caminho/pr.sh 

Na versão abaixo, usando chave pública, eu posso até prescindir de TTY no SSH, mas tenho de usar uma chave privada que esteja ligada à chave pública que o destino aceite.

ssh -o ConnectTimeout=4 -o StrictHostKeyChecking=no -i secret_key_file root@$i caminho/pr.sh 

Mesmo erro quando eu substituo pela sua linha. Erro abaixo:

Sorry, user user is not allowed to execute '/bin/su -c sudo sh pr.sh' as root on servidor.

Eu já tinha imaginado que a troca da ordem das opções poderia complicar para você (por causa da configuração do sudo) e editei a mensagem acima antes da sua resposta. Pode reexaminá-la?

Mais uma alternativa: já que você está caindo numa sessão interativa, faça envie os comandos por essa sessão, como se você realmente os estivesse digitando na sessão.

sshpass -p$password ssh -o ConnectTimeout=4 -o StrictHostKeyChecking=no -tt $user@$i "sudo /bin/su -" < pr.sh 

Note que a opção “-t” virou “-tt”, para forçar a alocação de TTY mesmo com a entrada padrão do SSH não sendo mais um TTY.