sudo-nak jelszó odaadása, sudo -S + ssh -t: sorry, you must have a tty to run sudo

Linux-kezdő

Sziasztok,

ssh-n keresztül kellene scripteket futtatnom mindenféle szervereken, de amit futtatni akarok rajtuk az sokszor csak sudo-val elérhető, pl.:

sshpass -p $password ssh StrictHostKeyChecking=no chx@serverfqdn ARG1=$ARG1 ARG2=$ARG2 'bash -s' < local_script.sh | tee -i /tmp/myscript17.out

ahol local_script.sh:
#!/bin/bash
# the below commands 'll run on remote host
hostname -f
command1 -parameter1
command2 -parameter2
sudo su - user2 -c "/home/user2/bin/command3 -parameter3"
sudo su - user3 -c "/home/user3/bin/command4 -parameter4"
exit 0

Csodálatosan működik, változókat át lehet passzolni, a futás eredménye visszajön szépen a gépemre. Csak a sudo-s része nem akar működni, és sajna van olyan amit csak sudo-val tudok futtatni.

pl.: sudo su - user2 -c "/home/user2/bin/command3 -parameter3"
nak kellene jelszót passzolnom (a szerverre belépve természetesen át tudok váltani userX-re), amit próbáltam az: echo $password | sudo -S su - user2 -c "/home/user2/bin/valami.sh"
ez visszatér azzal hogy: sudo: sorry, you must have a tty to run sudo

ssh-nak próbáltam megadni -t, -tt paramétereket, de ugyanaz az eredmény. sudoers módosítás (NOPASSWD:) sajnos nem játszik, az sem hogy az én userem belekerüljön userX groupjába, az sem hogy root crontabból fussanak a scriptek, az sem hogy expect-et feltegyék az OS-ekre (hogy én interaktív módot tudjak vele szimulálni).

Mindenképpen sudo-val kell megoldanom a problémát. Bárkinek bármilyen tapasztalat ezzel? Valahogy csak oda lehet passzolni a jelszót neki...

( chx | 2014. 11. 17., h – 13:12 )

sudoers-ből requiretty kikommentelése nem opció sajna
sudo -A (askpass) szintén nem opció

____________________
echo crash > /dev/kmem

Nem opció, tényleg megfutottam minden ilyen kört, sudoers-t, SSH kulcsosdit, expect-et feltenni, mindent. Semmit ilyesmit nem enged a policy, masszívan semmit.

Egyetlen opció hogy ssh-n áttolom a scriptjeim, és valahogy jelszót passzolok sudo-nak.

____________________
echo crash > /dev/kmem

( kallaics | 2014. 11. 17., h – 13:20 )

"sudoers módosítás (NOPASSWD:) sajnos nem játszik"
pedig ez a hivatalos módja. A sudoers fájlban azt is megmondhatod,hogy melyik programot tudja csak futtatni az adott user.

Esetleg ssh-copy-id az adott user alá és akkor nem kell sudo, meg az egész kavarás:)

( chx | 2014. 11. 17., h – 15:32 )

Érdekes így viszont működik:
sshpass -p $password ssh -t -o StrictHostKeyChecking=no lab1@lab1 'echo ****** | sudo -S su - testuser1 -c "whoami"'

A sudo -S előtti password nem változóban van, ez baj mert el kell rejteni valahogyan. A másik probléma hogy ezzel minden egyes parancs előtt nyitni kell egy ssh session-t.

Ugyanez a forma:
'echo ****** | sudo -S su - testuser1 -c "whoami"'
nem működik ha scriptben van, azaz 'bash -s' < script.sh

____________________
echo crash > /dev/kmem

Menni kell scriptből is, a lényeg hogy használd a '-t' opciót az ssh-nél: 


     -t      Force pseudo-tty allocation.  This can be used to execute arbitrary screen-based programs on a remote machine, which can be very useful, e.g. when implementing menu services.  Multiple -t
             options force tty allocation, even if ssh has no local tty.

( Zahy v | 2014. 11. 18., k – 07:53 )

A sudo -A opcioja egy olyan askpass-sal, ami kb ebbol all? :

read X
echo "$X"
exit

Direktben a szerverre belépve működik:

[lab1@lab1 /]$ export SUDO_ASKPASS=/home/lab1/askpass
[lab1@lab1 /]$ cat /home/lab1/askpass
#!/bin/bash
X=qete1353
echo "$X"
exit
[lab1@lab1 /]$ sudo -A ls
bin boot dev etc home lib lib64 lost+found media mnt opt proc root run sbin srv sys tmp usr var
[lab1@lab1 /]$ sudo -A su - testuser1 -c "whoami"
testuser1
[lab1@lab1 /]$

Viszont ssh-n keresztül küldve már nem:

#!/bin/bash
# commands to run on remote host
export SUDO_ASKPASS="/home/lab1/askpass"
hostname -f
echo $SUDO_ASKPASS
sudo -A su - testuser1 -c "whoami"
exit 0

ssh-n átküldve ezt kaptam még az elején:
Pseudo-terminal will not be allocated because stdin is not a terminal.

Az a gyanúm (ahogy feljebb is írtam) hogy a pseudo tty megszűnik létezni ha:
ssh -t -o StrictHostKeyChecking=no lab1@lab1 'bash -s' < script.sh

____________________
echo crash > /dev/kmem

Keress másik munkahelyet:)

Viccet félretéve:
Ez a tipikus esete a paranoid cégnek, ahol alap dolgokat nem használhatsz. Nekik kell nem neked, ezt kell megértetni velük, vagy dobj egy ticket-et a support-nak,hogy van egy ilyen probléma és mi a megoldás. Ha azt írják,hogy nem lehet megcsinálni,akkor told a főnök orra elé, hogy nem hogy Te ,de ők sem tudják megoldani. :)

Próbáltam :-) A célszerű megoldások (NOPASSWD: pl.) adottak, én is meg tudnám reszelni sudoers-t, OS support meg főleg, de a policy nem engedi.

Ami még eszembe jutott hogy scp-n scriptet feltol, lefuttat, töröl, de hát ugye az hogy 'sudo /tmp/myscript.sh' megint csak tiltott.

Security van, kérem...

____________________
echo crash > /dev/kmem

+1
értemén, hogy a gépesíthető munkát nem akarod kézzel elvégezni nx annyi idő alatt, de akkor is, ha az a cél, hogy kitöltsed/kitöltsék valamivel a munkaidődet, akkor inkább tanuljon az ember, amíg a gépek dolgoznak.

Szóseróla: egy helyen tőlem is elvárták volna, hogy fejlesztőként reggel 8-valameddig ott üljek. Nem is tartott sokáig.

( chx | 2014. 11. 19., sze – 08:13 )

Ha több kettőnél ez marad:

sshpass -p qete1353 ssh -t -o StrictHostKeyChecking=no lab1@lab1 'echo qete1353 | sudo -S "echo"; echo qete1353 | sudo -S su - testuser1 -c "whoami"; echo qete1353 | sudo -S su - testuser2 -c "whoami"; echo qete1353 | sudo -S su - testuser3 -c "whoami"' | tee -i /tmp/log.out

...ahol "whoami" helyett majd a megfelelő parancsok / scriptek szerepelnek.

Nem szép de sorban lefutnak a parancsok a target user nevében, és egyetlen ssh session-ön belül. Igaz így az output (/tmp/log.out) egy ömlesztett valami lesz, viszont ezt már utólag is fel lehet dolgozni.

Sánta de legalább biztosan célba ballag.

____________________
echo crash > /dev/kmem