VNC - používáme vzdálený desktop (diskuse)

[petr_p]

vncviewer má paramentr -via, kterým lze určit SSH server, přes který se automaticky sestaví tunel.

[petr_p]

Máte někdo skušenosti s přístupem přes VNC na Mac OS X server? Co jsem zjišťoval, tak Apple si nechutně pozměnil identifikaci verzi RFB protokolu, takže klient se nedokáže se serverem dohodnout.

[m]

funguje mi z Windows, klient tightVNC, na desktopový MacOSX 10.4.9

[Marko]

nebolo by jednoduchsie pouzit stunnel?

[Michal Vyskočil]

Možná ano, ale byl jsem líný jej studovat, když přes ssh to jde taky

[Miloš Kozák]

Heslo v plaintextu přenášeno neni.. Ale používá kapku jinou metodu, ale máte pravdu bezpečná také moc neni. Ale rozhodně heslo po síti nechodí.

[Leoš Literák]

Ani kdyz na te vzdalene masine spustite treba internetovy prohlizec a pripojite se do sve banky? Posila prece vsechny udery do klavesnice, ne?

[CEST]

jestli ma nejake jednoduche sifrovani nebo to posila plain text je relativne jedno. Kdyz uz je nejakej sitar dost zdatnej na pouziti tcpdump/Wiresharka/Etherealu, tak si dokaze najit program na dekodovani kodovanyho streamu VNC. Pokud je to BFU, tak zrejme nebude vedet, o cem je tcpdump/wireshark/ethereal a tudiz je jedno, jestli se to koduje nebo ne. Problem je, ze proste neni implementovane zadne spolehlive sifrovani.

Tak ano, kdyz se z vnc serveru bezpecne prihlasujes do sve banky, ale na svuj vnc server se pripojis primo, tak muze nekdo odposlouchavanim dekodovad poslane klavesy. Co jsem ted letmo kouknul do specifikace RFB protokolu, tak KeyEvent posila keysym, coz neni primo ASCII klavesy, ale X reprezentace sltacene klavesy, takze v tcpdump/wiresharku nebude primo videt znak, ale da se jednoduse dekodovat.

[Semo]

jestli ma nejake jednoduche sifrovani nebo to posila plain text je relativne jedno.

To je sice pravda, ale da sa to spravit jednoducho a predsa inteligentne. Tak ako je spravene AuthDigest v HTTP. Server ti posle nahodny retazec, ty k nemu na strane klienta pripojis svoje heslo a cele to prezenies hashovacou fciou (napr. SHA1) a vysledok posles serveru. Ten je schopny spravit to iste, takze porovnanim vyslednych retazcov vie server overit, ci klient pozna heslo alebo nie. Nie je to odolne na man_in_the_middle utok, ale na zabranenie odpocuvania to staci.

[CEST]

Jojo, takhle funguje APOP u POP3. To je ale jenom pro prihlaseni k tomu VNC. Autentizace k VNC tedy je kodovana tim heslem (podle specifikace ted koukam, ze server posle nahodnych 16bytu, klient zasifruje pomoci DES jako klic pouzije zazdane heslo).

Dalsi komunikace probiha bez jakehokoliv sifrovani, kdyz se stiskne klavesa, tak se posila keysym, coz je prakticky plain text. A to je problem a proto je nutne sifrovat.

[Michal Vyskočil]

OK, omlouvám se za mystifikaci, já byl přesvědčen, že jde o plaintext, proto se také všude doporučuje vnc tunelovat přes něco jiného.

[CEST]

No VNC urcite tunel, ja netunelovany VNC pouzivam pouze doma na LANu a v praci pouze na nedulezity testovaci stroje v lokalni siti. Vzdalene bych VNC bez tunelu nikdy na real server nedovolil a to bych doporucoval i ostatnim.

[Miloš Kozák]

To neni problém, jenom jsem to chtěl uvést na pravou míru... Kapku jsem to nastudovával do mé bakalářky:)

BTW povedlo se někomu zprovoznit SSH server v cygwin ve Windows 2003 Server RC2, nebo nějak tak se to značí? V pohodě to nainstaluju, ale spustit to už nejde... moc se ve windows nevyznám ..

dik

[Honza "tux" Friesse]

Já ho vždycky spouštím jen na chvíli ve Windows XP, tj. ne jako službu, ale spustím /usr/sbin/sshd a funguje to. Zkusil bych nejprve toto jednodušší řešení a teprve potom studoval cygserver.

[Miloš Kozák]

Ve windowsXP mi ssh server v poho funguje.. ale v server ne..

[petris]

Ja na spojovani obrazovek ruznejch pocitacu pouzivam x2x. Vyhoda je, ze nemusim poustet zadny kombinace server/klient, ale proste, az se rozhodnu pripojit k memu X nejaky jiny, spustim x2x. Na ostatnich strojich neni potreba nic instalovat/spoustet (krome tech Xek :)

Jinak VNC ma velkou nevyhodu v tom, ze prenasi celou plochu. Ve vetsine pripadu by si ale clovek vystacil s konkretni aplikaci. Proto pouzivam radeji normalni X protokol.

[Jirka]

X11vnc umoznuje prenaset jen urcite okno.

[CEST]

No vida, to jsem si nikdy nevsimnul, to je docela super vec!:)

[CEST]

Taky bych mel par postrehu, nemyslim to jako negativni kritiku, spis jako doplneni a osobni zkusenosti.

Osobne misto RealVNC pouzivam TightVNC, obsahuje totiz kodovani tight, nastaveni jpg kvality obrazu a kompresniho stupne. Kdyz jsem naposledy zkousel RealVNC, byl docela pomalej a tyhle volby myslim nemel, tak jsem presel na tight. Jinak pro Wokna je jeste UltraVNC (ma docela super funkce), ktery umi autentizovat pomoci Windows systemu a proto neni dostupny bohuzel pro Linux (aspon jsem ho nenasel).

K tomu tunelovani bych se take spis primlouval k stunnelu, zvlaste kdyz by uzivatel nemel mit pristup na shell, navic pres stunnel jde autentizovat pomoci certifikatu, takze i autentizace muze byt bezpecna. Dalo by se pouzit i treba OpenVPN (nebo jina VPN), do ktery by se pak schovala jakakoliv dalsi komunikace (napr. IMAP, SMTP...). Stunnel i OpenVPN maji binarni balicky take pro Windows, takze odpada starost s instalaci ssh serveru na Windows, ale osobne jsem to take resil CygWin SSH, ale to jsem chtel i shell a komplet Unix prostredi.

K alternativam. Jako hlavni nevyhodu cistyho prenosu X bych videl to, ze pri padu site, PC nebo klientskeho OS spadne okno a tim se aplikace ukonci. V pripade rozdelane prace to pak hodne vytoci. V pripade padu VNC vieweru ho clovek nahodi znovu a pracuje dal. Vyhoda tunelovanyho X protokolu je naopak ta, ze se okna zobrazujou jako soucasti OS a jde se prepinat pomoci Alt-TAB (s VNCviewerem bud Alt-TAB prepina okna ve VNC nebo se prepina mezi VNCview a ostatnima aplikacema OS).

VNCviewer se obvykle pripojuje k virtualnimu VNC serveru na Linuxech. Ve Windows se pripojuje k aktivni session. Pokud by chtel nekdo v Linuxu, aby se pomoci VNCview pripojil k te session, kterou ma na lokalnim monitoru, lze pouzit x11vnc, ktery vytvori virtualni VNCserver s obsahem, ktery se zobrazuje na lokalnim monitoru. Tzn. chovani bude pak naprosto stejne jako v pripade Windows.

K programu synergy existuje take VNC alternativa: x2vnc a win2vnc. Funguji na opacnem principu nez synergy. U synergy je nastartovan daemon na pracovni stanici, u ktere sedim a ovladane pocitace spousteji klienty a pripojuji se k hlavni stanici. x2vnc a win2vnc naopak funguji podobne jako vncviewer a pripojuji se na vncserver na ovladanou stanici (tam musi samozrejme bezet vncserver, cimz se zabiji dve mouchy jednou ranou - pokud sedim u pracovni stanice, mohu druhou stanici ovladat pres x2vnc, pokud jsem nekde mimo dosah ovladane pracovni stanice, mohu spustit vncviewer). x2vnc/win2vnc ma min moznosti nastaveni, coz je dano IMO pouzitim VNC protokolu, lze nastavit pouze 4 smery (sever, jih, zapad, vychod), na rozdil od Synergy, kde lze presne definovat, ze vpravo mam 1.ovladanou stanici a jeste vpravo od ni je dalsi ovladana stanice (mozna by slo tohle resit i pomoci x2vnc s tim, ze by na ovladane 1.stanici bezel dalsi x2vnc/win2vnc pripojeny na dalsi ovladanou stanici, ale to jsem nezkousel). Jeste v reakci nekdo zminil x2x, coz je ale pouze reseni pro X2X (mouse on one X display to be used to control another X display), kdezto pomoci vncserveru (x11vnc/winvnc.exe) a x2vnc nebo win2vnc muzete ovladat X2X, X2Win, Win2X a to jak na fyzicky X server (x11vnc) nebo na virtualni (vncserver zobrazeny pomoci vncviewer). Mam takhle resene na jednom monitoru ovladani Win ve Vmware zobrazene na X server pres vncviewer+WinVNC, dale vncserver v Linux ve vmware, dale normalni Xka+fluxbox, a pak jeste X server s prohlizecem zobrazujicim Nagios. Ctyri svetove strany obsazene, prepinani tech Xkek na druhym linuxu resim pomoci xsendkeycode (emuluje to stiknuti klaves v Xkach, fakt vsechny klavesy, takze pomoci CTRL-ALT-F5 az F8 prepinam screeny).

[Michal Vyskočil]

Osobne misto RealVNC pouzivam TightVNC, obsahuje totiz kodovani tight, nastaveni jpg kvality obrazu a kompresniho stupne.

Souhlasím, že je RealVNC (alespoň v základní variantě) nejpomalejší, ale v době psaní článku jsem jiné servery nezkoušel. Ale používám jej pořád, protože se mi nechce vrtat do něčeho, co už jsem rozjel

K tomu tunelovani bych se take spis primlouval k stunnelu, zvlaste kdyz by uzivatel nemel mit pristup na shell, navic pres stunnel jde autentizovat pomoci certifikatu, takze i autentizace muze byt bezpecna ...

Používám ssh klíče, takže by to mělo být také bezpečné. Je pravda, že jsem se mohl aspoň odkázat na článek o tunelování na root.cz, kde se probírají i jiné možnosti (se kterými nemám osobně zkušenosti).

Díky za komentář, mám pocit, že vydal za celý článek

[CEST]

Souhlasím, že je RealVNC (alespoň v základní variantě) nejpomalejší, ale v době psaní článku jsem jiné servery nezkoušel. Ale používám jej pořád, protože se mi nechce vrtat do něčeho, co už jsem rozjel

Rekl bych, ze i v realvnc jsou prikazy vncserver a Xvnc a parametry budou stejne jako v tightvnc, takze neni ceho se bat.

Používám ssh klíče, takže by to mělo být také bezpečné. Je pravda, že jsem se mohl aspoň odkázat na článek o tunelování na root.cz, kde se probírají i jiné možnosti (se kterými nemám osobně zkušenosti).

Jojo, urcite pres SSH je to stejne bezpecne jako pres stunnel, akorat vyhoda stunnelu je, ze se nemusi vytvaret shell ucty a navic, co me posledni dobou trapilo pri ssh tunelovani, ze jsem na ssh serveru musel spustit nejaky program, aby se spojeni neuzavrelo a tunel zustal. Tak jsem vymyslel ruzne sleepy a podobne, ale bylo to blby, protoze obcas se stalo, ze spojeni sice spadlo, ale protoze na tunel byly pripojene nejake aplikace, tak se ssh spojeni uplne neuzavrelo, takze ssh poslouchalo na portu, ale uz nedokazalo s cilovym serverem komunikovat. Dokud to ssh neskoncilo, tak se samozrejme nenahodilo nove. A i kdyby se nove nahodilo, tak nemohlo poslouchat na tom portu, protoze se tam drzelo to stare ssh. Navic pak jeste kdyz to ssh treba i kompletne spadlo a zacalo se nahazovat nove, tak se obcas stalo, ze na ssh serveru zustal bezet ten udrzovaci proces, takze jsem musel resit jeste zabijeni tech starych procesu.

Samozrjeme klic byl bez hesla, coz byla taky dira, ale na ssh serveru jsem mel v authorized_key omezeni pro ten klic na jeden prikaz (ten udrzovac spojeni). Proste nebylo to ono. Takze jsem presel na stunnel - je to jednoduche na konfiguraci a pritom dostatecne bezpecne (vyzadovani certifikatu podepsanych od vybrace CA). Takze ted je to dobry.

[Semo]

Tomu vytuhavanie ssh-spojenia by sa malo dat pomoct keep-alive paketmi. Putty ma niekde zaskrtavatko, urcite bude nieco aj v cmdline ssh.

[pok]

Pokud by chtel nekdo v Linuxu, aby se pomoci VNCview pripojil k te session, kterou ma na lokalnim monitoru, lze pouzit x11vnc, ktery vytvori virtualni VNCserver s obsahem, ktery se zobrazuje na lokalnim monitoru. Tzn. chovani bude pak naprosto stejne jako v pripade Windows.

Případně přímo v Gnome je vino: Systém -> Nastavení -> Vzdálená pracovní plocha, nebo vino-preferences (alespoň na FC6 to tak je).

[rincewind]

Narazil jste nekdo na to, ze se spatne interpretuji stisky klaves pri pripojeni rdesktopem z linuxu a na stroj s windows (locales mam iso8859-2 - vychozi a utf-8)? Jistym pokrokem je, ze jsem nastavil jazyk na en-us, ale presto nektere klavesy (zrejme jen s hackem nebo carkou) se poslou bud dvakrat nebo jedno s diakritikou a druhe bez. Jinak co se tyce VNC tak osobne jsem narazil na podobny problem, ze nesla poslat diakritika.

[CEST]

Jojo, s cestinou je to tezky. Pri kombinaci Linux vncview a Win vncserver je to jeste o kombinaci En-Cz v linuxu a ve Win. Je to takovej trosku gulas. A urcite taky bude zalezet, jak se spousti ten vncviewer. Linux 2 Linux by snad s cestinou nemel mit problem.

[Franta]

Taky, taky. Psaní písmenek v RDP většinou funguje, ale některé znaky se jen špatně zobrazují (třeba v Excelu v tabulce, ale v řádku vzorce jsou dobře).

P.S. Tenhle prispevek jsi psal také z VNC?

[pet]

S alternativou ssh X11 forwarding jsou problemy pri pouziti aplikaci pouzivajicich gtk2 - tyto padaji. Aplikace pouzivajici starsi gtk nepadaji. Pokud nekdo vi, co a jak je potreba osetrit, aby tomu tak nebylo, prosim prosim, podelte se s nami.

[Jirka]

Rad bych se zeptal, jestli nekdo resil otazku premeny VNC streamy na video stream. Rad bych deni ve vncviewer encodoval do video streamu, nasledne distribuoval po siti a prohlizel ho treba pomoci VLC. Nevite, jestli neco takoveho jiz exituje?

[CEST]

Jen tak v rychlosti co ma Gentoo:

vnc2swf http://www.unixuser.org/~euske/vnc2swf A tool for recording Flash SWF movies from VNC sessions (to spis pro zaznam)

vncrec http://www.sodan.org/~penny/vncrec/ VNC session recorder and player (tohle je taky spis pro zaznam, ikdyz pro transcode existuje modul na converzi do AVI, tak mozna by se to dalo nejak donutit, aby to streamovalo online).

pripadne nejhorsi moznost:

vncsnapshot http://vncsnapshot.sourceforge.net/ A command-line tool for taking JPEG snapshots of VNC servers

a z toho pak udelat video nebo stream nebo mjpeg by taky mozna slo.

Online streamovani asi nebude, protoze pro online je mozne pouzit share-mode s viewonly kombinaci. Cili pustit server s full-access pristupem pro sebe, a s view-only heslem pro ostatni. Jestli pak budes mit view-only jeste sifrovane treba stunnelem nebo to nechas nesifrovane, to uz zalezi jenom na tobe a obsahu vncserveru. Na prohlizeni vnc ve Windows staci vncviewer.exe, zadne dalsi DLL tusim nejsou potreba (WinVNC.exe jsou potreba dve DLL, ale neni potreba to take instalovat).

[Jirka]

Ma predstava je takovato:
* PC1 bezi na windows
* PC2 bezi na linuxu
* PC3 bezi na windows nebo linuxu

Encodovani:
* PC2 se pripoji pre vncviewer na PC1
* na PC1 se encoduje deni ve vncvieweru
* encodovane video se posila do site
* PC2 je dost vykonny na on-line encodovani

Prohlizeni:
* na PC3 pustim VLC a koukam na video

Takze se mi jedna o cteni dat z vncviewer (asi vncrec?) a nasledne prekonvertovani do MPEG streamu (asi transcode s podporou vnc?) a naslednou distrubuci videa do site.

[GeBu]

A nezkoušel jsi na PC1 spustit přímo VLC a jím zachycenou obrazovku streamovat do VLC na jiném PC?

[Jirka]

A jak zachycovat obrazovku a streamovat to dal? Soucasny SW umoznuje jen ukladani do souboru, coz je trosku neprakticke.

[GeBu]

Se přiznám, že jsem to nezkoušel, ale žil jsem v tom cokoliv umí VLC zachytit umí i streamovat.

[Jirka]

A VLC umi zachytit VNC?

[GeBu]

Aha, už vím proč si nerozumíme. Já vůbec nemyslím zachytávat obrazovku pomocí VNC, ale přímo pomocí VLC, které by mělo umět přímo streamovat obrazovku stroje na kterém běží. Jednou jsem to zkoušel a šlo to, ale už nevím, jestli ve Windows nebo v Linuxu (myslím, že Windows). Ale nestreamoval jsem to, jen ukládal, ale neumělo to zvuk a to mi vadilo.

[Jirka]

Aha, to jsem nevedel ze VLC umi zachytavat obrazovku. Nicmene zachytavat, encodovat a streamovat obsah cele obrazovky je pomerne narocne. Radeji bych streamoval jen urcite okno (x11vnc). Proto budu i nadale hledat cestu pres VNC. Zda se, ze jeden projekt dela co bych potreboval: VNCast (http://wiki.vislab.usyd.edu.au/moinwiki/VNCast).

[helemesecotonese]

super vec je take x2x, sice je to neco uplne jineho, ale sikne se to znat...

[Ash]

Jediná nevýhoda použití ssh je, že protokol pracuje na aplikační úrovni; to znamená, že to není zcela transparentní, ale je nutné změnit číslo portu.

ssh -L 5901:localhost:5900 user@server.domena

SSH tunel není transparentní? A co brání při tunelování použití zcela transparentního

ssh -L 5901:localhost:5901 user@server.domena

?

Já to tak alespoň používám (linux), měnit port mě ještě nenapadlo. To je nějaká vlastnost Windows? Obecně je komunikace je vedená na lokální 5901 posílána na vzdálený ssh port a tam z localhostu na 5901 vzdáleného stroje, takže nevidím problém, asi není dobré to prezentovat jako vlastnost ssh, když je patrně jen řešen nějaký nesoulad v konkrétním nastavení služeb (patrně na woknech běžící vnc:5900 na nějž se chceme z nejasných příčin připojovat podobně jako na linux vnc:5901, ale to jen hádám).

Při používání Putty mě pouze vypeklo to, že je v definici tunelu nutné místo localhost zadat IP adresu 127.0.0.1

V jakém případě je nutno někam do putty.exe zadávat 127.0.0.1? Pokud se připojuji z Woken používám

Connection -> SSH -> Tunnels ->"
Source port: 5901
Destination: server.domena:5901

V jakém případě je nějak potřeba psát 127.0.0.1?

A.

[Ash]

Je pravda že úplně transparentní to není, protože v aplikacích je potřeba uvádět localhost místo server.domena :) Ale z hlediska čísla portu to transparentní je. (A také konfliktní, pokud třeba na localhostu na tom portu už něco běží, což je možná ten důvod pro změnu čísla portu v článku, ale to pořád jen hádám...).

[Michal Vyskočil]

Pokud používám místní přesměrování, tak se mi tunel při použití localhost nevytvořil.

[Ash]

Co má být to "místní přesměrování"? Jako když se chcete přihlásit na vnc serveru na lokálním počítači? Tak to bych pak chápal i že je potřeba měnit port a taky že localhost třeba putty nepřeložil (měl by asi použít ....něconěco/system32/hosts, no asi se mu nechtělo :).

[Michal Vyskočil]

U ssh existuje místní a vzdálené přesměrování. V OpenSSh se rozlišují parametry -L -R, Putty na to má volby Local, Remote při v sekci Tunnels - viz obrázek

[botanicus]

"pacmac".sub!(/\<pacmac\>/, "pacman")

[Tomáš]

Chtěl bych se vás zeptat, zda-li X server (třeba s nějakým SW) umožňuje skrz síť posílat dění na uživatelovo monitoru. Vím, že VNC to umí a jde mi o to, zda-li to lze řešit i bez něj.

Díky!

[df]

Potřeboval bych propojit desktop, na kterém beží WinXP a Notebook s Mandrivou 2007 pomocí síťového kabelu. To abych nemusel kvuli přenosu dat mezi počítači vzdálenými tak 0,5 metru používat k transportu dat USB klíč, nebo dokonce napalovačku, nebo něco jiné. Oba počítače mají síťové karty, tudíž se mi to zdá nejjednoduchší řešení. Potíž je ale v tom, že za asi třičtvrtě roku se mi to nepodařilo propojit tak aby to fungovalo, takže když chci přenést pouze jeden soubor, musím použít USB klíč. Jsem však přesvědčen , že za pomocí kříženého kabelu by to mělo jít. Snad zde ani nemusím zdurazňovat, že nějaké šifrování je zbytečné - jeden počítač je ve stolu a druhý na stole tak 0,5 metru. Skoušel jsem ruzná nastavení IP na obou počítačích, ale Windows pořád hlásil omezené, nebo žádné spojení. Ve windowsu je pruvodce nastavením síťě, ale tam se píše, že se má ten pruvodce pustit na všech počítačích, které chci propojit, což předpokládá, že na všech počítačích beží WinXP. Ale na mém notebooku je MDV 2007. Co s tím ? Dá se to sprovoznit ? Mám zapnout na WinXP nějaký server, jak se to dělá ? Ještě jedna věc - na bezpečnosti vuči WinXP nesejde, protože ten počítač není připojený k síti. Tedy nějaké povolené sdílení celého disku mi nevadí, ani pootevírané všechny porty. Jak to ale udělat ? Dékuji za odpověď.

[Non_E]

1) Zeptejte se v poradně.

2) Připojení po síti je úplně jiná věc než VNC

3) Nastavte oběma počítačům stejnou masku a každmu dejte ip adresu (třeba 192.168.1.1 a 168.1.2, oba mají masku 255.255.255.0). Pak zkuste z jednoho v konzoli ping 192.168.1.1 resp. 192.168.1.2 a uvidíte, jestli se připojíte.

4) pak se podívejte po nějakém způsobu sdílení souborů - mandriva asi bude umět přistupovat k windowsáckémmu sdílení, pro sdílení z mandrivy se podívejte po sw jménem samba.

5) S problémy a dotazy hledejte v poradně a nebo na internetu (třeba google.cz)

[John DOE]

Ještě dodám, že by jste měl použít křížený kabel pro propojení dvou počítačů přímo. JD

[Al Za houby]

To je pravda, ale některé novější síťovky dokáží samy rozpoznat typ kabelu. Srandapes je pak přesvědčovat BFU že jinde to přímákem fachat nemusí.

[Dreit]

Jentak mě napadá, nejelo by to přes Hamachi?

[Sinner]

Spustil som TightVNC z linuxu na windowsXP cez hamachi a bol by som  rad, ak by sa niekto vyjadril k bezpecnosti vzdialenej plochy touto metodou. Dakujem.

[Kyosuke]

Chmm, šířku pásma...on hlavně vyžaduje hromadu roundtripů, to je hlavní problém. S tou šířkou pásma to nemusí být až tak strašné, můžu třeba mít na obou stranách broadband. Ale latenci neodstraním. NX je oproti tomu někde úplně jinde.

[digri]

Jeste k tomu tunelovani, pokud se prihlasuju na windowsi masinu, tak je asi jednodussi pouzit SSL tunel (stunnel), na rozdil od SSH s nim pod windows nebudete mit problem. Dalsi alternativou je samozrejme VPN.

[HonzaD]

Já používám na windowse TightVNC s "virtualni" grafickou karotu, je to nejakej ovladac ci co, je to stim znatelne rychlejsi a jako zabezpeceni pouzivam hamachi, je to rychli a pohodlny, ale nekdy se potrebuju pripojit z weboveho prohlizece pres javu od nekud kde nemam cas a nebo prava neco instalovat, je mozne nejak zabezpecit i to webove rozhraní integorvany v thightVNC? treba tim ssl ? Abych nemusel ale na klientovi instalovat zadnej SW