[Linux] Uitvoeren programma op andere Linux bak

[pierre-oord]

Ik heb een PHP script dat via exec een bash script aanroept op een linux bak. Nu wil ik meer linux bakken daaronder aansluiten, voor een website. FTP login's van mensen ga ik doen dmv NFS; ze loggen in op een hoofd FTP server en kunnen bij de files op een andere server door een intern netwerk.

Nu wil ik zoiets dus ook doen met het uitvoeren van commando's. Ik wil PHP gewoon een bash script laten aanroepen op de hoofdserver, waarna dit bash script een commando uitvoert op een andere linux box.

Hoe pak ik dit aan? Het commando op de andere linux box kan gewoon onder nobody/nogroup worden uitgevoerd (lees: graag).

Een vriend zei dat dit ook kon over NFS, een commando uitvoeren wat op een andere PC draait. Mij lijkt dat niet kunnen, net als een windows netwerk, en ook omdat ik had gelezen dat er manieren zijn om het root filesystem van een box zelfs op een andere machine te mounten, het heeft weinig zin als alle commando's daarna op die andere machine worden uitgevoerd. Ook zou het een groot beveiligingslek zijn..

Thx!

[djc]

Wat je zou kunnen doen is op de andere bak ook een PHP scriptje zetten en dat aanroepen via HTTP. Kun je een of andere token meegeven als security, en de output via de HTTP response weer terugsturen (als dat nodig is).

[Verwijderd]

Je kan met rsh/ssh direct remote commando's uitvoeren. In het geval van ssh zorg je eerst dat je op de bakken waar je gaat inloggen een shared ssh key hebt aangemaakt voor de user die gaat inloggen, zodat je geen prompt voor een password krijgt. Via exec in php kan je weer het ssh commando aanroepen. Mocht je interesse hebben of hulp nodig dan kan ik wel een partij links en voorbeelden opgraven in het aloude archief:

OpenSSH1,OpenSSH2 and ssh.com Public Key Authentication on Linux
http://newweb.ices.utexas.edu/adminworld/sshinterop.html#5

SSH and OpenSSH publickey authorization
http://www.mth.kcl.ac.uk/~klemm/ssh.html

v.b.

ssh [e-mail] "cp test.txt test.bak"

[ Voor 41% gewijzigd door Verwijderd op 24-03-2004 17:19 ]

[Verwijderd]

Je kan via SSH willekeurige commando's uitvoeren op remote machines.

SSH user@hostname commando

Als je public key authentication gebruikt heeft SSH geen wachtwoord meer nodig en kan je dit ook niet-interactief (dus in scripts) gebruiken.

[Verwijderd]

code:

ssh -tX eenuser@jemasterserver 'ssh -tX eenuser@eenanderehost applicatie'

Doet wat je wilt als ik me niet vergis.

[pierre-oord]

Bedankt voor de reply's tot zover ik moet even wat werk hier afronden, ga ik straks even dit testen. Even wat googlen om te zien hoe ik zo'n 2e key maak.

Dit is toch niet een groot beveiligingslek he, dat iemand vanaf internet ook met een een of andere key kan inloggen?

[Verwijderd]

pierre-oord schreef op 24 maart 2004 @ 17:32:
Dit is toch niet een groot beveiligingslek he, dat iemand vanaf internet ook met een een of andere key kan inloggen?

Ga je anders eerst eens inlezen op het gebied van public/private key authentication. Zolang de private key goed beschermt word, is dit een redelijk goede beveiliging. Besef wel, dat iedereen die een (mogelijke) fout vind in je php scripten cq je webserver automatisch toegang krijgt tot de private key en dus ook vanalles kan doen op je andere server. Strak en netjes coden dus

[Verwijderd]

Mwhoh ten eerste kun je gewoon bepalen welke commando's uitgevoerd mogen worden bij een bepaalde key authenticatie.

Ten tweede kan je bepalen vanaf welke host er verbonden mag worden met de key.

Ten derde behoor je de aanroepende code buiten de www-root te plaatsen.

Als je die 3 dingen goed instelt dan is de kans dat er wat gebeurt aardig geminimaliseerd.

[pierre-oord]

Owkee, na een tijd ga ik dit dus eindelijk doen. Het is allemaal heel simpel, ik kan nu als root zo inloggen op de andere bak bijvoorbeeld. Maar dan...

User apache moet straks een script uitvoeren wat een commando uitvoert op een andere PC. Dit script draait dus ook onder gebruiker apache. En dan komt het: Gebruiker apache heeft nooit een home directory gekregen, waarin in het andere deel van de key kan zetten. Apache is een gebruiker voor het Apache proces, waarmee je dus niet kunt inloggen etc.

Weet iemand hoe ik dit probleem oplos?

[CyBeR]

Je kunt natuurlijk ook gewoon rexec gebruiken, dat voor dit soort geintjes gemaakt is.

[Sendy]

Helaas zijn de r* utilities (rexec, rsh, rlogin) allemaal zo onveilig als de pest. ssh is voor dit soort geintjes een goede (de beste?) vervanger!

Pierre-oord >
Ik begrijp je probleem niet zo heel goed, maar je kan op het ssh commando opgeven waarvandaan hij de key moet lezen.

[pierre-oord]

Sendy schreef op 10 april 2004 @ 18:43:
Helaas zijn de r* utilities (rexec, rsh, rlogin) allemaal zo onveilig als de pest. ssh is voor dit soort geintjes een goede (de beste?) vervanger!

Pierre-oord >
Ik begrijp je probleem niet zo heel goed, maar je kan op het ssh commando opgeven waarvandaan hij de key moet lezen.

oh, als dat kan, ik ga op onderzoek uit dat ik daar niet aan dacht. I'll keep you posted

[pierre-oord]

Sendy schreef op 10 april 2004 @ 18:43:
..

Pierre-oord >
Ik begrijp je probleem niet zo heel goed, maar je kan op het ssh commando opgeven waarvandaan hij de key moet lezen.

Eindelijk even tijd vandaag, ik heb zojuist gekeken in de --help en de man, maar nergens vind ik hoe ik dit moet doen. Ik heb dit probleem eigenlijk aan 2 kanten:

Op de server wil ik een gebruiker een commando laten uitvoeren, maar eigenlijk moet deze zich remote niet kunnen inloggen, dus met /bin/false en geen home dir, maar dan werkt SSH niet. Okee, ik heb daar nu maar een user voor gemaakt. Maar dan de andere kant, waar user "apache" een ssh commando gaat uitvoeren. Deze user heeft ook geen home directory, waarin een sleutel staat. En nergens vind ik een command line optie om de key uit een andere directory te lezen voor apache. Ik heb wel al een direcotry speciaal voor alleen lezen voor apache gemaakt, maar die moet wel oproepbaar zijn.

Ik hoop dat dit kan, anders moet ik een lastige constuctie maken met iets van sudo, die dan het ssh commando aanroept. Het wordt dan alleen erg "ingewikkeld" wat de beveiliging niet ten goede kan komen.

[smokalot]

uit "man ssh":

code:

-i identity_file
             Selects a file from which the identity (private key) for RSA or
             DSA authentication is read.  The default is $HOME/.ssh/identity
             for protocol version 1, and $HOME/.ssh/id_rsa and
             $HOME/.ssh/id_dsa for protocol version 2.  Identity files may
             also be specified on a per-host basis in the configuration file.
             It is possible to have multiple -i options (and multiple identi-
             ties specified in configuration files).

dus dat kan prima...

[pierre-oord]

smokalot schreef op 12 april 2004 @ 16:25:
uit "man ssh":

code:

-i identity_file
             Selects a file from which the identity (private key) for RSA or
             DSA authentication is read.  The default is $HOME/.ssh/identity
             for protocol version 1, and $HOME/.ssh/id_rsa and
             $HOME/.ssh/id_dsa for protocol version 2.  Identity files may
             also be specified on a per-host basis in the configuration file.
             It is possible to have multiple -i options (and multiple identi-
             ties specified in configuration files).

dus dat kan prima...

Ik ga het zo gelijk testen, ik heb dit wel gelezen, maar heb over "and $HOME/.ssh/id_rsa and $HOME/.ssh/id_dsa for protocol version 2" heengelezen! Ik dacht dat identity er niets mee te maken had, heeft het ook niet, want het is v1. thx

[Verwijderd]

Sendy schreef op 10 april 2004 @ 18:43:
Helaas zijn de r* utilities (rexec, rsh, rlogin) allemaal zo onveilig als de pest.

Net zoals NFS?

[pierre-oord]

Ja, met nfs zag ik ook een execute optie, maar dat zal ook wel niet veilig zijn denk ik. Ik bedoel, SSH is gecodeerd met 2 sleutels, NFS is een simpele optie die iedereen op de client zo kan gebruiken.

edit:
Het lijkt niet te willen werken:

tijdelijk@pierre:/apache$ ssh -p 2200 -2 -i /home/.server2ssh pierre@10.0.0.2 /servers/hlds 10 start
The authenticity of host '10.0.0.2 (10.0.0.2)' can't be established.
RSA key fingerprint is XX.XX.XX.XX.XX.XX.XX.XX.XX.XX.XX.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.0.0.2' (RSA) to the list of known hosts.
Enter passphrase for key '/home/.server2ssh':

tijdelijk@pierre:/apache$

Doe ik nu weer iets simpels fout?

[ Voor 58% gewijzigd door pierre-oord op 12-04-2004 21:20 ]

[sirdupre]

Maar SSH is toch helemaal niet veiliger binnen een trusted netwerk omgeving? Als er NFS overheen loopt, is SSH toch helemaal niet veiliger? Zeker als het mogelijk is met NFS commando's uit te voeren, dan gebruikt een potentiële cracker toch gewoon NFS.... Als je zeker weet dat er niet zomaar afgetapt kan worden tussen die bakken, kan je net zo goed rexec gebruiken dan, lijkt me...

[pierre-oord]

SirDupre schreef op 12 april 2004 @ 21:41:
Maar SSH is toch helemaal niet veiliger binnen een trusted netwerk omgeving? Als er NFS overheen loopt, is SSH toch helemaal niet veiliger? Zeker als het mogelijk is met NFS commando's uit te voeren, dan gebruikt een potentiële cracker toch gewoon NFS.... Als je zeker weet dat er niet zomaar afgetapt kan worden tussen die bakken, kan je net zo goed rexec gebruiken dan, lijkt me...

Daar heb je natuurlijk gelijk in maar voor mij is het toch maar een kleinigheid, en om het dan meteen veilig te doen. Het is ook veiliger met die sleutels op het systeem zelf geloof ik, als dat gekraakt wordt.

SSH is sleutels, en rexec is denk ik met wachtwoorden enzo. Hetzelfde geldt voor NFS. Met natuurlijk nog het idee dat iemand met een laptop in de server ruimte eng kan gaan doen.

[Sendy]

rexec is zelfs zonder wachtwoord. Je stelt in een filetje in wie onder jouw naam mag inloggen (en dat specifieer ja als ip en username!) en that's it. Die persoon kan dan zonder wachtwoord, vanaf dat ip inloggen. Rete onveilig, zelfs in bedrijfnetwerken. Tenminste, als je verantwoordelijk bent voor je werk

nfs is (soms) ook onveilig, maar op een andere manier. Met nfs is het probleem dat een root user betrouwbaar geacht wordt. Maar iedereen kan natuurlijk root user op een computer zijn. Tegenwoordig is dat helemaal makkelijk met knoppix en user-mode-linux. Ter voorkoming van veiligheidslekken, kan je nfs het best non-setuid mounten en geen files van de root user op het filesystem hebben. Maar ik ben geen nfs expert, dus ik lul vast uit m'n nek.

Pierre-oord >
Je ssh vraagt nu om een passphrase. Dat is de key van die je key beschermt. Als je passphrase-loos wil inloggen moet je een key maken zonder passphrase (want die kan je niet intikken.) Je kan misschien ook ssh-agent gebruiken (en dan 1 keer een wachtwoord intikken); dan moet je je ssh opstarten via ssh-agent (of ssh-agent een shell laten opstarten, en dan daarin het ssh commando). Je kan dan met ssh-addkey een gedecrypte sleutel toevoegen aan je sleutelring. Maar makkelijker is gewoon geen passphrase intikken.

offtopic:
Ik heb je site pckennis bekeken, maar ik kan met Mozilla op OS X haast niet je menustructuur gebruiken. Het menuutje klapt meteen in als ik een subcategory wil selecteren

[ Voor 9% gewijzigd door Sendy op 12-04-2004 23:08 . Reden: Typos en [ot] ]

[_Squatt_]

Sendy schreef op 12 april 2004 @ 23:04:
nfs is (soms) ook onveilig, maar op een andere manier. Met nfs is het probleem dat een root user betrouwbaar geacht wordt. Maar iedereen kan natuurlijk root user op een computer zijn. Tegenwoordig is dat helemaal makkelijk met knoppix en user-mode-linux. Ter voorkoming van veiligheidslekken, kan je nfs het best non-setuid mounten en geen files van de root user op het filesystem hebben. Maar ik ben geen nfs expert, dus ik lul vast uit m'n nek.

Ik dacht dat het probleem was dat iemand die root is op een client elke uid kan aannemen. En zich dus voor kan doen als wie dan ook. De enige manier om bestanden te beschermen is dan om ze eigendom van root te maken. Uid 0 wordt standaard namelijk gemapt naar een ander account. Je kunt ook alle user requests mappen naar dat andere account. _{maar ik ben ook geen nfs expert}

Maar makkelijker is gewoon geen passphrase intikken.

En onveiliger. Klik hier voor een serie artikelen waarin uitgelegd wordt hoe je wel een passphrase kunt gebruiken, zonder dat je de 'ongemakken' daarvan hebt.

[ Voor 4% gewijzigd door _Squatt_ op 12-04-2004 23:41 ]

[Sendy]

Inderdaad _Squatt_, jouw verhaal is van de andere kant gezien Die root remap truck is ook van de laatste jaren Jouw oplossing voor alle files van root maken is natuurlijk ridicuul, dan valt het niet meer te gebruiken. Als je als-root kan mounten, kan je natuurlijk makkelijk backdoors installeren in configuratie files (bijvoorbeeld in ~/.ssh-authorized_keys.) Daarom _moet_ root te vertrouwen zijn. Of jouw oplossing natuurlijk

Goede link trouwens. Dat artikel gaat over het maken van keys. Een (nog) betere verdere link is deze. ssh-agent in detail.

offtopic:
Oh, niet helemaal goed gelezen. Je hebt een prima link gegeven.

[ Voor 15% gewijzigd door Sendy op 13-04-2004 00:10 ]

[pierre-oord]

Ik ga zo ook even die links lezen, even wat verplichtingen doen.

Even over mijn site sendy: die moet worden geupdate, ik zal zorgen voor een nieuw menu. Overigens heb ik op een windows ( ) systeem met mozilla geen problemen met de menu's, behalve dat ze soms niet willen inklappen, maar opnieuw erover muizen lost dat op. Maar ik zal er naar kijken, ik moet toch ook een nieuwe layout maken. Maar ja, het gaat om de info he

Over de passphrase:
Als ik onder een user waarin ik in de home dir de andere kant van de key heb staan hoef ik dat niet in te vullen. Echter, onder een andere user die geen .ssh dir heeft in de home directory, en ik daarna met de -l optie (of andere, iig om die files op te geven) dan krijg ik dus de vraag om dat password. Die heb ik gewoon leeggelaten, het zou automatisch moeten werken. De bestanden zijn ook ge chownt .. Ik ga het zo nog eens proberen, maar het blijft raar.

Het uiteindelijke doel is straks om user apache, zonder home dir, rechten te geven het commando uit te voeren. ik heb nu een tijdelijke oplossing, wat werkt: Met sudo het ssh commando aanroepen onder een user die wel de .ssh directory heeft staat in z'n home dir. Maar zoveel tool's vraagt om beveiligingsproblemen natuurlijk.

edit:
ssh-agent is de bedoeling voor met een password te werken. Dat gaat denk ik ook problemen geven met apache, net als met cron, zoals al genoemd staat in dat artikel.

Is er niet een heel andere benadering ofzo? Ik hoef maar 1 bestand op de remote PC uit te voeren via iets als SSH, een bash scriptje, en dat regelt daar alles verder. Verder hoeft SSH niets te kunnen op de bak, behalve met een password wel inloggen op de bak vanaf mijn huis bijvoorbeeld. Ik heb het liever wel veilig idd, niet dat als er een back word ge-root dan meteen de andere bak(ken) ook worden gestraft.

[ Voor 20% gewijzigd door pierre-oord op 13-04-2004 14:51 ]

[Sendy]

Het idee van ssh-agent is dat je juist maar 1 keer het wachtwoord invult. Bijvoorbeeld bij het opstarten van apache. Dat is nog steeds vervelend, maar dan kan het in ieder geval. Anders moet je een key zonder passphrase maken en dat is weer (een beetje) onveilig. Je kan aan de ssh-server kant de mogelijke commando's beperken. Dat moet je zeker ook doen.

Ik zal je verhaal lezen als ik weer tijd heb