Spájzba szerelt, távirányitott szerver, segitseg kellene!

Ubuntu Linux

Üdv. mindenkinek!

Egy új itthoni projekten dolgozom, miszerint a file- és letöltő szerverem monitorral, klaviatúrával és egérrel együtt áthelyezem a spájzba.
Az ötlet onnan jött, hogy bazi sok pénzt bele lehetne ölni a hangtalanitásába, de akkor sem lesz "néma"! Tehát olyan helyre kell tennem ahol senkit sem zavar és a légáramlás is megfelelő.
Nálunk ez a spájz.Hálózaton szeretném távirányitani, most az Xrealvnc-vel (vncserver) bütykölök éppen...
Tudom, hogy ssh-n lenne a legegyszerűbb, de én X-el akarom! =)

Kubuntu 7.04-et használok, firestarter tűzfallal.
A tűzfalat már belőttem, azzal nincs idáig gond.

Kezdeti problémáim:

- Lehetőleg felhsználói bejelentkezés nélkül el kéne inditani a vncservert a felhsználó futtatási szintjén (nem root-ként).

- A vncserver kommunikációjának titkositása, van-e értelme ha csak lan-on vezérlem?!?

- Ha az előzőek már működnek akkor esetleg az interneten keresztüli vezérlés (esetleg hamachi-s VPN kapcsolat, vagy valamelyik másik), de akkor kellene valami megoldás, hogy ha felépül a VPN, akkor lelassitsa a letöltést, hogy ne kerüljön 20 percbe a böngészőröl a torrent kliensre váltani...

Szóval, adottak a problémáim, a segitségetek előre is köszönöm!

  • 3958 megtekintés

( superfly | 2007. 10. 02., k – 22:44 )

1, system("su -c \"vncserver :$vnc_port\" $username");
(Perl, cronbol fut)

2, VNC portot lehet sshval tunnelezni, ha ebben is segitseg kell szolj

3, Az utolso problemara szerintem http://lartc.org/, port prioritassal szerintem meg lassitanod sem kell

AZ elsoben nemtudok mit kifejteni, en crontabba raknek 1 scriptet, megnezi fut-e a server ha nem, indit.

pgrep -u user Xvncserver egy jo indulasi alap

Masodikkal kapcsolatban pedig annyi h a kapcsolat 1 ssh tunelen keresztul megy:

ssh -l user -L5901:localhost:5901 zoolmcfly.myip.hu

Es akkor azon a gepen amin irod, a helyi port 1 ssh tunnelen keresztul a zoolmcfly.myip.hu 5901es portjara lesz huzva

( flimo | 2007. 10. 03., sze – 09:03 )

Hasonlót csináltam, mikor haza kellett vinnem a monitorom, mert az otthoni megdöglött :)

Az automatikus vncszervert úgy oldottam meg, hogy gnome-ban Startup Programs közé betettem, gdm-ben pedig automatikus bejelentkezésre állítottam. Lehet nem a legszebb megoldás, de egyszerű és működik.

( pepo v | 2007. 10. 03., sze – 09:20 )

1, Ha már KDE-t használsz, akkor a Krfb a barátod. (Egy automautikus userbejelentkezés is jól jöhet, ha nem akarsz a spájzban loginelni, ha esetleg nem megy állandóan a géped. -> KDM)
2, Nincs.
3, Azureus plugin, vagy TorrentFlux.

Egyébként ezt én monitor, bill. és egér nélkül oldottam meg. De nekem is kellett az X.

( hrgy84 | 2007. 10. 03., sze – 10:18 )

Én azt az X-nek a VNC pluginjével csinálnám meg. Xvnc-nek is hívják, Gentoo-ra el tudom mondani hogy megy.

Lényegében a realvnc-nek van egy vnc.so állománya, meg egy Xvnc binárisa, a .so-t a X moduljai közé, a Xvnc-t meg a /usr/bin-be kell másolni.

Ezután a gdm/kdm-nek meg kell mondani, hogy X szerver néven ne a standard X-et indítsa, hanem a Xvnc-t, és be kell kapcsolni az XDMCP supportot.

Még jobb, ha a gdm/kdm-ben mindenféle X szerver indítását tiltod, és a Xvnc binárist egy (x)inetd lövi fel, ha szükséges. XDMCP természetesen kell a gdm/kdm-be ez esetben is.

( ZooLMcFly | 2007. 10. 03., sze – 17:18 )

Köszi a hozzászólásokat, kipróbálom az összeset!

A Krfb-vel annyi a bajom, hogy ha win-ből ultravnc-vel csatlakozom rá, rögtön kihal!
Jah, meg még nem jutottam el odáig, hogy ne keljen engedélyeznem a kapcsolódást. (Csak fusson, ha csatlakozni akarok kérjen jelszót és engedjen be.)

Debianban az egyik csomagban van sajna most nem jut eszembe a neve talan a vnc4server.
xorg.conf-ba pedig:
LoadModule: "vnc"
Es mar a *dm et is tolja at. Ez a legegyszerubb, de utobbi idoben ugy vetem eszre, hogy a vnc servert futtato gepen szeret szetesni a kep, de teged ez nem erint :)

vncserver-t inditasz paracssorbol, s csatlakozol hozza, ezzel tobb grafikus terminalt is tudsz inditani.

Vagy x11vnc, xinitd-bol inditassal megoldhato, hogy a *dm-el induljon s mar ezt is tolja at. Nalam kdm-el megy. E leiras alapjan csinaltam. HOWTO: x11vnc (vnc for display :0)

Én is ezt mondtam.

De én azt mondom, felesleges, hogy a X a rendes képernyőt meg a VNC-t is felizgassa, mivel a spejzba úgyse fog senki beülni Quakelni. Szerintem elég, ha egy xinetd felizgatja a Xvnc szervert, ami csak VNC-n figyel, és forwardol XDMCP-n a gdm/kdm felé.

Az én linkem: Xvnc Terminal Server

Persze a XinetD-t nem muszáj pont így beállítani, én egy "normál" X nélküli rendszer esetében a 5900-ra (:0) tenném az első konzolt, egy másikat a 5901-re (:1), mindkettőt egyforma grafikára, és csá. A gdm/kdm meg elrendezi az elrendezendőket.
Ja és ennél a megoldásnál magához a VNC-hez nem kell jelszó, mert az XDMCP kapcsolat úgyis kér. Gondolom a külvilág felé nem providálja.

Ha kell valakinek, kikísérletezhetem a megoldást *buntura, és esetleg tömören feldobom ide a blogba.

Rá kell keresni, hogy a Xvnc binárist mi providálja *buntu alatt.

( th v | 2007. 10. 04., cs – 09:17 )

Hali!
Ha mar a VNC-rol meg Krfb-rol esett szo, lenne egy kerdesem nekem is. Kubuntu 7.04, Krfb beallitva. Amikor VNC-n akarok csatlakozni, nemes egyszeruseggel segfaultol egybol a server es megszakad a kapcsolat. Nem kotheto klienshez, mert tobbfajta klienssel is probaltam. Probaltam mar ujratelepiteni a csomagot, de a gond megmaradt. Talalkoztatok mar ilyen gonddal? Ha igen, mi volt a megoldas?
Udv!
--
TH

( Toma_ | 2007. 10. 04., cs – 09:22 )

Jesszus! A szerverek már a spájzban vannak?! :)

(Bocsi. :))

( ZooLMcFly | 2007. 10. 19., p – 23:09 )

Üdv. midenkinek, féligmeddig sikerült megoldanom a problémát!

1. A krfb kilőve, bármely vnc klienssel csatlakozom, a szerver és a kliens közül valamelyik mindíg elhalálozik 10 mp alatt.
Hiába nyomtam fel .deb-ből újra!

A megoldás egy érdekes progi mégpedig az NXclient, NXnode és NXserver kombó (http://www.nomachine.com)
Tök jól müxik és minden platformon van.

De mivel soha semmi nem elég jó, most az a problémám, hogy ssh-kell hozzá.
Mivel neten keresztül is el akarom érni a gépem, ezért az ssh-t kellene úgy konfigolnom, hogy ne lehessen bejelentkezni rá!
Remélem értitek...

Hát valahogy be kell jutnod az ssh-ba, tehát valamilyen szinten be kell jelentkezz.

Amit tudok ajánlani, az az ssh non-standard portra (x != 22 && 1024

PKI authentikációhoz kell egy kulcspár, ebben a ssh-keygen segít: 


zoolmcfly@melosgep ~$ ssh-keygen -t dsa

Ez két fájlt generál, a ~/.ssh/id_dsa és a ~/.ssh/id_dsa.pub fájlokat. Ezek közül a másodikak a tartalmát hozzá kell fűzni a vnc szerverként használt otthoni gépen a /home/zoolmcfly/.ssh/authorized_keys fájl tartalmához.
Ezek után a /etc/ssh/sshd_config-ban a UsePAM beállítás legyen no, ezzel kiütöd a jelszókérést.
Ezekután a 


ssh zoolmcfly@otthonigep.homelinux.org -p 32023

paranccsal tudsz majd belépni, ahol a otthonigep.homelinux.org helyére a saját DNS-ed/IP-d írandó, a 32023 helyére pedig az a port ahol a ssh várja a logint.

Gondolom a NX* stuffok hozzákonfigolása a ssh részéhez már menni fog.

Arra figyelj, hogy ha valami nem támogatja a non-standard porton figyelő ssh-t, akkor annak így lehet súgni: 


zoolmcfly@melosgep ~$ nano .ssh/config

Fájl: 


# /home/zoolmcfly/.ssh/config
Host otthonigep.homelinux.org
Port 32023

Kapcsold le. :D

Amúgy az ssh beállítható úgy, hogy csak publikus kulccsal engedjen belépni, mással ne. Sőt, azt is megadhatod neki, hogy csak bizonyos felhasználókat engedjen csak kulccsal belépni. A másik portra rakással csak magadat szivatod, védelmi szerepe nem sok van.

Ave, Saabi.

Miért is kell két vállra feküdnie egy gépnek, csak mert be próbálnak törni ssh-n?
Amúgy meg egy portscanner-rel megtalálni a másik SSH port-od is és akkor meg azt fogják DOS-olni.
De ha nagyon nagy a para, akkor csomagszűrőben meg kell határozni, hogy mely IP címek fordulhatnak az adott port-hoz. Ha pedig ez nem jó, mert előre nem meghatározható címekről is el akarod érni a gépet, akkor van arra lehetőség, hogy azokat a címeket, amelyek megadott időn belül megadottnál többször próbálkoznak, a csomagszűrő automatikusan letiltja egy meghatározott időre. (de jó lenne tudni, hogy IPFilter-nél ezt hogy lehet beállítani)

Ave, Saabi.

> van arra lehetőség, hogy azokat a címeket, amelyek megadott időn belül megadottnál többször próbálkoznak, a csomagszűrő automatikusan letiltja egy meghatározott időre. (de jó lenne tudni, hogy IPFilter-nél ezt hogy lehet beállítani)

1) melyik az a csomagturo szuzfal, amelyik ilyet nativan tud? Es hogyan?

2) en aszittem azert van a supportos, hogy elolvassa a manualt a FC helyett.

3) szkriptelni te is tudsz, max nem szeretsz. Tessen logolni, aztan X idonkent feldolgozni a logot es lehet blokkolni. De mindig hozza szoktak tenni, hogy tokeletesen jo arra, hogy kitiltsuk a gep elerhetosegebol a DNS-szerverunket, az NTP-szerverunket, a DHCP-szerverunket, stb.

Ha jól értem, akkor ilyesmire gondol: 


    iptables -A INPUT -m tcp -p tcp --dport 22 -m state --state ESTABLISHED -j ACCEPT
    iptables -A INPUT -m tcp -p tcp --dport 22 -m state --state NEW \
             -m hashlimit --hashlimit-name sshlimit --hashlimit-mode srcip \
             --hashlimit 1/minute --hashlimit-burst 3 -j ACCEPT
    iptables -A INPUT -m tcp -p tcp --dport 22 -j DROP

1, IPtables (a hogyanra Jo-Hans tud válaszolni én nem)
2, természetesen ezért van. Viszont neked annyit kell segíteni, hogy nem marad időm a saját problémáim megoldására. :-P
3, nem tudom, nálad hogy működnek az említett szolgáltatások, nálam ezek nem a 22-es portot használják. Persze tudom, minden konfiguráció kérdése :-P

Ave, Saabi.

3) érdekes, én azt olvastam, hogy nem csak UDP-t, de bizonyos emberek még TCP-t is tudnak "hamisítani". Szóval kaphatsz az SSH-portodra menő csomagot látszólag a DNS-szerveredtől. Akár többet is, mint amennyit a limited megenged. És akkor máris kitiltottad.
És ha azt mondod ehhez belső hálón kell lógni - ott meg mindenkiben megbízunk, akkor nem is értem, miért szoktátok bekapcsolni a screenlockert.

Legjobb tudomásom szerint a DNS server nem kezdeményez kapcsolatot a kliensek felé. Tehát a DNS server-t by default kitilthatom. Csak olyan csomagokat engedélyezek felőle, amelyek tőlem kezdeményezet session-höz tartoznak. (SPI mode? stateful packet? vagy mi a szép neve ennek a megoldásnak?) Másfelől a kitiltás nem permanent, hanem időleges. Ha ezt még megfűszerezem egy caching-only nameserver-rel a kliensemen, akkor az egy perces kitiltás máris nem lesz olyan fájdalmas a névfeloldás szempontjából. Egy DOS támadás ellen viszont máris elég.
Belső hálózatban miért bíznék meg jobban mint egy külsőben? Pláne egy akkora hálózatban mint a mienk?
A screenlockert pedig Emil miatt kezdtük bekapcsolni. Bár Ő már elköltözött a másik épületbe, de amíg velünk volt, ahogy lezáratlan gépet talált, rögtön küldött róla egy hülye levelet mindenkinek. :-) Persze ettől függetlenül is célszerű lezárni, mert mindenféle alakok is járkálnak felénk. Vagy egy randa szakállas is, tőle mindig tartok hogy belenyúlkál a gépembe. :-P

Ave, Saabi.

( cheeseghost | 2007. 10. 20., szo – 08:44 )

Hat en biztos nem kinlodnek a vnc-vel. Probaltam, es azt mondom, jobb, hatekonyabb az ssh - x11 forwarding. Egy xfce-t futtatva, kivaloan kezelheto minden jatekszer.
En hasonlot muveltem, csak a ciposszekrenyben, igy a kajat nem fujja tele porral.
mondjuk en leszedtem minden felesleges fogyasztot rola. se floppy, se cd, se monitor, se bili... 6 eve csak aramszuneteknel all le, de ujraindul.

A VNC-nek egyik legnagyobb előnye, hogy nincs olyan platform, amire ne lenne vnc kliens - ilyen avagy olyan. Azonfelül a vnc talán picit kissebb sávszélt igényel mint a x11 forward, ami úgyszint nem elhanyagolható szempont, lévén a lakossági internet általában felfelé nagyon szűk.

De szvsz a VNC-nek perdöntő előnye az ssh -X megoldással szemben, hogy ha megszakad a kapcsolat gond nélkül akár teljesen más gépről ujra kapcsolódhatsz és onnét folytatod ahol abbahagytad.

Én adva a biztonságra távolról csak ssh kapcsolatot engedélyezek és a vnc 5900 portját tunnelezem.

( mrev | 2007. 10. 20., szo – 23:15 )

a file- és letöltő szerverem monitorral, klaviatúrával és egérrel együtt áthelyezem a spájzba

Jó, de minek a monitor, klaviatúra, egér. Gondolom, nem akarsz te is beülni a spájzba.

Nem értem, miért van ennyi híve a VNC-nek. Akár az

ssh -X

akár az

X -query

sokkal jobb. Amit a terhelésről írnak, az szamárság. Az ssh és X is platformfüggetlen. A cygwines X van olyan jó, mint a linuxos. A ssh titkosít, de LAN-on, tűzfal mögött nincs jelentősége a titkosításnak.

--
CCC3

Hát, modemes kapcsolaton valóban okozhat problémát az X "hatalmas" sávszélességigénye, de szerintem a mai otthoni 100Mb-es hálózatokon észrevehetetlen. Gondoljunk bele, a régi X terminálok legjobb esetben is 10Mb-es hálózaton dolgoztak!

Ave, Saabi.
ps: tehát, ha félreérthető voltam, egyetértek veled

Jó, de azt is tessék már hozzászámolni, hogy pl. nem csak belső, hanem külső hálóról is hozzá kéne ahhoz a szerverhez férni. A lakossági ADSL-eknek a feltöltési irénya elég ritkán éri el a 1MBitet (yó, tudom, van ilyen, de könyörgöm, ugye nem mindenki használ ilyent?). Akkor hol is vannak a régi X terminálok? A bőség zavarával küzdöttek.

Van valaki, aki mondjuk internet felől is használt ilyent? Meghallgatnám a véleményét.

Én elég gyakran használok ilyet (ssh -X) többféle felállásban. (Nem vagyok profi.)

A -C kapcsolóról még nem hallottam, de ki fogom próbálni.

Szóval gyors hálózatról egy mo-i otthoni gép felé megy a dolog, de lassű.

Az itteni otthoni gépemről egy szerveren keresztül (tehát két ssh -X en keresztül) a munkahelyi gépemre megy a dolog, de szintén lassú.

Viszont egy norvég egyetemi hálózatról a munkahelyi gépemet nagyon kényelmesen elérem, ugyancsak ez volt egy izraeli egyetemi gépről (azaz teljesen használható, nem lassú).

Szóval szerintem akkor volt a dolog lassú, ha az egyik gép otthoni (ADSL vagy kábeles net), de lehet, hogy a -C ezen tud segíteni. Ki fogom próbálni. Gyors hálózatról gyors hálózatra probléma nélkül ment a sima ssh -X.

Csaba

Aham. Nekem a gyors->"lassú" háló irány az érdekes. Ezért mondom, hogy az X sávszélzabáló, csak egy Ethernet kategóriájú hálón belül (>=10MBit fel/le) megfelelő, de ha valahol van egy picit is lassú háló, ott meggebed. -C kapcsoló: Hát, lehet, hogy segít, de olyan nagyon sokat nem hiszem. Bár... a franc tudja.

( ScOut3R | 2007. 10. 22., h – 19:27 )

Én egyáltalán nem szenvednék az X-szel, meg az X-es távoli vezérléssel. Ez olyan windows-os... Szerintem torrentflux a nyerő, én is ezt használom a "szerveremen". Távolról is el lehet érni, távolról is le lehet szedni a letöltött dolgokat. Hogyha a szervert kell bütykölni akkor meg ssh.

+1

Adott egy ötletet ez a téma. Valami régi, kukába szánt notiból (hibás/törött kijelző nem akadály) + USB pendrive-ból össze lehetne tákolni otthonra egy ilyesmit, esetleg dsl linux-al (swap+var+tmp mehetne a noti vinyójára)...

Egy P1 120-as noti 16M RAM-al akár elég is lenne a feladatra (mutella + ctorrent kliensekkel), és talán kevesebbet is fogyasztana, mint egy sufni desktop...

Nem akar valaki véletlenül hozzám vágni egy ilyen notit? Ami van, az már foglalt könyvolvasási célokra :-)))

---
Mondjon le!

Az X-et a Xserver-re teszed. :D ssh X forward-nál is a te gépeden van az X server. Nem ártana ismerni az X működését, mielött gúnyos hangvételbe fogsz.

Amúgy meg bármi meglepő, vannak grafikus unix programok is, melyeknek nem feltétlen van karakteres változata.

Ave, Saabi.

Bocsánat a gúnyos hangvételért. Én a hozzászolásomat a téma indítójának hozzászólásához intéztem, és az ő feladatára nem kell grafikus felület. Hogyha valakinek oracle kell az telepítsen X-et. MySQL+torrentfluxhoz nincs rá szükség.

Akkor hogy ismerjem az X működését: nem szükséges X a másik gépen ahhoz, hogy grafikusan állítgassam a dolgokat? (Vagyis az adott szolgáltatás grafikus beállító programját futtassam.)

Egy dolog a grafikus felületen való konfigolás, más dolog az X folyamatos futtatása.

Nekem pl. egy xinetd húzza fel a VNC-kapcsolatokhoz a portot, és csak kapcsolódáskor indul el az X. Ez bizonyos értelemben kétszeres védelem:
1) A gépen nem automatikusan indul a xinetd, tehát csak akkor lehet VNC-n belépni, amikor Én szeretnék
2) A felhúzott xinetd mellett is csak akkor indul el az X, amikor a VNC-n át abba belépek. Így folyamatosan sosincs X a memóriában, mindig csak a beléptetett session idejére. A VNC-t külön le lehet jelszóval védeni.

Megközelítheted így is, úgy is. Mivel az ablakkezelő is csak egy alkalmazás az X felett, azt futhat a kliensen is, de futhat az (X) server-en is. Vagy ki is hagyhatod, bár akkor kissé kényelmetlenné válik az ablakok használata.

Próbáld ki azt, hogy az X terminálodról (mely esetünkben az X server), vagy a desktop-od X-es felületéről belépsz egy másik gépre és azon beállítod a DISPLAY változót, hogy a te gépedre mutasson. Ha ekkor elindítasz egy xclock-ot akkor annak a képe a másik gépről jön, de az ablakkeretet már a te gépeden futó ablakkezelő rajzolja, az nem járja meg a hálózatot.
(persze a két gép közti kapcsolathoz nem árt átengedni a 6000-es portot a csomagszűrőn és az X alatt is engedélyezni kell, hogy a másik gép oda képet küldjön. Ja, és az sem árt, ha a desktop-on az X-nek nincs letiltva a hálózatkezelés. Vagy ssh -X, amikor is az X server felől nézvést minden a localhost-ról jön. Ekkor az X server nem tud arról, hogy a megjelenített ablak egy másik gépről származik.)

Ave, Saabi.

( ZooLMcFly | 2007. 11. 05., h – 10:29 )

Üdv. mindenkinek!
A project félig meddig befejeződött, a gép áthelyezése megtörtént, már csak néhány szolgáltatás konfigurációja van hátra!

Egy kép, csak mert, hátha... http://images.netbag.hu/20071105/10213340251.jpeg
Gépterhelés (htop): http://images.netbag.hu/20071105/10274555834.jpeg
Köszönöm mindenkinek a segitséget!

A végleges megoldás: Ssh-n keresztül screen-ben fut egy rtorrent, ami be lett állitva, hogy figyeljen egy mappát, amit ftp-n érek el. Ebbe a mappába pakolászom a torrent fileokat, amit az rtorrent szépen be is rak a listájára.

Próbálgatások után én is elvetettem az X-et. Lan-on még jó lett volna, de a 4 megás net bazi lassú internet felőli vezérléshez!

Viszont, van még 1-2 dolog, amit ajánlhatnátok nekem, mégpedig viruskergetőt valamint tűzfalat!

Üdv.: ZooL