paulo1205
(usa Ubuntu)
Enviado em 28/12/2017 - 15:20h
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