PHP shell_exec telnet

Sziasztok!

Valaki meg tudja mondani, hogy miért működik felemásan a telnet ha php shell_exec-ből hívom?

simán:
shell_exec("telnet 10.10.10.14 666");

ki is írja, hogy trying
conected to
escape character és ennyi, utána bumm.

A túl oldalon figyelő service nem kapja meg a jelet.

A vicc, hogy akkor se megy, ha nem is direktben hívom php-val, hanem meghívok egy bash scriptet, ami átnyomul egy userrel ssh-n egy másik szerverre és onnan hívódna meg az ottani bash-ból a telnet. Minden megy, csak a telnet akad el. Ugyanez a script meghívva parancssorból megy.
Látszólag minden ugyanaz, csak az egyik www-data -ból indul, a másik egy bármilyen user-ből de mindkét esetben sudo-val.

Persze, megoldhatom fsockopen-el, és meg is fogom, mert már a tököm kivan vele, de azért érdekelne az ok, hátha tudja valaki.

Köszi előre is.

Hozzászólások

Csak tipp.. lehet, hogy kell neki a tty? Amúgy a shell_exec példád biztos, hogy helyes? nem kéne oda a telnet parancs is?
Mobilon vagyok, nem tudom tesztelni.
--
Aláírás szünetel...

php indít el egy scriptet sudo-val. az átloggol egy másikgépre ssh-val és onnan az futtatja a telnetet.
Ha simán úgy indítom mint fent idéztem, akkor ugyanaz a hiba, szal itt a php a probléma. (egyelőre megoldottam a telnet hívás php-ból a script lefutása után)

Neked valami ongyilkos hajlamaid lehetnek. PHP indit scriptet sudo-val? Ezt korrektul ugy szokas megoldani, hogy van egy kulon szolgaltatas, amit egy API-val ersz el az ilyen feladatok elvegzesere, lehetoseg szerint nem PHP-ban irva, mert van nehany olyan hisztije amivel ilyen feladatok kapcsan eleg nehez egyutt elni. Az SSH futtatas PHP-bol egyebkent mindig is torkaveres volt, nem tudom mit probalsz megoldani, de ha teheted, keruld el.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT
Refaktor Magazin

+1
Alapvetően a php systemcall erősen ellenjavasolt. Erre most nem esküdnék, de mintha safe_mode-ban le is lenne tiltva. Ha ez egy web alkalmazás akkor apahce/httpd usernek sudo-t adni....imho aggályos. Telnet-et pedig jellemzően csak "sysadmin debug" -ra használjuk, helyette inkább ssh.

Létezik php-hez ssh modul és még működik is (használom). Nem igazán néztem bele a forrásba de úgy tűnik, hogy natívan használja az ssh C lib-eket. Tehát nem csak egy wrapper az ssh CLI client körül.

En szemely szerint szeretem elszeparalni az adminisztrativ es production szolgaltatasokat. Ha egy PHP-nak elgurul a gyogyszere es ledosolja az SSH szolgaltatast (vagy hasonlo), akkor nincs mivel bemenni a gepre es leloni a fenebe az egeszet. Szerintem, ennek a megvalositasa ugy korrekt, ha van a gepen egy API, pl HTTP, es a PHP azt szolongatja. Nyilvan vannak olyan kovetelmenyek amik miatt ez nem teljesulhet (pl. nem lehet a gepen semmifele "extra" kod), de ez esetben megfontolando valamilyen konfiguracio-menedzsment szoftver hasznalata amit API-n lehet hivogatni. Ha a PHP kozvetlenul SSH-zhat egy masik gepre, kulonoskepp rootkent, akkor egyetlen PHP sechole eleg ahhoz, hogy beverjek a gepedet es elinditsanak mindenfele rondasagot. Az meg senkinek nem jo.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT
Refaktor Magazin

Egyetértek...Ha van lehetőség a remote oldalon futtatni egy szolgáltatást ami ad egy API-t, az a szép megoldás.
Sajna a remote host elég ritkán van az én kezemben és max egy "technikai user"-t lehet kérni restricted shell-ben. Mert policy.
(PHP ssh-zni root-tal -"Páncél autó, neeeeem!"

Sajna ez van, erre van lehetőségem.
Abszolúlt belső rendszerről van szó, nincs kint publikusan a weben.
Szívesebben használnék mondjuk nodejs-t amit lehet hívogatni de ha ez a rendszer lehal, akkor szívhatok keményen. Így nem iktatok be inkább még egy layert.

A jelenlegi megoldás (amit nem én csináltam) a fenti módszernél ezerszer fapadosabb és ódivatúbb(php, system(), stb), ez a mostani sokkal modernebb lesz még így is.
A jelenlegi is évek óta működik, dúrva nagy rendszerről van szó, és komoly lehalás nem volt még eddig.

A gépek virtuális gépek, ha lehalnának, amire nem sok esély van, akkor hozzáférünk pillanatok alatt.

Bocs ha nem vázolok részleteket, nagy cég és nem adnék ki részleteket.
Azért köszi a "segítséget".

Nem akarlak megbántani, de milyen +1 layer-ről beszélsz? Valami annak a remote portnak csücsül a végén, elég lenne csak azt cserélni, értelmesebbre.
De hogy a másik oldalról fogjam meg a dolgot, mindent elmond a rendszer komplexitásáról (és tippem szerint a másik végéről is az egésznek) hogy system-el telnet-et hív a rendszer ahelyett hogy a beépített socket kezelést használná

// Happy debugging, suckers
#define true (rand() > 10)

Nem bántódom meg.

Feltettem egy kérdést. Nem érdekel, hogy ki mennyire tartja hülyeségnek, én vagyok benne, én látom át a rendszert, én vagyok kapcsolatban a munkatársakkal a rendszergazdával és a gépekkel, így én tudom, hogy így tud menni és kész.

Azért írtam ki a témát, mert érdekelne a probléma, hogy miért van így és áthidalható e.

Van amikor tanácsot kérek egy megoldásra, akkor szívesen fogadom az ilyen válaszokat is, de ez most nem az. Ne sértődjön meg senki se rajta. Köszi.

A telnet szerintem addig olvas, amig van bemenet az stdin-en. Eppen ezert neked nem a shell_exec kell, hanem a proc_open es megfeleloen fel kell konfiguralnod a pipe-okat, hogy mit honnan etetsz meg tartalommal.

Ettol fuggetlenul PHP-bol mindenfele kulso programokat vegrehajtani alapvetoen nagyon rossz otlet, nehany, lehetoleg a webrol nem elerheto kiveteltol eltekintve (pl cronjob), kerulendo.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT
Refaktor Magazin

nem. Amúgy a system függvény a régi több éves cuccban van. Persze mondhatjuk, hogy a shell_exec meg a proc_open ugyanarra hivatott végeredményben.

A php process indítás egy sh scriptet indít és abban van a végén telnet. A fenti példában írt shell_exec("telnet x.x.x.x xxx"); csak egy példa, hogy az se megy.

Most amúgy fsockopen-el megy minden perfektül. (lefut a process és a végén fsockopen)

A pingelés hatására amúgy egy xinetd által indított script kezd el futni root jogokkal, olyan szerveren ahol már probléma lenne egy sudo jog megadása a távolról belépő ssh usernek.