Portál AbcLinuxu, 19. dubna 2024 10:35

Vzdálený přístup

Protokol X11 je navržen tak, aby ho bylo možné používat nejen tehdy, když X server a klientská aplikace běží na témže počítači, ale i v případě, že běží na různých počítačích, které jsou propojeny sítí. V takovém případě je ke komunikaci využíváno TCP spojení. Aby mohla aplikace komunikovat s X serverem, je třeba jí sdělit, na který X server (a případně na kterou obrazovku) má zobrazovat. Tato informace je obvykle předávána prostřednictvím proměnné prostředí DISPLAY, klasické grafické programy podporují i parametr příkazové řádky -display (nebo zkráceně -disp).

Hodnota proměnné (resp. argument) má obecně tvar 'host:display.screen'. Nepovinný parametr host definuje počítač, kde se X server nachází. Většinou obsahuje jméno počítače nebo IP (IPv4 nebo IPv6) adresu. Není-li uveden, kontaktuje se X server na stejném počítači, většinou ale ne pomocí TCP spojení přes lokální smyčku, ale přes lokální (unix domain) socket.

Parametr display určuje číslo konkrétního X serveru na zvoleném počítači. Na jednom počítači může totiž X serverů běžet více, například je-li současně otevřeno více grafických konzolí. Jiným příkladem je spuštění programu Xnest, který implementuje X server používající jako virtuální obrazovku okno zobrazované na jiném X serveru. Obvyklé číslování X serverů je od nuly, nejčastěji se zde proto setkáme s hodnotou 0. Tento parametr je také (včetně dvojtečky) jediný povinný, minimální (a také nejčastější) specifikace obrazovky je tedy ':0'. Z praktického hlediska parametr display při TCP komunikaci určuje port, na nějž je navazováno spojení; jedná se o port 6000+display.

Poslední (opět nepovinný) parametr screen určuje obrazovku, na kterou má aplikace zobrazovat. Obrazovky (má-li jich X server více) se číslují opět od nuly (nula je i defaultní hodnotou). Číslo obrazovky na rozdíl od předchozích parametrů neovlivňuje navázané spojení, informace je používána interně v rámci komunikace protokolem X11. Obrazovky v tomto smyslu nemají nic společného s virtuálními pracovními plochami, které nabízí většina window managerů. Nejčastěji se s více obrazovkami setkáváme u počítačů s více monitory, kde číslo obrazovky určuje (fyzický) monitor, na který bude aplikace zobrazovat.

Praktická použitelnost aplikace běžící na vzdáleném počítači a zobrazující na lokální X server je ovlivněna parametry síťového spojení. Je-li spojení realizováno lokální sítí, nebývá to problém; u 100 Mb/s ethernetu na chování většiny aplikací není vzdálená komunikace příliš znát. U pomalejších spojení (kromě přenosové rychlosti zde hraje roli i zpoždění paketů) jsou pochopitelně odezvy delší. Hodně zde záleží i na tom, co aplikace zobrazuje. Vykreslování jednoduchých objektů nebo vypisování textů není příliš náročné, ale např. při prohlížení fotografií je třeba přenášet celé bitmapy, což může být poměrně náročné. Nezanedbatelnou výhodou je i skutečnost, že tímto způsobem můžeme používat grafické aplikace i na počítači, kde není vůbec nainstalován X server, např. na výkonném aplikačním serveru, ke kterému přistupují uživatelé ze svých pracovních stanic. Nelze zapomínat ani na to, že protokol je univerzální: není tedy omezen na prostředí Linuxu, ale lze jej používat i mezi různými platformami.

Možnost zobrazování na X prostřednictvím TCP/IP sítí (a tedy i Internetu) je velmi užitečným nástrojem, jedná se ale o dvousečnou zbraň. Pokud bychom neaplikovali mechanismus, který by omezil potenciální klienty, mohl by kdokoli používat náš X server, a to nejen k zobrazování, ale i k získávání událostí od vstupních zařízení; mohl by tedy mimo jiné např. sledovat, co píšeme na klávesnici. Nepotřebujeme-li vůbec přistupovat na X server vzdáleně, může být vhodnější použít při jeho spouštění parametr '-nolisten tcp', který způsobí, že X server nebude vůbec poslouchat na TCP portu 6000+display a umožní pouze komunikaci lokálních klientů přes lokální socket. Některé novější distribuce naopak spouštějí X server s tímto parametrem defaultně, takže naopak chceme-li komunikovat vzdáleně, je potřeba to explicitně povolit. V dalších částech se ale zaměříme na situaci, kdy vzdáleně komunikovat chceme, ale potřebujeme klienty autorizovat.

Seznam povolených adres

Nejjednodušší formou autorizace je rozlišení klientů podle IP adresy. Display manager udržuje seznam adres (standardně prázdný), z nichž je povolen přístup všem klientům bez dalších omezení. K manipulaci s tímto seznamem lze použít příkaz xhost, bez parametrů vypíše seznam povolených adres (standardně přeložených na DNS jména). Přidání položky do seznamu lze provést příkazem 'xhost +host' (znak + lze vynechat), odebrání příkazem 'xhost -host'.

Jak už to bývá, je tato varianta sice nejjednodušší, ale také nejméně vhodná. Jednak povolením adresy konkrétního počítače povolujeme přístup automaticky všem jeho uživatelům, jednak při podvržení IP adresy server nepozná, že se nejedná o oprávněného klienta. Pomineme-li tedy specifické případy typu lokální sítě o dvou počítačích a jednom uživateli. nelze tuto metodu v dnešní době pro praxi doporučit.

Autentizační cookies

Při spuštění seance (session) display manager generuje náhodný klíč (cookie), který je s touto seancí svázán. Klient, který se prokáže znalostí této cookie, má povolen přístup k X serveru, aniž by jeho IP adresa musela být v seznamu z předchozí sekce. Cookie je spolu s informací o serveru (zapisuje se ve stejném formátu jako hodnota proměnné DISPLAY s vynecháním čísla obrazovky) uložena do autentizační databáze, která je standardně v souboru .Xauthority v domácím adresáři přihlášeného uživatele. Z tohoto souboru si pak cookies berou jednotlivé grafické aplikace a používají je pro autentizaci vůči serveru.

S obsahem autentizační databáze lze pracovat příkazem xauth, a to buď interaktivně (spustíme-li ho bez parametrů) nebo neinteraktivně (předáme-li mu příkaz přímo jako argument). Základní příkazy jsou:

• list … zobrazení cookies z databáze
• extract file server … zkopírování cookie pro server server do souboru file
• merge file … přidání cookie ze souboru do databáze

Jako jméno souboru lze uvést i znak '-', cookie se pak extrahuje na standardní výstup a načítá se ze standardního vstupu. Pokud v takovém případě nepřesměrováváme výstup nebo nepoužijeme rouru, je vhodnější použít příkazy nextract a nmerge, používající formát složený pouze z číslic, který lze zobrazovat na terminál a kopírovat pomocí selection nebo copy&paste.

Přihlásíme-li se tedy na vzdálený počítač např. pomocí SSH a chceme-li na něm spouštět grafické aplikace tak, aby zobrazování probíhalo na náš lokální X server, je třeba nastavit odpovídajícím způsobem proměnnou DISPLAY tamnímu shellu (nesmíme ale zapomínat, že shell a posléze i grafická aplikace poběží na vzdáleném počítači, nelze tedy psát localhost nebo jméno počítače vynechat). Dále ale také musíme zkopírovat autentizační cookie z lokální databáze do vzdálené. To lze provést buď extrakcí do souboru, jeho překopírováním a importem cookie do databáze, nebo extrakcí na terminál a překopírováním do druhého okna, kde jsme přihlášeni na vzdáleném stroji a předem jsme použili 'xauth nmerge -'.

Transparentní tunelování pomocí SSH

Zásadní nevýhodou předchozích postupů je skutečnost, že řeší pouze otázku autentizace a autorizace (a ani to ne zcela spolehlivě), ale žádným způsobem nechrání data, která si mezi sebou vyměňují X server a klientská aplikace, a to proti odposlechu ani proti podvržení. Pokud tedy komunikace mezi oběma počítači není zabezpečena např. pomocí IPsec, není takové řešení příliš vhodné, a to zejména, komunikují-li mezi sebou přes Internet. Protože X11 komunikace používá jedno TCP spojení, je ideálním kandidátem na zabezpečení pomocí SSL (např. programem stunnel). Protože se ale dnes na vzdálený počítač, kde aplikaci spouštíme, většinou připojujeme pomocí SSH, je jednodušší využít možnosti transparentního tunelování X11 přes jeho zabezpečený přenosový kanál.

K pochopení toho, jak funguje tunel, je třeba mít na paměti, že X server je na straně, kde je SSH klient, a naopak. Tunelování není třeba nijak složitě nastavovat, pouze je nutné, aby tato funkce byla povolena v konfiguraci klienta (ssh) i serveru (sshd) a aby byl klient spouštěn s parametrem -X a měl nastavenou proměnnou DISPLAY na lokální X server. Je-li tomu tak, SSH démon vytvoří virtuální X server (standardně s číslem od 10 výše, aby nedocházelo ke kolizi s případnými lokálními X servery na jeho straně. Na tento X server (tj. typicky na hodnotu ':10') pak také nastaví shellu (nebo jinému spouštěnému programu) proměnnou DISPLAY.

Spuštěná grafická aplikace tedy veškeré požadavky posílá na virtuální X server, ten je ale pouze přeposílá (zabezpečeným spojením) SSH klientovi, který je dále předá lokálnímu X serveru na straně uživatele. Podobně, pouze v opačném směru, jsou posílány odpovědi X serveru aplikaci. Aplikace samozřejmě nemusí běžet na stejném počítači jako SSH démon, podobně SSH klient nemusí běžet na stejném počítači jako X server. Pak je ale zabezpečený jen úsek mezi SSH démonem a SSH klientem, to ale může být dostatečné, např. jsou-li koncové úseky realizovány relativně bezpečnou lokální sítí, zatímco tunelovaný úsek vede přes Internet.

Kromě obvyklých bezpečnostních opatření při používání SSH (zejména kontrola pravosti veřejného klíče serveru při prvním přihlášení) nesmíme zapomínat, že tunel chrání jen před útoky "po cestě". Není tedy ochranou před lokálním útokem na koncových počítačích. Zejména pokud bychom nemohli důvěřovat uživateli root na vzdáleném počítači, zpřístupňujeme mu otevřeným tunelem svůj lokální X server (po dobu, kdy je tunel navázán). Nesmíme také zapomínat, že při větších datových tocích šifrování a autentizace dat zatěžuje procesor obou stran. Naopak, u pomalých spojení lze zapnutím komprese (přepínač -C) přenos urychlit snížením objemu přenášených dat.

Lokální komunikace pod jiným uživatelem

Problematika lokální komunikace do této kapitoly zdánlivě nepatří, ale vše, co bylo řečeno v předchozích sekcích, se vztahuje i na aplikace běžící na témže počítači jako X server. Procesy uživatele, který se přihlásil do grafického prostředí, mají samozřejmě přístup k vygenerované cookie, takže jim je přístup umožněn. Pokud ale použijeme příkaz su, nebudou mít procesy spouštěné pod cílovým uživatelem k X serveru povolen přístup.

Povolení přístupu pomocí 'xhost localhost' není vhodným řešením, protože tím bychom povolili přístup všem lokálním uživatelům a procesům. Řešení pomocí SSH je zase zbytečně náročné, protože šifrování a autentizace jsou při lokální komunikaci zcela zbytečné a pouze by zatěžovaly procesor. Nejvhodnějším řešením je tedy zkopírování autentizační cookie do databáze cílového uživatele. Lze to provést stejným způsobem jako při vzdálené komunikaci, kopírování je zde ale o něco jednodušší. Je-li cílovým uživatelem root, lze navíc využít toho, že má povoleno čtení jakéhokoli souboru ve filesystému a nechat ho extrahovat cookie přímo z databáze přihlášeného uživatele:

  xauth -f ~user/.Xauthority extract - :0 | xauth merge -

Jednodušší alternativou je použití příkazu sux, který funguje podobně jako su, ale navíc automaticky kopíruje autentizační cookie od původního uživatele k novému. Také lze použít autentizační modul pam_xauth, který způsobí automatické předání autentizační cookie při použití příkazu su. Stačí přidat do souboru /etc/pam.d/su řádek

  session  optional       pam_xauth.so

XDMCP - Linux jako terminál

Protože window manager je z pohledu X serveru klientská aplikace jako každá jiná, může samozřejmě i on běžet na jiném počítači než X server. Můžeme pochopitelně spouštět i window manager se zobrazováním na jiný X server pomocí proměnné DISPLAY nebo parametru -display, např.:

  Xnest -geometry 1024x768 :1 &
  fvwm -display :1 &

Chceme-li se takto přihlásit ke vzdálenému počítači, je třeba při spouštění X serveru tento počítač specifikovat parametrem -query (argumentem je jméno nebo IP adresa):

  X -query 192.168.2.65

Chceme-li, aby náš počítač fungoval jako terminál pro více vzdálených stanic, můžeme spustit display manager (konkrétní nastavení závisí na volbě display manageru) v režimu, kdy je uživateli místo lokálního přihlašovacího dialogu nejprve zobrazen seznam počítačů, na které se může přihlásit, a teprve poté, co si ze seznamu vybere cílovou stanici, je zobrazen její přihlašovací dialog (obrazovka). Seznam může být buď definován staticky v konfiguraci lokálního display manageru nebo může být vytvářen dynamicky. Ve druhém případě display manager rozešle broadcast datagram s dotazem, kdo je ochoten povolit přihlášení, a zobrazí se seznam stanic, které odpověděly. Tento seznam se pak obvykle periodicky aktualizuje. Je možná i kombinace staticky konfigurovaného a dynamicky generovaného seznamu.

XDMCP protokol neobsahuje prakticky žádné bezpečnostní prvky a vzhledem k použití UDP není ani jeho dodatečné zabezpečení příliš snadné. Jeho použitelnost je proto omezena prakticky jen na důvěryhodné lokální sítě, kde se používá pro klasické X terminály a tenké klienty. Samozřejmě i použití XDMCP podléhá konfiguraci autorizačních pravidel, ale jejich výklad by byl nad rámec tohoto letmého seznámení. Bližší informace lze získat např. z těchto zdrojů:

• Domácí síť - III
• FreeBSD v malej firme - 6 (terminálové služby)
• Linux XDMCP HowTo

Dokument vytvořil: vladka, 29.8.2005 12:09 | Poslední úprava: Nicky726, 11.3.2009 23:55 | Další přispěvatelé: Michal Kubeček, Milan Horák | Historie změn | Zobrazeno: 11277×

Tiskni Sdílej:

ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.