Bekijk Volledige Versie : Remote admin
Hey ik ben bezig met een servertje onder fedora (v3) te maken en nu zoek ik iets van een remote admin, zodat ik via mijn windows bak de server kan beheren.
IK heb zelf veel ervaring met Radmin 2.1 maarja die draait niet op Fedora is tenslotte windows. (ben pas nieuw in het linux/fedora gebeuren dus als ik iets zeg wat niet klopt dont shoot me)
Met welke programmas hebben jullie goede ervaringen?
Mvg,
Bart Jaminon
Putty ben ik net ook ergens tegen gekomen, zal dat es gaan proberen,
Thx alvast, meer tips blijven welkom,
Triloxigen
01/03/05, 23:29
PuTTy en als je lui bent WinSCP
Meer heb je niet nodig :)
Lui ligt het niet aan,
Heb de makkelijkste manier nodig,
ben leek, qua linux...
Voor PuTTy zal je toch echt Linux commando's moeten leren!
ColoProvider
01/03/05, 23:37
Origineel geplaatst door debeste
Lui ligt het niet aan,
Heb de makkelijkste manier nodig,
ben leek, qua linux... Je krijgt het het snelste onder de knie door er gewoon mee aan de slag te gaan, veel op te zoeken en vooral niet aarzelen om fora af te struinen en google arm te maken door flink veel te zoeken :)
Mocht je echt uit het niks beginnen is een boekje over Fedora altijd handig voor een snelle start.
Origineel geplaatst door Xerious
Voor PuTTy zal je toch echt Linux commando's moeten leren!
PuTTy doet ook cut & paste hoor. ;)
Dan zou ik iig nog adviseren om de commando's over te tikken. Dan pak je ze wat makkelijker op :)
Origineel geplaatst door Remigius
Dan zou ik iig nog adviseren om de commando's over te tikken. Dan pak je ze wat makkelijker op :)
Probleem is dat je met alleen overtikken er nog niet bent.
Het gaat er uiteindelijk ook om dat je weet wat je doet.
Verder is een algehele kennis van je systeem wel een vereiste, omdat je anders nog niets ermee kunt.
Alhoewel daarin apt een redelijk lapmiddel schijnt te zijn, maar erg deftig vind ik het niet. ;)
SSH server installeren en zoals men reeds zei: SSH client Putty
Origineel geplaatst door Jacobs.T
SSH server installeren en zoals men reeds zei: SSH client Putty
Of anders gewoon een Telnetd icm. telnet. ;)
Origineel geplaatst door M-BahZ
Of anders gewoon een Telnetd icm. telnet. ;)
NEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE!
Origineel geplaatst door Frangkje
NEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE!
Er mankeert anders niets aan telnet hoor. ;)
Mits je het over een SSL tunnel smijt en je de fundamentele onveiligheden in telnetd voor lief neemt is het idd prima te doen.
Origineel geplaatst door MikeN
Mits je het over een SSL tunnel smijt en je de fundamentele onveiligheden in telnetd voor lief neemt is het idd prima te doen.
Welke fundamentele onveiligheden in telnet doel je op ?
En waarvoor een SSL tunnel ?
Je haalt je mail toch niet op via je telnet sessie, of wel ? ;)
Telnetd is een zeer oude applicatie, welke veel te veel werkzaamheden als root uitvoert, iets wat in het verleden al aardig wat ernstige lekken tot gevolg heeft gehad.
En misschien haal ik m'n mail niet op via telnet, maar ik verstuur er wel het root wachtwoord overheen van de server waar m'n mail op staat, what's the difference. Jup, je kan hem uiteraard ook gewoon firewallen op IP e.d., maar het idee blijft hetzelfde, namelijk dat je via SSH wel vanaf een untrusted netwerk kan connecten, en bij een niet versleutelde telnet verbinding je maar erop moet vertrouwen dat je verkeer niet verkeerd beland.
Dan missen we nog even het stukje dat je met telnet geen enkele verificatie heb of de bak waar je naar connect ook wel werkelijk de bak is waar je naar wil connecten.
Origineel geplaatst door MikeN
Telnetd is een zeer oude applicatie, welke veel te veel werkzaamheden als root uitvoert, iets wat in het verleden al aardig wat ernstige lekken tot gevolg heeft gehad.
Er zijn wel telnetd's die dit probleem al geruime tijd verholpen hebben.
Buitendat is er geen wezenlijk security verschil tussen het runnen van welk soorig daemon dan ook.
Security aspecten komen meer kijken bij de authenticatie procedures en de code danwel de functies van een daemon.
Of een ding nou in plaintxt communiceert of encrypted doet hier niet aan af.
Een httpd op jouw server is toch ook niet direct _de_ bottleneck qua security ?
Origineel geplaatst door MikeN
En misschien haal ik m'n mail niet op via telnet, maar ik verstuur er wel het root wachtwoord overheen van de server waar m'n mail op staat, what's the difference.
Wie zegt dat jij je rootpass verstuurd ?
Authenticatie kan op tig aantal andere manieren.
Werken met wachtwoorden is nogal veroudert en ook weinig respectabel, iets wat door banken gelukkig ook erkent wordt.
Overigens prefereer ik persoonlijk het werken met sudo.
Raad ik je overigens wel eens te gaan lezen over hardening van je Linux systeem, omdat anders sudo nog wel eens een probleem op zich zou kunnen worden.
Origineel geplaatst door MikeN
Jup, je kan hem uiteraard ook gewoon firewallen op IP e.d., maar het idee blijft hetzelfde, namelijk dat je via SSH wel vanaf een untrusted netwerk kan connecten, en bij een niet versleutelde telnet verbinding je maar erop moet vertrouwen dat je verkeer niet verkeerd beland.
Whow... dan kunnen ze sniffen hoe je je nieuwe Apache httpd compiled.
Neej, dat soort bedrijfsgeheimen houd je inderdaad liever voor jezelf. ;)
Origineel geplaatst door MikeN
Dan missen we nog even het stukje dat je met telnet geen enkele verificatie heb of de bak waar je naar connect ook wel werkelijk de bak is waar je naar wil connecten.
Verificatie depends uiteraard helemaal op hoe je het een en ander implementeerd.
RebornVampie
02/03/05, 23:58
Misschien een stomme opmerking maar waarom moet linux zo lastig zijn. Als het net als windows (firedeamon opstarten, servertje erin adden en klaar) clickable was dan had je toch ook geen last van al die vervelende commands. Het msdos tijdperk is toch voorbij. Ik heb trouwens (wil geen discussie aangaan) slechtere ervaring met linux bakken dan met windows bakken.
Origineel geplaatst door RebornVampie
Misschien een stomme opmerking maar waarom moet linux zo lastig zijn. Als het net als windows (firedeamon opstarten, servertje erin adden en klaar) clickable was dan had je toch ook geen last van al die vervelende commands. Het msdos tijdperk is toch voorbij. Ik heb trouwens (wil geen discussie aangaan) slechtere ervaring met linux bakken dan met windows bakken.
Wellicht dat je hier beter een apart topic voor aan kunt maken.
Allereerst is Linux niet moeilijker of lastiger als Windows.
De meeste Linux distributies houden zich aan de Filesystem Hierarchy Standard waarmee Unixes, Linux en BSD distributies en eventueel andere systemen die deze standaard adopteren, een universeel filesystem krijgen.
Data zal altijd op dezelfde plekken verkrijgbaar zijn, ongeacht het systeem.
Hierbij wordt ook weer een strikt onderscheid gemaakt in het soort data.
Vooral bij het maintainen van meerdere systemen is dit erg welkom.
Verder is iets textbased of middels een GUI doen niet hetverschil tussen moeilijk en makkelijk.
Dit is enkel de gebruikerservaring.
Wanneer deze bij jou met "grafisch" te beinvloeden valt raad ik jou aan eens te rade gaan bij jezelf.
Of iets clickable is of met commando's gedaan moet worden maakt uiteindelijk weinig uit.
We weten waar de programma's staan door de FHS, deze staat in het PATH van te doorzoeken directories en we weten hoe het programma heet.
Met een GUI heb je exact hetzelfde.. daarbij moet je ook weten hoe het programma heet.
Als Linux op de commandline een tekstverwerker zal hebben met de naam word, zal die prolly ook gewoon met het commando "word" aan te roepen zijn.
Indien we gelijk het document aan willen roepen vanuit dezelfde directory zou "word filename" in zo'n geval genoeg zijn.
In het geval van Windows zal er echter weer geklikt moeten worden.. lekker makkelijk.
Goh, je moet weten welke tekstverwerker geinstalleerd is.
Maaruhm.. is dat in Windows ook niet het geval ?
Om nog verder in te gaan op Linux vs. Windows.
Windows is qua opzet inferieur aan Linux.
Allereerst is bij Windows in beginsel te weinig rekening gehouden mbt. multiuser, wat bij Linux van meet af aan al gedaan is.
Verder depends Windows erg veel op RPC's wat erg opmerkelijk is, en waarvoor Microsoft tot op heden ook nog geen fatsoenlijke verklaring heeft kunnen geven.
Feit is ook dat daar de meeste problemen vandaan komen.
De doemdenkers onder ons zullen waarschijnlijk denken aan spionage danwel remote takeover doelen. ;)
Tja.. en Windows is ook nog eens een bijhoorlijke waste of resources op een serversysteem, als je het mij vraagt.
Overigens zeg ik op dit punt niet dat Windows qua werking inferieur is aan Linux, of BSD.
Het kan natuurlijk zijn dat de Linux en BSD kernels hevig inferieur zijn aan de Windows en meer slechte en vulnerable code bevatten als die van de Windows kernel.
Kan uiteraard ook zijn dat Microsoft dingen kan, die de Linux en BSD coders niet voor mogelijk hielden.
Alhoewel ik het persoonlijk maar even bij mn Linux systeem houd.
Origineel geplaatst door M-BahZ
Er zijn wel telnetd's die dit probleem al geruime tijd verholpen hebben.Ik had het hier over de standaard netkit telnetd die je normaal gesproken krijgt wanneer je telnetd installed, er zullen inderdaad wel veiligere telnetd's zijn :)
Wie zegt dat jij je rootpass verstuurd ?
Authenticatie kan op tig aantal andere manieren.Raad ik je wel aan dat erbij te zeggen voordat je in het topic van iemand die duidelijk nieuw is met Linux gaat roepen dat hij ook telnetd kan gebruiken.
Whow... dan kunnen ze sniffen hoe je je nieuwe Apache httpd compiled.Er gaan bij mij over sommige SSH sessies echt wel gegevens die ik niet overal zou willen laten rondslingeren. Maar dat hangt er maar net vanaf waar je je SSH voor gebruikt.
Verificatie depends uiteraard helemaal op hoe je het een en ander implementeerd.
Vertel eens hoe je het zou implementeren met telnet, ben wel benieuwd eigenlijk :)
En RebornVampie, ieder OS heeft zn sterke en zwakke punten. Ik ga op de meeste punten wel met M-BahZ mee wanneer het gaat om beheer, maar vindt het design van Windows niet op alle punten inferieur aan dat van Linux. Als jij beter met Windows om kan gaan, en je kan daarop doen wat je wil, doe het dan daar gewoon op :)
Origineel geplaatst door MikeN
Ik had het hier over de standaard netkit telnetd die je normaal gesproken krijgt wanneer je telnetd installed, er zullen inderdaad wel veiligere telnetd's zijn :)
Inderdaad.
Ik denk persoonlijk dat er meer zinnige telnetd's zijn als sshd's.
De meesten zijn ook niet vatbaar of vatbaar geweest voor de problemen die de SSHd's kennen (danwel gan kennen) of gekent hebben. ;)
Origineel geplaatst door MikeN
Raad ik je wel aan dat erbij te zeggen voordat je in het topic van iemand die duidelijk nieuw is met Linux gaat roepen dat hij ook telnetd kan gebruiken.
Ja en nee.
Aangezien telnet in zijn oorspronkelijke vorm gewoon plaintext gebruikt zou het misschien voor de handliggend zijn hier nogmaals op te wijzen...
Aan de andere kant is het tot op zekere hoogte nutteloos om dit te melden.
We hoeven mensen toch ook niet uit te leggen dat de kernels op kernel.org vulnerable zijn, en mensen die dingen nog moeten patchen ? ;)
Origineel geplaatst door MikeN
Er gaan bij mij over sommige SSH sessies echt wel gegevens die ik niet overal zou willen laten rondslingeren. Maar dat hangt er maar net vanaf waar je je SSH voor gebruikt.
Correct.
Doorgaans gebruiken de meesten SSH en telnet alleen voor system maintance.
Men wordt geacht de security aspecten hiervan te kennen.
Zaken als mail en dergelijke is een implementatie op zich en het is dan ook zaak dat mensen zelf hierbij overdenken hoe het een en ander aan te pakken.
Origineel geplaatst door MikeN
Vertel eens hoe je het zou implementeren met telnet, ben wel benieuwd eigenlijk :)
Ik zal hier even een erg kort door de bocht zijnde antwoord opgeven. ;)
Een "authentication protocol" valt doorgaans met veel soorten daemons te implementeren.
Alhoewel de keuzes voor deze implementaties vaak weinig origineel zijn. ;)
Een afdoende identificatie van client/server middels keys is overigens wel gewoon mogelijk.
Een korte zoektocht op google zal je ook gelijk bruikbare alternatieven bieden.
Echter liet ik al reeds wat vallen over het niet hoeven te gebruiken van een rootpass, maar natuurlijk is sudo ook niet heilig.
Immers moet je alsnog inloggen op je systeem, en of je dat nu doet met een account welke sudo kan gebruiken of met root zelf maakt weinig verschil.
Het toverwoord hiervoor is echter "One time passwords".
De implementatie hiervan is nog niet bij iedereen bekend, maar google levert je een schat aan informatie hierover.
One time psswords laat zich in grote lijnen vergelijken met de TAN codes zoals gebruikt door de Postbank.
In principe raad ik iedereen aan een implementatie hiervan ook zeker te overwegen.
Met name voor ftp en telnet (en in mindere mate ssh) zal dit zeker wel een toegevoegde waarde kennen.
Kort samengevat leent telnet zich prima voor proffesionele toepassingen.
De meeste punten waarop SSH beter zou zijn kunnen relatief makkelijk weerlegt worden.
Verder rammelt het dusdanig vaak aan de SSH implementaties, dat ik niet lukraak SSH zal aanraden. ;)
Edit: de volgende link bevat al een beetje informatie. ;)
http://www.evilcoder.org/freebsd_html/one-time-passwords.html
Origineel geplaatst door M-BahZ
De meesten zijn ook niet vatbaar of vatbaar geweest voor de problemen die de SSHd's kennen (danwel gan kennen) of gekent hebben. ;)Is op zich een punt, encryptie zooi = meer code = meer kans op fouten :)
We hoeven mensen toch ook niet uit te leggen dat de kernels op kernel.org vulnerable zijn, en mensen die dingen nog moeten patchen ? ;)2.6.11 is pas uit :p
Maar ik ben sowieso niet echt blij met het security beleid zoals dat op dit moment door de Linux kernel maintainers gevoerd wordt. Toevallig kwam ik een tijdje terug deze column tegen, welke op zichwel een paar goede punten heeft http://www.securityfocus.com/columnists/296
Maar we dwalen af :p
Een afdoende identificatie van client/server middels keys is overigens wel gewoon mogelijk.
Een korte zoektocht op google zal je ook gelijk bruikbare alternatieven bieden. Tja, die kon ik dus niet zo snel in combinatie met telnet vinden, maar ze zullen er dus wel zijn :)
Echter liet ik al reeds wat vallen over het niet hoeven te gebruiken van een rootpass, maar natuurlijk is sudo ook niet heilig.
Immers moet je alsnog inloggen op je systeem, en of je dat nu doet met een account welke sudo kan gebruiken of met root zelf maakt weinig verschil.Dat is mijns inziens ook een groot "probleem" aan sudo. Afgezien van het feit dat m'n huidige productieomgeving nog steeds aan veel veranderingen onderhevig is, en ik dus vaak genoeg echt een rootshell nodig heb. sudo kan echter handig zijn voor sommige (veel?) dagelijkse admin taken.
Het toverwoord hiervoor is echter "One time passwords".
De implementatie hiervan is nog niet bij iedereen bekend, maar google levert je een schat aan informatie hierover.Ik dacht al dat het daarop zou uitkomen. One time passwords vindt ik aan de ene kant een goed idee, aan de andere kant moet ik altijd een lijst meeslepen (of iedere dag een nieuw lijstje in mn kop stampen ;)) wat ik gewoonweg niet handig vind. Uiteindelijk vindt ik dat je altijd een afweging moet maken tussen security en usability, welke bij mij iets meer richting de usability is gegaan. Dat het voor plaintext protocollen een grote toegevoegde waarde heeft (soms zelfs noodzakelijk) heb je volledig gelijk in.
Verder rammelt het dusdanig vaak aan de SSH implementaties, dat ik niet lukraak SSH zal aanraden. ;) Ach, de laatste tijd is het weer rustig (*klopt af*) :D
Origineel geplaatst door MikeN
Is op zich een punt, encryptie zooi = meer code = meer kans op fouten :)
Helaas _teveel_ fouten als je het mij vraagt. ;)
Origineel geplaatst door MikeN
2.6.11 is pas uit :p
Maar ik ben sowieso niet echt blij met het security beleid zoals dat op dit moment door de Linux kernel maintainers gevoerd wordt. Toevallig kwam ik een tijdje terug deze column tegen, welke op zichwel een paar goede punten heeft http://www.securityfocus.com/columnists/296
Maar we dwalen af :p
Het huidige beleid is inderdaad een punt van discussie.
Overigens is hetzelf gaande bij de maintainers van andere projecten.
Gelukkig zijn er een aantal goede patchsets welke doen, wat volgens velen, de kernel maintainers hadden moeten doen.
Een aantal patchsets zijn ook uiterst experimenteel, en brengen op hun beurt weer stabiliteits en security problemen met zich mee.
In de toekomst zal het denk wellicht nog wel positief kunnen zijn voor de algehele ontwikkeling van de Linux kernel.
Maar ik denk dat het op dit moment voornamelijk een barriere opwerpt.
Verder was een announcement op kernel.org aangaande wijzigingen in het beleid bij de kernel maintainers wel op z'n plaats geweest.
Veel systeembeheerders werken namelijk al jaren volgens een vastgeroest patroon.
Origineel geplaatst door MikeN
Tja, die kon ik dus niet zo snel in combinatie met telnet vinden, maar ze zullen er dus wel zijn :)
Ik vermoed dat een zoektocht op "secure telnet" of iets als dat wel wat hits oplevert.
Origineel geplaatst door MikeN
Dat is mijns inziens ook een groot "probleem" aan sudo. Afgezien van het feit dat m'n huidige productieomgeving nog steeds aan veel veranderingen onderhevig is, en ik dus vaak genoeg echt een rootshell nodig heb. sudo kan echter handig zijn voor sommige (veel?) dagelijkse admin taken.
Voor de meeste taken zal sudo inderdaad zondermeer voldoen.
Verder zorgt sudo bij de meeste mensen wellicht ook voor een stukje bewustwording van het multiuser gebeuren in Linux en security in het algemeen.
Overigens geheel terzijde sta je sudo natuurlijk niet aan alle gebruikers van het systeem toe, maar enkel aan een bepaalde group.
Dit had jij al door denk ik, maar wellicht even interessant voor de mensen die meelezen. ;)
Origineel geplaatst door MikeN
Ik dacht al dat het daarop zou uitkomen. One time passwords vindt ik aan de ene kant een goed idee, aan de andere kant moet ik altijd een lijst meeslepen (of iedere dag een nieuw lijstje in mn kop stampen ;)) wat ik gewoonweg niet handig vind. Uiteindelijk vindt ik dat je altijd een afweging moet maken tussen security en usability, welke bij mij iets meer richting de usability is gegaan. Dat het voor plaintext protocollen een grote toegevoegde waarde heeft (soms zelfs noodzakelijk) heb je volledig gelijk in.
Ik denk dat one time passwords voor communicatie in plaintext de enige deftige methode is, waar security vereist is.
Als je wat shellaccountjes host voor klanten alszijnde een shellhost maakt het natuurlijk niets uit of zo'n accountje een keer gekraakt wordt.
Immers ga je er als host toch wel vanuit dat de halve wereld toegang heeft tot je servers, omdat jij niet in kunt staan voor wat je gebruikers aan logingegevens laten lekken, of vulnerable webscripting hebben. ;)
Maar voor bijvoorbeeld FTP zie ik persoonlijk weinig goede alternatieven als je op safe wilt spelen.
Ik denk dat je voornamelijk bij bedrijven een groot aanzien zult genieten wanneer je gebruik zult maken van one time passwords.
Tuurlijk usability speelt ook een rol, maar voor je eigen accounts kan je eventueel besluiten geen one time passwords toe te passen.
Beter is het misschien gewoon een keertje opnieuw in te loggen.
Als je echt de hele dag door op het systeem aan het werk bent kan je natuurlijk gewoon ingelogt blijven.
Uiteraard lock je dan wel even de terminal, als je de pc verlaat. ;)
Origineel geplaatst door MikeN
Ach, de laatste tijd is het weer rustig (*klopt af*) :D
Stilte voor de storm ? ;)
Probleem is overigens ook dat veel zaken nog altijd niet geraporteerd worden.
Wat wel vaker gebeurt met security related issue's.
Wie doet jou wat als jij je systeem met GPL software binnen je bedrijf volledig patcht en verder wijzigingen niet doorspeelt naar de community.
Schade lijd de community immers niet, door jouw toedoen...
Je breekt met de GPL licentie en mag het product eigenlijk niet installeren.
Maar wat als je het vervolgens wel installeerd... ze kunnen (helaas) niets beginnen.
Het is natuurlijk bij opensource wel snel zo dat je snel de concurrent op weg helpt door te doneren... ;)
Je breekt niet eens met de GPL licentie, zolang je het product binnen je bedrijf houdt :) De GPL zegt tenslotte alleen wat over de distributie van broncode/programma's en niet over het gebruik.
Maar het feit dat er security bugs zijn die niet gerapporteerd worden blijf je altijd houden. Er zijn zelfs vendors die er bewust voor kiezen security problemen niet te fixen of te melden, of ze wel te fixen, maar niet te melden. Een spijtige zaak, maar wat doe je eraan (behalve een andere vendor zoeken natuurlijk ;) )