[SSH} Mijzelf buitengesloten

[douweh]

Hoi allemaal,

dit is mijn eerste post op dit forum, en ik ben dan ook nog erg onervaren in het hele server gebeuren.. Vandaar dat ik nu een eigen testserver (colo) heb draaien bij TransIP (met de standaard transIP freeBSD distro) om wat dingen uit te proberen.

Gisteren heb ik vanuit de portscollectie apache13-modssl geinstalleerd.
Ging prima draait allemaal ok (nog geen certificaten of dergelijke ingesteld) Maar nu ik na een reboot vandaag probeer te connecten met mijn server via ssh (sshd = openSSH vanuit de ports) krijg ik op mijn mac de volgende melding terug "Permission denied (publickey)". Op de pc klapt putty er gewoon direct uit.

Ik snap niet dat ssh daar ineens om vraagt, voorheen kon ik gewoon met mijn user/pass combi inloggen.

Heeft iemand enig idee hoe ik dit weer normaal krijg?

Ik kan evt wel via een phpscript wat shell commando's uitvoeren, maar ik ik kan in php geen root worden via 'su'.

Alle hulp/uitleg is heel hard welkom!

[wv-]

Je moet eerst een shell starten door bijvoorbeeld een perl programma te laten luisteren op een bepaalde poort en een shell te laten starten als je connecteert. Daarna kan je su/sudo doen (als je webuser in de groep wheel zit) en sshd herstellen. Zo een scriptjes kan je vinden als je eens google't naar perl + remote + shell.

[D. ter Horst]

Toevallig aangezet dat root alleen via een public key kan inloggen? Het staat er best letterlijk, dus ik hoop dat je die heb.

Anders zou het overigens nog via su moeten kunnen, dat is dan wel weer vreemd.

Overigens denk ik dat wv- je bericht verkeerd begrijpt, het gaat hier niet om een app die luisterd op een poort welke op de background dient te draaien, maar de SSH verbinding zelf welke er uit flikkerd (als ik het goed begrijp that is).

[wv-]

Overigens denk ik dat wv- je bericht verkeerd begrijpt, het gaat hier niet om een app die luisterd op een poort welke op de background dient te draaien, maar de SSH verbinding zelf welke er uit flikkerd (als ik het goed begrijp that is).

Ik denk dat jij me verkeerd begrijpt. Hij was via php een manier aan het zoeken om su te kunnen doen. Ik stelde voor om via php een perl script te starten om een remote shell te starten, zodat je su kan doen.

[D. ter Horst]

Maar dan blijf je een probleem houden als apache niet onder root loopt, wat waarschijnlijk het geval is aangezien je dan geen rechten hebt om zoiets te doen ?

[wv-]

dus daar kan je su doen? Maar op een default FreeBSD moet je in de group wheel zitten, dus als hij het aangepast heeft ga je su kunnen doen, anders niet.

p.s.: sorry dat mijn niveau te hoog is voor de standaard webhostingtalker :)

[wonko]

Vandaar dat wv- voorstelt op dan su te doen. Op zich is dit dus je eigen machine "hacken" door een shell remote beschikbaar te maken.

[D. ter Horst]

[...]

p.s.: sorry dat mijn niveau te hoog is voor de standaard webhostingtalker :)

Beetje jammer om dan zoiets te roepen, kun je ook een beetje dubbel opvatten en ik vat het negatief op in dit geval.

[wonko]

Heren, hou het netjes, hier help je de TS niet mee.

[Easewood]

Er moet iets veranderd zijn in de sshd instellingen zo aan je foutmelding te zien - het installeren van Apache / mod_ssl kan dit niet veroorzaakt hebben, zeker niet via ports.

Als je systeem (en dus de TransIP freebsd versie) een beetje beveiligd is moet het onmogelijk zijn een root shell te krijgen via Apache (de www gebruiker). Tenminste, zo zou het moeten zijn.

De enige oplossing die je dan hebt is lokaal in te loggen (tenzij je andere remote opties hebt om de machine te bereiken).

Het handigst (zeker gezien je zelf aangeeft niet ervaren te zijn) is dan ook fysiek naar de machine toe te gaan / iemand in het datacentrum aan te spreken om e.e.a. op te lossen.