SSH via PHP probleem (User account related).

[Koozza]

Beste tweakers,

Ik ben echt bezig met de meest vage constructie ooit, maar het kan niet anders. Ik ben bezig om PHP via SSH een sendmail command op een andere server uit te laten voeren. Zolang ik de root account van de remote server gebruikt via ssh, werkt dit geheel prima en word het mailtje netjes verstuurd.

Echter als ik een speciale account hiervoor pak (Die uiteindelijk ALLEEN dat command mag uit gaan voeren), werkt het niet meer. Op de remote server is de user in /etc/passwd als volgt: (Deze werkt dus niet!)

code:

sendmail:x:2002:2002::/home/sendmail:/bin/bash

Als ik hier van maak:

code:

sendmail:x:0:0::/home/sendmail:/bin/bash

Werkt het zaakje na behoren, maar is die account root en niet echt wat ik wil. Nu is het bijkomende rare probleem; Via php gebeurt dus bovenstaande, maar als ik handmatig het command uitvoer via ssh werkt het wel gewoon!

Even kort samengevat:

Methode:	Succes:
PHP SSH, Remote: root	Ja
PHP SSH, Remote: sendmail account	Nee
bash SSH, Remote: root	Ja
bash SSH, Remote: sendmail account	Ja

Ik weet niet of het nuttige info is, maar het command waarmee ik test is:

code:

printf "To: [e-mail]\nFrom: [e-mail]\nSubject:TEST123\n\nTEST BLAA" | sendmail -t -i

Ik ben echt ten einde raad over waarom dit niet werkt

[Hero of Time]

Heb je nog meer draaien, zoals een webserver? Je moet PHP toch op een of andere manier aansturen. Wat zie je in de verschillende logs? Dat is de eerste plaats waar je gaat zoeken naar je probleem en je noemt er helemaal niets over. Er staat gegarandeerd waarom 't niet werkt.

[CAPSLOCK2000]

BIj dit soort problemen ligt het vaak aan iets dat in je environment zit. BV je taal-instellingen.

PS. Ben je bekend met SSH-forced commands?

[Koozza]

Hero of Time schreef op woensdag 02 april 2014 @ 08:18:
Heb je nog meer draaien, zoals een webserver? Je moet PHP toch op een of andere manier aansturen. Wat zie je in de verschillende logs? Dat is de eerste plaats waar je gaat zoeken naar je probleem en je noemt er helemaal niets over. Er staat gegarandeerd waarom 't niet werkt.

Sorry, dit was ik vergeten te vermelden. Ik heb naar de logs gekeken maar daar stond vrij weinig in: De PHP Code functioneert naar behoren en voert het command daadwerkelijk op SSH uit. Als ik in de PHP code de bijbehorende BASH op vraag staat hier ook niks in, behalve dat het command zonder errors is uitgevoert.

In de .bash_history van de sendmail user wordt niks gelogged als PHP dit uitvoert, waarom weet ik niet (als ik bijvoorbeeld in PHP ls laat uitvoeren, krijg ik een directory listing terug, en staat er ook niks in de .bash_history).

CAPSLOCK2000 schreef op woensdag 02 april 2014 @ 11:34:
BIj dit soort problemen ligt het vaak aan iets dat in je environment zit. BV je taal-instellingen.

PS. Ben je bekend met SSH-forced commands?

Bedoel je dan de PHP environment of die van de remote server waar sendmail op draait? (Misschien handige info: De PHP server draait op Debian Wheezy, en de sendmail server op CentOS 6.4)
Ik ben niet bekend met SSH-Forced commands.


Edit:

Het probleem is opgelost! Kennelijk moet je een heel path meegeven met sendmail als je een andere user gebruikt. Dus /usr/sbin/sendmail IPV gewoon sendmail.

[ Voor 8% gewijzigd door Koozza op 02-04-2014 13:53 ]

[Hero of Time]

Ehm, ja, dat is nogal logisch. De mappen /sbin en /usr/sbin staan niet in de user $PATH voor een hele goede reden. Als je bekent bent met de hiërarchie van het file system, weet je dat.

[Koozza]

Hero of Time schreef op woensdag 02 april 2014 @ 13:59:
Ehm, ja, dat is nogal logisch. De mappen /sbin en /usr/sbin staan niet in de user $PATH voor een hele goede reden. Als je bekent bent met de hiërarchie van het file system, weet je dat.

Ik vind het dan nogal raar dat als ik met putty een SSH opstart met diezelfde user dat rechtstreeks sendmail typen wel gewoon werkt.

Ook als ik de PATH variable opvraag staat /usr/sbin er gewoon tussen:

code:

[sendmail@thijs ~]$ echo $PATH
/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/sendmail/bin

[CAPSLOCK2000]

simpele test, vervang 'sendmail' door '/usr/sbin/sendmail' . Als het dan werkt dan lag het inderdaad aan je PATH. Let op, er wordt verschil gemaakt tussen situaties waarin er een terminal is (waar een mens achter zit) en waar dit niet is (scriptjes). Dat kan ook invloed hebben op je pad.

PS. Verdiep je in SSH forced commands, jouw situatie is een schoolvoorbeeld voor wanneer je die wil gebruiken.

[Verwijderd]

ThijsD schreef op dinsdag 01 april 2014 @ 23:58:

Ik ben echt bezig met de meest vage constructie ooit, maar het kan niet anders.

Dit lijkt me onwaarschijnlijk. Als je al niet een PATH issue op kunt lossen, moet je wellicht ook twijfelen aan je eerdere conclusie dat dit de enige mogelijke constructie was.

Waarom heb je geen lokale MTA die de mail door kan sturen?
Waarom kun je niet op poort 25, 465 of 587 verbinden met de server met sendmail?
Waarom probeerde je uberhaupt sendmail als root aan te roepen?

Ik ben benieuwd hoe je überhaupt zo'n case kunt tegenkomen. Ik ga al een behoorlijk tijdje mee in de webdevelopment en serverbeheerwereld en kan me er weinig bij voorstellen. Ik vind een remote command om een user aan te maken begrijpelijk voor bijvoorbeeld een beheerapplicatie. Maar remote mail sturen via zo'n rare constructie? Dat klinkt als een ontwerpprobleem. Kortom, hoe is deze situatie ontstaan?

[Koozza]

CAPSLOCK2000 schreef op woensdag 02 april 2014 @ 18:24:
simpele test, vervang 'sendmail' door '/usr/sbin/sendmail' . Als het dan werkt dan lag het inderdaad aan je PATH. Let op, er wordt verschil gemaakt tussen situaties waarin er een terminal is (waar een mens achter zit) en waar dit niet is (scriptjes). Dat kan ook invloed hebben op je pad.

Zoals in mijn edit te zien was, met path ervoor werkt het wel gewoon
Ik zal me is gaan verdiepen in SSH forced commands, misschien dat dat het makkelijker maakt.

Verwijderd schreef op woensdag 02 april 2014 @ 20:06:
[...]

Dit lijkt me onwaarschijnlijk. Als je al niet een PATH issue op kunt lossen, moet je wellicht ook twijfelen aan je eerdere conclusie dat dit de enige mogelijke constructie was.

Waarom heb je geen lokale MTA die de mail door kan sturen?
Waarom kun je niet op poort 25, 465 of 587 verbinden met de server met sendmail?
Waarom probeerde je uberhaupt sendmail als root aan te roepen?

Ik ben benieuwd hoe je überhaupt zo'n case kunt tegenkomen. Ik ga al een behoorlijk tijdje mee in de webdevelopment en serverbeheerwereld en kan me er weinig bij voorstellen. Ik vind een remote command om een user aan te maken begrijpelijk voor bijvoorbeeld een beheerapplicatie. Maar remote mail sturen via zo'n rare constructie? Dat klinkt als een ontwerpprobleem. Kortom, hoe is deze situatie ontstaan?

Nou dat kan ik wel uitleggen hoe ik in deze shit ben gekomen. Wij hebben voor een schoolproject van interconnect per groepje een eigen VPS gehad. Deze moesten we zelf installeren en hier een website op developpen. Nu had ik tijdens de laatste oplevering iets te hard gebluft over de werking van onze mailserver, waardoor de docent verbaast was want alle poorten behalve HTTP, FTP, MySQL en SSH staan dicht.

Nu moest ik dus maar een manier bedenken om mail toch werkend te krijgen. (De poorten staan zowel van buiten naar binnen, als van binnen naar buiten dicht).

Hierop had ik bedacht om het sendmail path van php te veranderen in een SSH path naar een externe server. Iets in de richting van: sshpass ****** ssh [e-mail] /usr/sbin/sendmail -t -i

Een andere oplossing kon ik me niet echt bedenken, want kwa poorten was het echt goed dichtgetimmerd

Overigens probeerde ik sendmail niet als root aan te roepen, maar dat was om te testen het hele SSH command wordt dus door www-data uitgevoert.

De les uit dit verhaal: Bluf niet zomaar bij elkaar dat je mailserver werkt

[ Voor 4% gewijzigd door Koozza op 02-04-2014 20:38 ]

[Hero of Time]

Als SSH wel kan, gewoon een SSH tunnel opzetten naar de externe server, lokale MTA aanroepen en die laten mailen door de tunnel heen. Veel veiliger, minder kans op falen en je bluf is geen bluf. Lees even 'man ssh'

[Verwijderd]

ThijsD schreef op woensdag 02 april 2014 @ 20:35:

De les uit dit verhaal: Bluf niet zomaar bij elkaar dat je mailserver werkt

Ik wist wel dat er iets raars achter moest zitten

De SSH tunnel oplossing van Hero of Time is zo gek nog niet.