SSH Stuk -> Hoe remote toegang krijgen?

[Ariejan]

Dit is het probleem waar ik op dit moment mee zit. Aan mij de taak om SSH terug de lucht in te krijgen, het liefst zonder helemaal naar A'dam te moeten reizen.

Een server (geplaatst in adam) wordt remote beheerd vanuit Eindhoven. Nu is het zo dat een beheerder de configuratie van SSH dusdanig door de war geschopt heeft, dat deze niet meer start. Door middel van gebruik van 't APC is de server al gereboot, maar SSH werd ook toen niet gestart.

De server draait op SuSE 9.3 Pro met firewall. Actieve services/software

Apache 2.0.53, mod_php4, mod_ssl
Postfix
PureFTPd
SSH -> broken
MySQL -> geen toegang van buitenaf.

Ik ben in het bezit van 'n gewoon gebruikers account, en het root account. Beide accounts kan ik dus gebruiken.

Mijn vraag, omdat ik hier toch nieuwsgierig naar ben: hoe kan ik het ssh config bestand veranderen?? Rebooten kan dan via de APC switch, waarna SSH weer in de lucht zou moeten zijn.

Wat heb ik zelf geprobeerd?

Inloggen via FTP (useraccount) en dan naar /etc gaan lukt niet (chroot in homedir)
Inloggen via FTP (als root) lukt niet
Telnet staat uit
Via apache het configbestand van ssh overschrijven zal waarschijnlijk niet lukken.

Iemand ideeen hierover?? Het mogen de meeste vieze hacks zijn die je maar kunt verzinnen, als alle data maar in tact blijft. 'n keer rebooten is geen probleem.

Alvast bedankt!!

[andreict]

mja we gaan hier dus niet vertellen hoe je zon server kan hacken om er dingen mee te gaan doen. (we kunnen niet weten of je wel de eigenaar of dergelijke bent van die server)

Een goede oplossing is toch ff naar amsterdam te rijden, daar wordt je ook voor betaald neem ik aan?

[F_J_K]

Het mogen de meeste vieze hacks zijn die je maar kunt verzinnen, als alle data maar in tact blijft.

offtopic:
Herstel: het mogen niet de meeste vieze hacks zijn want we willen niet dat scriptkiddies het gaan nadoen op andermans servers. Dus laten we het houden op enige opties waar gewoon het root password ook wordt gebruikt

[Ariejan]

F_J_K schreef op donderdag 15 december 2005 @ 13:12:
[...]

offtopic:
Herstel: het mogen niet de meeste vieze hacks zijn want we willen niet dat scriptkiddies het gaan nadoen op andermans servers. Dus laten we het houden op enige opties waar gewoon het root password ook wordt gebruikt

Puik plan. Dan is daarmee ook gelijk aangetoond dat ik de nodige rechten heb op die bak. (Waarom SSH negeren als je 'n useraccount en root account hebt?)

[Verwijderd]

remote zal je een hoop kunnen hacken, maar daar kunnen we je echt niet mee helpen, want dan wordt het hier een bron voor hackers. Er zijn zat sites die uitleggen hoe je kan hacken

tip: "gebruik een script via ftp" dat kan wel helpen vaak, meer ga ik niet zeggen.

verder denk ik toch echt dat je beter in de auto kan stappen.

[ Voor 5% gewijzigd door Verwijderd op 15-12-2005 13:15 ]

[Murcielago]

gewoon de persoon die het verpest heeft de boel laten fixen, en anders een schadevergoeding

[Verwijderd]

Met ftp uploaden van een bash script waarin je met root login en ww inlogt op je bak en de goede ssh config terugzet. Dit script via een php pagina uit laten voeren?

^^Zo werkt het vaak niet djmurcielago...

[ Voor 13% gewijzigd door Verwijderd op 15-12-2005 13:17 ]

[Verwijderd]

Een reboot is geen optie?

Of maak een SSH bestand aan, mail dat naar een persoon met directe toegang en laat die dat bestand kopieeren

[ Voor 70% gewijzigd door Verwijderd op 15-12-2005 13:24 ]

[Ariejan]

Verwijderd schreef op donderdag 15 december 2005 @ 13:18:
Een reboot is geen optie?

Jawel, maar met 'n fout in het configbestand los je daar niks mee op. Eerst 'n configbestand fixen, dan via de APC pagina 'n reboot doen.

[Ariejan]

Verwijderd schreef op donderdag 15 december 2005 @ 13:16:
Met ftp uploaden van een bash script waarin je met root login en ww inlogt op je bak en de goede ssh config terugzet. Dit script via een php pagina uit laten voeren?

^^Zo werkt het vaak niet djmurcielago...

Hmm. ik ben chrooted in m'n home dir. Ik weet niet of ik public_html heb/kan maken/gebruiken. Goed idee! Ga het even bekijken.

[DeMoN]

_-edit-

[ Voor 160% gewijzigd door DeMoN op 15-12-2005 13:25 ]

[AtleX]

Dat is al gebeurd blaatkoetje

Ik weet niet hoe dicht je webserverconfig is, maar langs die weg zou ik het toch gaan proberen. Je kan FTP-en, dus als je er een scriptje opzet die je SSH config overschrijft ben je er eigenlijk al. Daarna kan je via die APC rebooten en dan moet je er als het goed is weer bij kunnen.

[DJ Buzzz]

Lijkt me toch dat je eens serieus naar de beveiliging van je server moet kijken als grapjes zoals hierboven lukken... Als het een beetje fatsoenlijk dicht zit, zit er al snel niet veel anders op dan erheen rijden...

[DeMoN]

djbuzzz schreef op donderdag 15 december 2005 @ 13:23:
Lijkt me toch dat je eens serieus naar de beveiliging van je server moet kijken als grapjes zoals hierboven lukken... Als het een beetje fatsoenlijk dicht zit, zit er al snel niet veel anders op dan erheen rijden...

Dat dacht ik ook al en daarom poste ik het maar niet
Normaal kan je in die dir van die chroot geen php script bestanden via apache laten uitvoeren..

[0siris]

AtleX schreef op donderdag 15 december 2005 @ 13:21:
Je kan FTP-en, dus als je er een scriptje opzet die je SSH config overschrijft ben je er eigenlijk al.

*zucht*

Ariejan schreef:
Inloggen via FTP (useraccount) en dan naar /etc gaan lukt niet (chroot in homedir)

[Ariejan]

Ok. Ik heb geen url/~ariejan/ access. Krijg 'n 403 voor m'n kiezen.

Er wordt Moodle gedraait op die bak. Misschien dat we daar wat mee kunnen? Misschien via die weg iets uploaden? Hmm. checking.

[AtleX]

0siris schreef op donderdag 15 december 2005 @ 13:26:
[...]

*zucht*

[...]

Lezen aub. Als hij gewoon een (PHP-) scriptje erop zet via FTP, en dat aanroept via zijn browser. Dan kan dat scriptje misschien wel in /etc gaan rommelen zodat de config overschreven kan worden.

[Ariejan]

He. ik heb wat! Ik heb ook beheerders rechten op de Moodle site.

Daar kan ik opgeven wat de locatie is van 'zip'. Als ik dat 'ns verwijs naar 'n bash script in /home/ariejan (wat ik kan uploaden).

Als ik dan 'n file 'zip' wordt m'n config hersteld als 't goed is.

Of zit ik er dan helemaal naast?

[MrBarBarian]

Eerst naar Amsterdam en de boel fixen..

Daarna een les leren en een remote console kaart in dat ding steken (zoals Sun een RSC heeft, HP een GSP enz enz).. en vergeet dat ding niet te configgen

Ik vind het doelbewust hacken van je eigen server echt totaal not done... en als je mijn klant zou zijn zou ik direct de overeekomst opzeggen

[ Voor 28% gewijzigd door MrBarBarian op 15-12-2005 13:33 ]

[0siris]

AtleX schreef op donderdag 15 december 2005 @ 13:29:
[...]Lezen aub. Als hij gewoon een (PHP-) scriptje erop zet via FTP, en dat aanroept via zijn browser. Dan kan dat scriptje misschien wel in /etc gaan rommelen zodat de config overschreven kan worden.

Hmm....true, my mistake

[DeMoN]

Ariejan schreef op donderdag 15 december 2005 @ 13:30:
He. ik heb wat! Ik heb ook beheerders rechten op de Moodle site.

Daar kan ik opgeven wat de locatie is van 'zip'. Als ik dat 'ns verwijs naar 'n bash script in /home/ariejan (wat ik kan uploaden).

Als ik dan 'n file 'zip' wordt m'n config hersteld als 't goed is.

Of zit ik er dan helemaal naast?

Hmm lijkt mij dat ie 'zip' nodig heeft om bijvoorbeeld lokaal het volgende uit te kunnen voeren:

zip stuff.zip *

(alle files in curdir zippen in stuff.zip)

Dus als jij dat gaat vervangen naar wat anders gaat hij

bashscriptvanjou stuff.zip *

uitvoeren waarschijnlijk.
Als je bashscript nou alle 'argvs' negeert en je er wel inzet hoe hij je ssh config moet resetten met een sshd restart erbij zou het misschien kunnen werken.

Zomaar een idee?

sverzijl schreef op donderdag 15 december 2005 @ 13:38:
[...]

Maar dat is precies hetzelfde idee als TS zelf ook al heeft

Maar ik documenteer het alleen ff

[ Voor 21% gewijzigd door DeMoN op 15-12-2005 13:39 ]

[Arnout]

403 betekent niet automatisch dat je geen toegang hebt. 403 treed ook op wanneer Indexes uit staan (standaard). Dus zet er even een index.html of index.php neer.

[DeMoN]

Maak een bootflop met de nodige opstartscripts die alles voor je fixen en stuur die naar ze op via de post

[sverzijl]

DeMoN schreef op donderdag 15 december 2005 @ 13:36:
Zomaar een idee?

Maar dat is precies hetzelfde idee als TS zelf ook al heeft

MrBarBarian schreef op donderdag 15 december 2005 @ 13:32:
Daarna een les leren en een remote console kaart in dat ding steken (zoals Sun een RSC heeft, HP een GSP enz enz).. en vergeet dat ding niet te configgen

Die GSP is leuk, behalve als ie hangt. Je kan de GSP resetten, maar dan moet je eerst de halve kast openmaken Gelukkig is dat bij de wat nieuwere modellen verholpen.

[ Voor 54% gewijzigd door sverzijl op 15-12-2005 13:42 ]

[Ariejan]

DeMoN schreef op donderdag 15 december 2005 @ 13:36:
[...]


Hmm lijkt mij dat ie 'zip' nodig heeft om bijvoorbeeld lokaal het volgende uit te kunnen voeren:

zip stuff.zip *

(alle files in curdir zippen in stuff.zip)

Dus als jij dat gaat vervangen naar wat anders gaat hij

bashscriptvanjou stuff.zip *

uitvoeren waarschijnlijk.
Als je bashscript nou alle 'argvs' negeert en je er wel inzet hoe hij je ssh config moet resetten met een sshd restart erbij zou het misschien kunnen werken.

Zomaar een idee?

Precies.

Alleen. Hoe kan ik su of sudo uitvoeren zonder dat er interactief om 'n password gevraagd wordt..

[LoBbY_1]

Misschien is het ook handig om de volgende keer een pakket te installeren als webmin om zo als nog fouten te kunnen oplossen naderhand. Ik weet niet over wat voor budged je beschikt om je servers op afstand te kunnen beheren, maar een leuke tool in zo'n geval is "KVM over IP". Zo kan je altijd nog inloggen.

[Ariejan]

LoBbY_1 schreef op donderdag 15 december 2005 @ 13:46:
Misschien is het ook handig om de volgende keer een pakket te installeren als webmin om zo als nog fouten te kunnen oplossen naderhand. Ik weet niet over wat voor budged je beschikt om je servers op afstand te kunnen beheren, maar een leuke tool in zo'n geval is "KVM over IP". Zo kan je altijd nog inloggen.

Dat is 't eerste wat ik wilde gaan doen ja Webmin.

Het is overigens m'n eigen server die ik samen met 'n vriend beheer. Dus het budget is vrij klein enzo. Daarom is het ook geen probleem om hier 'n creatieve oplossing voor te verzinnen.

[bakkerl]

Als je de volgende keer gaat spelen met configuraties dan maak je een backup van de huidige juiste config files. Daarnaast een script welke deze config files terug zet en de server/service herstart.
Vervolgens maat je een 'at' (cron maar dan eenmalig) aan welke na een uur dat script uitvoert.

Dan heb je een uur om te spelen wat je wil. Gaat het mis duurt het maximaal een uur voordat de configs weer terug gezet worden. Tevens ook handig voor iptables aanpassen.

En als je binnen het uur klaar bent, en het is goed, dan kun je een 'at' (of een cron) altijd nog cancelen.

[ Voor 4% gewijzigd door bakkerl op 15-12-2005 13:53 ]

[sverzijl]

Ariejan schreef op donderdag 15 december 2005 @ 13:39:
[...]


Precies.

Alleen. Hoe kan ik su of sudo uitvoeren zonder dat er interactief om 'n password gevraagd wordt..

sudo -S gebruiken ?

-S The -S (stdin) option causes sudo to read the password from
standard input instead of the terminal device.

(Dit is op HPUX, weet niet of de SuSE port ditzelfde heeft)

[DeMoN]

Ariejan schreef op donderdag 15 december 2005 @ 13:39:
[...]


Precies.

Alleen. Hoe kan ik su of sudo uitvoeren zonder dat er interactief om 'n password gevraagd wordt..

Heb ik nog nooit gedaan.
Dit is wat ik kan vinden:

http://www.computing.net/unix/wwwboard/forum/7127.html

Maar kleine kans dat je 'expect' al op je bak hebt staan

sverzijl schreef op donderdag 15 december 2005 @ 13:53:
[...]

sudo -S gebruiken ?

-S The -S (stdin) option causes sudo to read the password from
standard input instead of the terminal device.

(Dit is op HPUX, weet niet of de SuSE port ditzelfde heeft)

su: invalid option -- S
Usage: su [OPTS] [-] [username [ARGS]]
        -       make this a login shell
        -c, --command=<command>
                pass command to the invoked shell using its -c
                option
        -m, -p, --preserve-environment
                do not reset environment variables, and keep the
                same shell
        -s, --shell=<shell>
                use shell instead of the default in /etc/passwd

Debian SID.

[ Voor 51% gewijzigd door DeMoN op 15-12-2005 14:02 ]

[Ariejan]

sverzijl schreef op donderdag 15 december 2005 @ 13:53:
[...]

sudo -S gebruiken ?

-S The -S (stdin) option causes sudo to read the password from
standard input instead of the terminal device.

(Dit is op HPUX, weet niet of de SuSE port ditzelfde heeft)

Op m'n lokale suse bak werkt dat

sudo -S touch blah < file1

file1 bevat het root password. blah is owned door root Mooi. Ik ben goed op weg denk ik zo.

[Verwijderd]

waarom geen backup terug zetten ???

zeg nu niet dat je een server hebt zonder backup ??

en anders blaas je toch gewoon de install software er over om ssh weer up te krijgen ..

en ander zet je toch telnet weer aan even om het probleem op te lossen
er is toch een beheerder daar ??

[ Voor 59% gewijzigd door Verwijderd op 15-12-2005 14:14 ]

[Eijkb]

Ik weet niet wat voor server het is, maar KVM over IP is een dure oplossing. Misschien ondersteunt je hardware wel IMPI 1.0 of 2.0.

Voor de rest, ik ben al meerdermale naar Amsterdam gereden (vanuit Antwerpen) om even een SSH config te reconfigureren Dus stap maar in de auto.

Mocht het via een FTP account toch lukken, dan is je server niet goed beveiligd

[sverzijl]

Verwijderd schreef op donderdag 15 december 2005 @ 14:06:
er is toch een beheerder daar ??

krijg het vermoeden van niet, anders had die de SSH config wel aan kunnen passen.

[DeMoN]

Ariejan schreef op donderdag 15 december 2005 @ 14:02:
[...]


Op m'n lokale suse bak werkt dat

sudo -S touch blah < file1

file1 bevat het root password. blah is owned door root Mooi. Ik ben goed op weg denk ik zo.

kewl, keep us posted

[sverzijl]

tik-tak-tik-tak (ondertussen was je inmiddels al in A'dam geweest, dus wel een beetje opschieten met de remote oplossing

[Verwijderd]

veldhoven -> amsterdam is even goed je gas pedaal in drukken ..lol

[sverzijl]

124km en er staan nog geen files

[Ariejan]

sverzijl schreef op donderdag 15 december 2005 @ 14:22:
124km en er staan nog geen files

Goh. zo'n haast heeft 't niet..en ik wil gewoon graag 'n creatieve oplossing vinden.. lieft samen met wat Tweakers hier die me kunnen helpen.

[MrBarBarian]

sverzijl schreef op donderdag 15 december 2005 @ 14:18:
tik-tak-tik-tak (ondertussen was je inmiddels al in A'dam geweest, dus wel een beetje opschieten met de remote oplossing

tis een een privaat geval.. tik-tak is er dus niet zo erg

[FireDrunk]

kan je uberhaupt iets geupload krijgen?

anders is het toch gewoon
<?
system("su");
system("pwd");
system("cp /home/arie/public_html/ssd.conf /etc/sshd/sshd.conf");
?>
of mis ik iets...

[Ariejan]

thijs_cramer schreef op donderdag 15 december 2005 @ 14:27:
kan je uberhaupt iets geupload krijgen?

anders is het toch gewoon
<?
system("su");
system("pwd");
system("cp /home/arie/public_html/ssd.conf /etc/sshd/sshd.conf");
?>
of mis ik iets...

Ik kan geen PHP bereiken uitvoeren vanuit m'n homedir...

[CyBeR]

Mischien wat laat, maar dat ding hangt in een colo? Daar lopen engineers rond die je gewoon taken kunt laten uitvoeren Die kun je dus instrueren om in te loggen en die config voor je te fixen. Als je geluk hebt loopt er toevallig iemand van je coloboer ook rond en kan die 't voor je doen (hebben vaak meer inzicht waardoor jij minder verbose hoeft te zijn; 'fix de sshd config' volstaat).

En wellicht heeft je coloboer consoleservers om dit soort geintjes voortaan te voorkomen?