dla początkujących

50

styczeń 2006

dla początkujących

zdalny dostęp do pulpitu

51

www.lpmagazine.org

Zdalny dostęp

do środowiska

graficznego

Piotr Machej

U

zyskanie zdalnego dostępu do
komputera z zainstalowanym
Linuksem jest proste, o ile jest
na nim uruchomiony serwer

SSH, ale nie wszystko da się zrobić w trybie
tekstowym. Może zdarzyć się, że mamy
jakiś problem, który nie jest łatwo opisać
słowami. W takim przypadku dobrym
rozwiązaniem byłoby udostępnienie bar-
dziej doświadczonemu znajomemu (lub np.
administratorowi naszej sieci) naszego pul-
pitu – wtedy nie tylko moglibyśmy uzy-
skać pomoc, ale i zobaczyć, co ten znajomy
zrobił. To wszystko jest możliwe, a z niniej-
szego artykułu dowiecie się, jak możecie
skonfigurować Linuksa w celu udostępnia-
nia swojego biurka lub uzyskiwania dostę-
pu do zdalnego pulpitu. Zawarte w nim
informacje dotyczą szczególnie dystrybucji
Aurox i Fedora, ale większość z nich może
być wykorzystana również przez użytkow-
ników innych dystrybucji Linuksa.

Przykład z życia

Posiadanie jednego mocnego komputera
i jednego (lub więcej) słabszych ma swoje
zalety i wady. Z oczywistych względów
najbardziej lubię pracować na tym naj-
lepszym, ale czasem rodzina mnie z niego
wygania (np. aby pooglądać filmy na
DVD). Zamiast przenosić wtedy wszyst-
kie materiały do pracy na drugi kompu-
ter, po prostu słabszy sprzęt wykorzy-
stuję jako terminal. Rodzinka może sobie
wtedy spokojnie oglądać film, a ja mogę
pracować z OpenOffice.org Writerem na tym
samym komputerze, korzystając z klawia-
tury i monitora słabszego sprzętu.

W nieco inny sposób radzi sobie w firmie

mój znajomy. Zmęczony ciągłym bieganiem
do użytkowników zgłaszających problemy
zainstalował na wszystkich komputerach

X11vnc. Od tej pory po odebraniu zgło-
szenia wyświetla sobie w okienku pulpit
użytkownika mającego problem i zazwy-
czaj jest w stanie naprawić usterkę bez
ruszania się z serwerowni. Zaoszczędzony
czas podobno poświęca na testowanie prze-
pustowości sieci z użyciem znakomitej gry
America's Army.

FreeNX

Stosunkowo nowa technologia NX, roz-
wijana przez firmę NoMachine, zdobywa
sobie coraz więcej fanów. Wynika to głów-
nie z tego, że zastosowano w niej bardzo
wydajną metodę kompresji. Dzięki temu
nawet posiadacze antycznych już mode-
mów 9600 bps mogą dosyć komfortowo
pracować ze zdalną sesją graficzną. Co
więcej, sesja jest szyfrowana z użyciem
SSH, co powinno zapewnić nam wystar-
czający poziom bezpieczeństwa. Ponieważ
cena udostępnianego przez NoMachine ser-
wera NX jest dosyć wysoka, skorzystamy
z bezpłatnej alternatywy, czyli dostępnego
na licencji GPL serwera FreeNX. Jako klien-
ta wykorzystamy oryginalnego (i bez-
płatnego) klienta stworzonego przez No-
Machine.

Instalacja i testowanie klienta

Zaczniemy od instalacji klienta, gdyż
zanim zainstalujemy serwer, możemy
przetestować jakość NX na serwerach
udostępnionych przez NoMachine. Wcho-
dzimy na stronę http://www.nomachine.com/
download_client_linux.php i pobieramy pa-
kiet odpowiedni dla naszej dystrybucji.
Po zapisaniu go na dysku instalujemy go
w taki sam sposób, jak inne pakiety (np.
w Fedorze poleceniem

rpm -Uvh nxclient-

1.5.0-113.i386.rpm

). Oczywiście, do insta-

lowania pakietów potrzebujemy upraw-

DVD

Po uruchomieniu Linux+ Live

DVD możesz skorzystać z SSH,

VNC, FreeNX-a oraz Krfb.

Na płycie CD/DVD

Na płycie CD/DVD znajdują się

pakiety FreeNX-a oraz

klienci VNC.

dla początkujących

50

styczeń 2006

dla początkujących

zdalny dostęp do pulpitu

51

www.lpmagazine.org

nień administratora, które możemy uzy-
skać wydając polecenie

su -

i podając ha-

sło użytkownika root.

Jeśli chcemy przetestować, jak NX spra-

wuje się na naszym łączu, możemy wejść
na stronę http://www.nomachine.com/testdrive.
php. Należy tu wypełnić krótki formularz.
Najpierw wybieramy serwer, który chcemy
wykorzystać do testów (np. testdrive.no-
machine.com, umieszczony we Włoszech).
Oprócz tego, należy podać swoje imię i naz-
wisko oraz działający adres e-mail. Chwilę
po wciśnięciu przycisku Send na wskaza-
nym koncie pocztowym powinien pojawić
się list z danymi potrzebnymi do podłącze-
nia się do serwera.

Zaopatrzeni w te informacje możemy

uruchomić klienta poleceniem

nxclient

.

Na ekranie Session wpisujemy nazwę
sesji (np. Test Drive) oraz nazwę kompu-
tera podaną w liście (np. testdrive.noma-
chine.com). Numer portu pozostawiamy
w spokoju i wybieramy tylko typ nasze-
go połączenia z Internetem. Na następ-
nym ekranie z rozwijalnej listy wybieramy
Unix i środowisko (w przypadku testowe-
go serwera dostępne są KDE i GNOME).
Ponadto, wybieramy odpowiadający nam
rozmiar pulpitu. Możemy również zazna-
czyć opcję powodującą szyfrowanie całości
transmisji. W ostatnim ekranie konfigura-
cyjnym możemy zadecydować, czy ikona
połączenia ma pojawić się na pulpicie oraz
czy mają być wyświetlone zaawansowane
opcje konfiguracji. Na razie nie będziemy
przeglądać zaawansowanych opcji, więc
po prostu wciskamy przycisk Finish.

Teraz pozostaje nam już tylko w wy-

świetlonym okienku wpisać nazwę użyt-
kownika i hasło dostarczone w liście oraz
z rozwijalnego spisu wybrać odpowiednią
nazwę sesji (w naszym przykładzie – Test
Drive). W czasie nawiązywania pierwsze-
go połączenia ze zdalnym serwerem może
pojawić się pytanie o zaakceptowanie
klucza RSA. Należy go zatwierdzić, a po
chwili zobaczymy okno z wyświetlonym
pulpitem zdalnego komputera. Konto
testowe przyznane przez NoMachine jest
aktywne przez 7 dni, więc daje to dosyć
czasu na przetestowanie jakości transmisji
przy różnych warunkach obciążenia sieci.

Jeśli nas to zadowoli, możemy przejść

do zakładania własnego serwera.

Konfiguracja serwera

Opis instalacji i konfiguracji serwera
FreeNX jest bardzo ściśle związany z dys-
trybucjami Aurox i Fedora. W przypadku

innych popularnych dystrybucji, zgodnie
z informacjami zawartymi na stronie do-
mowej projektu (http://openfacts.berlios.de/
index-en.phtml?title=FreeNX_distro_inte-
gration), serwer ten jest zawarty od razu
w dystrybucjach lub we wskazanych na
stronie repozytoriach. Z tego powodu
instalacja w przypadku tych dystrybu-
cji (Mandriva, Gentoo, Ubuntu, Debian) nie
powinna sprawić kłopotu.

Jak zwykle, przed instalacją nowego

oprogramowania powinniśmy zadbać o
aktualność systemu. W związku z tym
wydajemy (z uprawnieniami administra-
tora) polecenie

yum update

. Po uaktual-

nieniu pakietów instalujemy potrzebne
pakiety poleceniem

yum install expect

nc

. Teraz musimy pobrać odpowiednie

pakiety FreeNX i NX. Niestety, w tej chwili
nie są jeszcze dostępne w repozytorium
Fedora Extras, więc będziemy musieli ścią-
gnąć je "ręcznie".

Pobieramy pakiet http://fedoranews.org/

contributors/rick_stout/freenx/freenx-0.4.4-
1.fdr.0.noarch.rpm. Jest on przeznaczony
dla dystrybucji Fedora Core 2 i nowszych,
a także innych korzystających z X.org. Jeśli
nadal używamy dystrybucji Fedora Core 1,
Red Hat 9 lub innej korzystającej z XFree86,
to powinniśmy pobrać pakiet http://
fedoranews.org/contributors/rick_stout/freenx/
freenx-0.4.4-1.rh.0.noarch.rpm. Oprócz tego,
pobieramy pakiet http://fedoranews.org/
contributors/rick_stout/freenx/nx-1.5.0-
0.FC4.1.i386.rpm. Jak można rozpoznać
po nazwie, jest on przeznaczony dla dys-
trybucji Fedora Core 4. Użytkownicy wcze-
śniejszych wersji mogą użyć w nazwie,
zamiast FC4, odpowiednio FC3, FC2 lub
FC1. Ta ostatnia wersja jest przeznaczo-
na również dla użytkowników Red Hat 9
i innych korzystających z XFree86.

Po pobraniu pakietów instalujemy je

poleceniem

rpm -Uvh freenx-0.4.4-1.fdr.

0.noarch.rpm nx-1.5.0-0.FC4.1.i386.rpm

.

Na tym kończy się instalacja serwera. Praw-
da, że proste?

Konfiguracja klienta

Podstawowe konfigurowanie klienta opi-
saliśmy już wcześniej. Jeśli nie zakładali-
śmy testowego konta, to możemy kiero-
wać się opisem umieszczonym w rozdzia-
le Instalacja i testowanie klienta. Oczywiście,
zamiast danych serwera NoMachine podaje-
my dane naszego serwera. Jeśli założyliśmy
już konto i mamy skonfigurowaną sesję w
kliencie, to w celu dodania nowej sesji uru-
chamiamy klienta poleceniem

nxclient --

wizard

. Później możemy postępować zgod-

nie ze wspomnianym opisem, ale na końcu
będziemy musieli sięgnąć po ustawienia
zaawansowane. Wynika to z tego, że w
celu poprawnego uwierzytelnienia musimy
klientowi dostarczyć poprawny klucz pry-
watny. Znajduje się on w pliku /etc/nxserver/
client.id_dsa.key na komputerze, gdzie insta-
lowaliśmy serwer FreeNX. Musimy go sko-
piować (czy to z pomocą dyskietki, czy
komendą

scp /etc/nxserver/client.id_

dsa.key user@192.168.1.15:~/

– przy zało-

żeniu, że korzystamy z konta user na kom-
puterze o adresie 192.168.1.15) na nasz kom-
puter z klientem. Wtedy w opcjach zaawan-
sowanych sesji wciskamy przycisk Key, a w
następnym oknie przycisk Import. Po wska-
zaniu skopiowanego pliku client.id_dsa.key
zatwierdzamy operację przyciskiem Save i
jeszcze raz Save.

Gdybyśmy później chcieli zmienić

opcje (np. rozmiar pulpitu lub środowi-
sko), możemy po uruchomieniu klienta
wybrać odpowiednią sesję z listy i wcisnąć
przycisk Configure.

Po zakończeniu pracy ze środowi-

skiem wylogowujemy się z niego, tak
jak zwykle. Możemy też zamknąć okno
klienta, a wtedy uzyskamy możliwość
zawieszenia sesji (Suspend). Przy ponow-
nym łączeniu się z serwerem zobaczymy
spis zawieszonych sesji, z których można
wybrać tą, którą chcemy wznowić.

Serwer FreeNX ma wiele zalet, ale na

razie nie we wszystkich zastosowaniach do-
brze się sprawdza. Przykładowo, nie poz-
wala na podłączenie się do działającej już
sesji lub współdzielenie pulpitu z innym
użytkownikiem. Jeśli zależy nam na takich
funkcjach, musimy wypróbować inne pro-
gramy, opisane w dalszych rozdziałach.

Zdalny pulpit w GNOME

Prędzej czy później możemy znaleźć się
w sytuacji, w której chcielibyśmy, aby zna-

Rysunek 1.

Klienta NX możemy

wypróbować na testowym serwerze
udostępnionym przez NoMachine

dla początkujących

52

styczeń 2006

dla początkujących

zdalny dostęp do pulpitu

53

www.lpmagazine.org

jomy administrator nieco nam pomógł.
Najprościej byłoby go zaprosić, aby móc
obserwować, co robi i uczyć się od niego.
Po co jednak mamy go fatygować, skoro
nasze komputery są połączone w sieć?
Spróbujmy udostępnić mu nasz pulpit tak,
aby mógł na nim pracować, a równocze-
śnie abyśmy mogli go obserwować.

W nowszych wersjach GNOME taka

funkcjonalność jest dostępna od razu
(dzięki programowi Vino). Po uruchomie-
niu programu

vino-preferences

(dostęp-

nego w pakiecie vino) możemy określić,
czy chcemy zezwalać innym użytkowni-
kom na podgląd naszego pulpitu. Oprócz
tego, można pozwolić zdalnym użytkow-
nikom na kontrolowanie naszego pulpitu.
Opcję tę należy zaznaczać bardzo ostroż-
nie – o ile będziemy mieli możliwość
obserwowania poczynań gościa, o tyle
w razie zapomnienia o włączonym ser-
werze możemy zostawić szeroko otwar-
te drzwi dla włamywacza. Aby tego unik-
nąć, mamy do dyspozycji jeszcze dwie
opcje. Pierwsza z nich powoduje wyświe-
tlenie okienka z prośbą o potwierdzenie za
każdym razem, gdy ktoś podłącza się do
naszego pulpitu. Druga pozwala na okre-
ślenie hasła, które będzie musiał podać
gość, zanim otrzyma możliwość oglądania
lub kontrolowania naszego pulpitu.

Gość może podglądać nasz pulpit wyda-

jąc np. polecenie

vncviewer 192.168.1.1:

0

. Oczywiście, zamiast 192.168.1.1 podaje

adres lub nazwę naszego komputera. Pro-
gram Vncviewer jest częścią pakietu vnc.

Bezpieczeństwo

Uruchomienie dodatkowej usługi, która
pozwala na łączenie się z komputerem,
zawsze wiąże się z pewnym zagrożeniem.
Korzystając z Vino, pozwalamy na połą-
czenia na port 5900 TCP naszego kompu-
tera. Najlepiej, aby tylko wybrane osoby
miały możliwość połączenia się z nim.
Wynika to z kilku przyczyn. Po pierw-
sze, może okazać się, że w oprogramo-
waniu jest jakiś błąd, który sprytny wła-
mywacz może wykorzystać do uzyska-
nia dostępu do naszego komputera. Po
drugie, ktoś złośliwy może nam utrud-
niać pracę co chwila próbując połączyć się
z naszym pulpitem. Nawet jeśli ustawili-
śmy konieczność potwierdzenia połącze-
nia, to ciągle wyskakujące okienka mogą
być bardzo uciążliwe. Z tego powodu
powinniśmy ustawić naszą zaporę sie-
ciową tak, aby akceptowała połączenia
na port 5900 TCP tylko z tych kompute-

rów, z których spodziewamy się połączeń
z naszym pulpitem. Może to być tylko sieć
lokalna (komputery w pracowni szkolnej)
lub określony jeden komputer (np. należą-
cy do naszego znajomego administratora).

Oprócz tego, warto pamiętać o tym,

aby udostępniać możliwość połączenia z
naszym pulpitem tylko wtedy, gdy jest to
konieczne, a w pozostałym czasie mieć ją
wyłączoną.

Nawet przy zachowaniu tych zasad

bezpieczeństwa można zwrócić uwagę na
jeszcze jeden fakt. Transmisja podglądu
pulpitu nie jest szyfrowana, więc może
być podsłuchana – szczególnie, jeśli łączy
się z nami ktoś z Internetu. Na szczęście,
możliwe jest zastosowanie SSH do szyfro-
wania takiej transmisji. W tym celu należy
utworzyć tunel. Służy do tego polecenie
postaci:

ssh -C -L 5901:localhost:5900

S

user@192.168.1.1

Wydaje się je na komputerze, na którym
będzie uruchomiony Vncviewer. Zamiast
5901 można użyć innego nieużywanego
numeru portu. Zamiast user i 192.168.1.1
należy podać nazwę użytkownika i adres
lub nazwę komputera, z którym chcemy
się połączyć w celu obejrzenia pulpitu.
Nazwa użytkownika dotyczy naszego
konta na tamtym komputerze – nie musi
to być nazwa użytkownika, którego pulpit
chcemy obejrzeć. Po wydaniu tego polece-

nia i podaniu naszego hasła zalogujemy się
poprzez SSH na nasze konto na zdalnym
komputerze. Równocześnie, na czas trwa-
nia tego połączenia, zostanie utworzony
tunel pomiędzy portem 5901 na kompute-
rze, gdzie ma być uruchomiony Vncviewer,
a portem 5900 na komputerze z podgląda-
nym pulpitem.

Teraz już wystarczy uruchomić Vncviewer

poleceniem

vncviewer localhost:5901

,

a cała transmisja będzie szyfrowana. Nale-
ży zwrócić uwagę, że w takiej konfigura-
cji przy pytaniu o potwierdzenie możliwo-
ści podglądania pulpitu zostanie wyświe-
tlona nazwa komputera lokalnego (tego,
na którym pulpit jest uruchomiony), a nie
zdalnego (tego, gdzie uruchamiany jest
Vncviewer).

Zdalny pulpit w KDE

Podobnie jak GNOME, środowisko KDE
również posiada swoje narzędzie do
współdzielenia pulpitu. Jest to program
Krfb, zawarty w pakiecie kdenetwork. Ma
on nawet większe możliwości niż Vino,
o czym możemy się zorientować po jego
uruchomieniu poleceniem

krfb

.

Od razu na pierwszym ekranie zoba-

czymy przycisk prowadzący do opcji konfi-
guracyjnych (zajmiemy się nimi za chwilę)
oraz trzy przyciski dotyczące zaproszeń.
Pierwszy z z tych trzech pozwala na wyge-
nerowanie osobistego zaproszenia. Po jego
wciśnięciu zobaczymy takie informacje,
jak nazwę komputera i hasło, które powin-

Rysunek 2.

Hasło z zaproszenia trzeba od razu zapisać lub przekazać, gdyż jest

wyświetlane tylko raz

dla początkujących

52

styczeń 2006

dla początkujących

zdalny dostęp do pulpitu

53

www.lpmagazine.org

ny być użyte do połączenia z naszym pul-
pitem, a także datę ważności zaproszenia.
Informacje te możemy przekazać osobie,
której chcemy udostępnić pulpit. Ważne,
aby być pewnym, że przekazujemy je
odpowiedniej osobie, tzn. że nikt tej wia-
domości nie podsłucha ani nie przechwyci.
Dodatkowym zabezpieczeniem jest wspo-
mniany już termin ważności zaprosze-
nia – ze względów bezpieczeństwa jest on
ograniczony do jednej godziny.

Drugi przycisk pozwala wygenero-

wać zaproszenie i od razu wysłać je za
pośrednictwem poczty elektronicznej.
Umieszczone w nim będą wspomniane
już informacje. Należy zwrócić uwagę,
że e-mail nie jest zbyt bezpiecznym spo-
sobem na przekazywanie wiadomości o
hasłach, więc powinniśmy z niego korzy-
stać tylko wtedy, gdy korzystamy z szyfro-
wania wiadomości.

Ostatni przycisk służy do zarządza-

nia udzielonymi zaproszeniami. Na spisie
można sprawdzić, kiedy zostały udzielo-
ne zaproszenia i kiedy kończy się ich waż-
ność. Można wskazać pojedyncze z nich i
skasować je, skasować wszystkie, a także
skorzystać z dwóch przycisków mających
te same funkcje, co wspomniane już przy-
ciski na głównym ekranie.

Korzystanie z zaproszeń jest najbez-

pieczniejsze, gdyż upoważnia zdalnego
użytkownika tylko do jednego logowa-
nia – przydzielone hasło jest wykorzysty-
wane tylko raz. Nie oznacza to jednak, że
nie można logować się w ten sposób, jak
w Vino, czyli podając jedno, stałe hasło.
Byłaby to wielka strata, gdyż taka możli-
wość przydaje się, gdy gdzieś wyjeżdżamy
i chcemy coś sprawdzić na naszym pulpi-
cie uruchomionym w domu. Ponieważ
domyślnie można logować się tylko z uży-
ciem zaproszeń, w celu zmiany tej opcji
musimy skorzystać z przycisku otwierają-
cego okno konfiguracji.

Mamy tam do dyspozycji trzy zakład-

ki. Interesująca nas opcja, pozwalająca
na połączenia bez zaproszenia, znajdu-
je się na pierwszej. Jeśli zdecydujemy się
ją zaznaczyć, powinniśmy również roz-
ważyć zaznaczenie opcji sprawiającej, że
każde połączenie bez zaproszenia musi
zaakceptować użytkownik korzystający z
pulpitu. Warto też podać hasło wymaga-
ne od łączącego się użytkownika. Opcję
pozwalającą użytkownikom łączącym się
bez zaproszenia na kontrolowanie pulpi-
tu należy zaznaczać bardzo ostrożnie. Na
drugiej i trzeciej zakładce mamy do dyspo-

zycji po jednej opcji. Pierwsza z nich powo-
duje wyłączenie tapety podczas sesji zdal-
nej (może to nieco zwiększyć wydajność,
szczególnie w przypadku bardzo koloro-
wej tapety), natomiast druga pozwala na
wybranie portu wykorzystywanego przez
serwer (lub skorzystanie z przydzielania
automatycznego). Domyślnie wykorzysty-
wany jest port 5900, podobnie jak w przy-
padku Vino.

Umieszczone w poprzednim rozdzia-

le informacje o zaporze sieciowej i szyfro-
waniu sesji dotyczą również przypadku
korzystania z Krfb.

XDMCP

(słabszy komp jako terminal)

W dzisiejszych czasach sprzęt kompute-
rowy starzeje się coraz szybciej. Często
zdarza się, że w celu unowocześnie-
nia komputera trzeba wymienić więk-
szość komponentów lub po prostu zaku-
pić nowy komputer. Pozostaje problem,
co zrobić ze starszym sprzętem, któ-
rego często nikt nie chce kupić. Dzięki
Linuksowi (a właściwie dzięki protokoło-
wi XDMCP) nawet dość antyczny sprzęt
wciąż możemy wykorzystać choćby jako
terminal. W sieci lokalnej (czy to w domu,
czy w firmie) takie rozwiązanie może
okazać się bardzo dobre. W dodatku,
odpowiednie skonfigurowanie Linuksa
okazuje się być bardzo proste.

Czynności wstępne

Na początku musimy upewnić sie, że
mamy do dyspozycji dwa komputery
połączone w sieć. Najlepiej, aby znajdowa-
ły się one w jednym segmencie sieci lokal-
nej – zarówno ze względu na bezpieczeń-
stwo (mniejsza szansa na podsłuch), jak
i wydajność. Ten z komputerów, który
ma pełnić rolę serwera, powinien urucha-
miać się w środowisku graficznym, a nie
tekstowym. Jeśli po uruchomieniu kom-
putera widzimy ładny ekran logowania,
w którym możemy podać nazwę użyt-
kownika i hasło, to jest to właśnie to, o co
nam chodzi. Za wyświetlenie tego ekranu
odpowiada menedżer logowania, którym
najprawdopodobniej jest GDM, KDM lub
XDM – może to być uzależnione od kon-
figuracji naszej dystrybucji. Drugi kompu-
ter (będziemy go nazywać terminalem lub
klientem) może się uruchamiać w trybie
tekstowym.

O tym, czy komputer przedstawi gra-

ficzny, czy tekstowy ekran logowania,
w przypadku dystrybucji Aurox (a także

Fedora i podobnych) decyduje wpis w pli-
ku /etc/inittab. Jeśli znajduje się tam linia
o treści

id:5:initdefault:

, to system

uruchomi się w trybie graficznym, nato-
miast trybowi tekstowemu odpowiada
linia

id:3:initdefault:

. Odpowiedniej

zmiany można dokonać dowolnym edy-
torem (np.

gedit /etc/inittab

) po uzy-

skaniu uprawnień administratora (wyda-
jąc polecenie

su -

i podając hasło użyt-

kownika root).

W tym samym pliku możemy znaleźć

linię o treści podobnej do poniższej:

x:5:respawn:/etc/X11/prefdm -nodaemon

Taka linia oznacza, że w piątym pozio-
mie uruchomieniowym jako menedżer
logowania będzie użyty program wska-
zany przez skrypt /etc/X11/prefdm. Należy
usunąć z niej parametr -nodaemon, w rezul-
tacie uzyskując linię o treści:

x:5:respawn:

/etc/X11/prefdm

.

Dzięki temu nasz menedżer logowania bę-
dzie mógł służyć nie tylko do obsługi lokal-
nego logowania, ale będzie też czekał na
połączenia nadchodzące z innych kom-
puterów (oczywiście, zanim tak się stanie,
musimy skonfigurować jeszcze kilka rze-
czy). Jeśli chcielibyśmy przy okazji zmienić

Co znaczą te skróty?

W artykule jest użytych kilka skrótów, które
mogą wymagać bliższego wyjaśnienia.

VNC (Virtual Network Computing) to

system pozwalający na zdalne kontrolo-
wanie środowiska graficznego. Opiera się
na protokole RFB (Remote FrameBuffer),
odpowiadającym za zdalny dostęp do gra-
ficznego interfejsu użytkownika.

XDMCP (X Display Manager Control

Protocol) to protokół, z użyciem które-
go komunikuje się menedżer logowania.
Dzięki niemu użytkownik może spraw-
dzić, które komputery w sieci przyjmują
połączenia, a nawet uzyskać podstawowe
informacje o tych komputerach. Może też
po prostu bezpośrednio podłączyć się do
zdalnego menedżera logowania.

NX to zestaw technologii i narzędzi

mających na celu ułatwienie i uprzyjem-
nienie korzystania ze zdalnego dostępu
do środowisk graficznych. Jego główną
częścią jest wyjątkowo skuteczny proto-
kół kompresji, pozwalający na wygodny
dostęp do zdalnego pulpitu nawet na sto-
sunkowo wolnych łączach.

dla początkujących

54

styczeń 2006

dla początkujących

zdalny dostęp do pulpitu

55

www.lpmagazine.org

menedżer logowania, można po prostu zmie-
nić tę linię tak, aby miała np. treść:

x:5:respawn:/usr/bin/gdm

Bardziej poprawną metodą jest pozostawie-
nie tej linii w spokoju, a zamiast tego doko-
nanie zmiany w pliku /etc/sysconfig/desktop,
gdzie powinna znaleźć się linia o treści:

DISPLAYMANAGER="GNOME"

W takim przypadku preferowanym mene-
dżerem logowania będzie GDM. Jeśli wo-
limy KDM, to zamiast GNOME wpisuje
my KDE. Miłośnicy klasycznego XDM wpi-
sują XDM (sic!).

Gdy spełnimy już powyższe warunki,

możemy przejść do właściwej konfiguracji.

Konfiguracja

Wciąż korzystając z uprawnień administra-
tora zaczynamy od edycji pliku /etc/X11/
xdm/xdm-config. Odnajdujemy linię (za-
zwyczaj jest ona ostatnia) o treści:

DisplayManager.requestPort: 0

Powoduje ona, że menedżer logowania
nie oczekuje zapytań XDMCP. Aby to
zmienić, musimy usunąć tę linię lub po
prostu zamienić ją na komentarz. W tym
drugim przypadku wystarczy na począt-
ku linii dodać wykrzyknik, aby wygląda-
ła tak:

! DisplayManager.requestPort: 0

Po zapisaniu zmian zajmujemy się edycją
pliku /etc/X11/xdm/Xaccess. Wśród wielu
linii komentarza znajdujemy linię o
treści:

#* # any host can get a login window

Usuwamy znak komentarza (#) z począt-
ku linii. Dzięki takiemu zapisowi dowol-
ny komputer będzie mógł połączyć się
z naszym serwerem za pomocą XDMCP.
Ze względów bezpieczeństwa niekoniecz-
nie jest to najlepszy pomysł. Jeśli chcemy,
aby mogły się łączyć tylko komputery
z naszej sieci lokalnej, to najlepiej podać jej
adres (np. 192.168.0.* dla sieci 192.168.0.0
o masce 255.255.255.0). Gdy wystarczy
nam, jeśli może się łączyć tylko jeden kon-
kretny komputer (np. o adresie 192.168.
0.15), to również możemy ograniczyć mo-
żliwość połączeń tylko do niego, zmienia-
jąc powyższą linię na taką:

192.168.0.15 # only host
192.168.0.15 can get a login window

Ostatnie zmiany zależą od tego, z którego
menedżera logowania korzystamy. W razie
braku pewności, zawsze możemy wprowa-
dzić wszystkie.

W przypadku korzystania z GDM edy-

tujemy plik /etc/X11/gdm/gdm.conf. W sekcji
[xdmcp] powinniśmy zadbać o to, aby
następujące opcje nie były zakomentowa-
ne (linie nie mogą zaczynać się od znaku #)
i aby miały wskazane poniżej wartości:

Enable=true
Port=177

Użytkownicy KDM takie same zmiany
powinni wprowadzić w pliku /etc/kde/kdm/
kdmrc. Plik ten w niektórych dystrybucjach
może znajdować się w innym katalogu,
np.: /usr/share/config/kdm/kdmrc lub /opt/kde2/
share/config/kdm/kdmrc.

Na koniec musimy jeszcze zadbać, aby

nasza zapora sieciowa (firewall) nie dopusz-
czała połączeń przechodzących z Internetu
na port 177 UDP, a równocześnie, aby
pozwalała na takie połączenia z kompute-
rów, które mają służyć jako terminale.
Sposób uzyskania takiego efektu zależy od
konstrukcji naszej zapory sieciowej. Wyko-
nanie tej czynności nie jest bezwzględnie
konieczne, ale z pewnością zredukuje ryzy-
ko związane z uruchomieniem nowej usłu-
gi. Przykładowa regułka blokująca dostęp
z zewnątrz do komputera o adresie 192.
168.0.1 poprzez interfejs sieciowy eth1 może
wyglądać tak:

iptables -A INPUT -i eth1

S

-p udp -d 192.168.0.1

S

--destination-port 177 -j REJECT

Po ponownym uruchomieniu syste-
mu (bardziej doświadczeni użytkowni-
cy mogą się ograniczyć do zrestartowa-
nia Xinit, menedżera logowania i ustawień
zapory sieciowej) powinno już być możli-
we nawiązanie połączenia z terminali.

Korzystanie

Po odpowiednim skonfigurowaniu ser-
wera możemy wreszcie przesiąść się na
nasz terminal i zacząć pracę. Po zalogo-
waniu się do systemu wpisujemy tylko
jedno polecenie:

X -query 192.168.1.1

.

Oczywiście, zamiast 192.168.1.1 używa-
my adresu (lub nazwy) naszego serwe-
ra. Po chwili powinien pojawić się mene-
dżer logowania, gdzie możemy wpisać
nazwę użytkownika i hasło, z jakiego
korzystamy na serwerze. Jeśli już mamy
uruchomioną sesję tego użytkownika na
serwerze, to zostaniemy ostrzeżeni, ale mo-
żemy spokojnie wymusić rozpoczęcie sesji.
I to wystarczy – widzimy teraz na ekranie
dokładnie to, co byśmy widzieli po zalogo-
waniu się bezpośrednio na serwerze.

X11vnc

Omówiliśmy dotąd sytuacje, gdy siedzi-
my przy komputerze i chcemy komuś
udostępnić nasz pulpit. Co zrobić w sytu-
acji, gdy wyszliśmy z pracy zapominając
zamknąć jakiś program, który nie powi-
nien już działać? Powrót do firmy często
nie wchodzi w rachubę, a zwlekanie do
następnego dnia może się dla nas skoń-
czyć naganą. O ile tylko mamy dostęp do
naszego komputera przez SSH, to możemy
sobie w takiej sytuacji poradzić. Z pomocą
przychodzi X11vnc, który pozwala na pod-
łączenie się do działającej już sesji X.

Instalacja

W przypadku dystrybucji Red Hat, Aurox
i Fedora program X11vnc można pobrać
z repozytorium DAG. Jeśli korzystamy
z programu Yum i mamy dodane repozy-
torium DAG, to instalacja ogranicza się do
wydania polecenia

yum install x11vnc

.

W innym przypadku musimy pobrać
odpowiedni pakiet dla naszej dystrybucji
(np. x11vnc-0.7.2-1.1.fc3.rf.i386.rpm) ze stro-
ny http://dag.wieers.com/packages/x11vnc/,
a następnie zainstalować go (np. polece-
niem

rpm -Uvh x11vnc-0.7.2-1.1.fc3.rf.

i386.rpm

).

Korzystanie

Z lokalnego komputera musimy połączyć
się (np. za pośrednictwem SSH) ze zdal-

Rysunek 3.

Dzięki SSH możemy

swobodnie uruchamiać zdalnie pojedyncze
programy

dla początkujących

54

styczeń 2006

dla początkujących

zdalny dostęp do pulpitu

55

www.lpmagazine.org

nym komputerem (w naszym przykładzie
stojącym w pracy) i zalogować się na konto
użytkownika, który uruchomił system
X Window. Teraz wystarczy uruchomić
polecenie

x11vnc -display :0

. Jeśli się po-

wiedzie, to otrzymamy odpowiedni
komunikat, podający nazwę, jaką mamy
wpisać do klienta VNC oraz numer portu
(zazwyczaj 5900). Podobnie jak w po-
przednich przypadkach, pozostaje nam
wydać polecenie

vncviewer

jako argu-

ment podając nazwę lub adres kompute-
ra w pracy.

Po zamknięciu klienta VNC program

X11vnc automatycznie zakończy działa-
nie. Jeśli nie odpowiada nam takie zacho-
wanie, możemy uruchomić X11vnc z opcją
-forever. W każdym z tych przypadków
warto pomyśleć o zabezpieczeniu dostępu
do pulpitu hasłem. W tym celu najlepiej
utworzyć plik, w którym w pierwszej i dru-
giej linii będą podane dwa hasła. Pierwsze
z nich będzie pozwalało na podglądanie
i kontrolowanie pulpitu, a drugie tylko
na podglądanie. Plik ten (o przykłado-
wej nazwie ~/pass.txt) należy zabezpie-
czyć przed dostępem osób postronnych
wydając polecenie

chmod 600 ~/pass.txt

.

Dzięki temu tylko właściciel pliku
będzie mógł go odczytać i modyfikować.
Uruchomienie X11vnc z użyciem pliku
z hasłami odbywa się po wydaniu pole-
cenia:

x11vnc -display :0 -forever
-passwdfile ~/pass.txt

Uwagi umieszczone w rozdziale o zdal-
nym pulpicie w GNOME odnośnie zapory
sieciowej i przesyłania transmisji tunelem
SSH odnoszą się również do X11vnc. W
tym przypadku możemy nawet jednym
poleceniem równocześnie utworzyć tunel
i uruchomić X11vnc:

ssh -L 5901:localhost:5900
user@192.168.1.1 'x11vnc
-localhost -display :0'

Oczywiście, w takim przypadku klien-
ta uruchamiamy poleceniem

vncviewer

localhost:5901

.

Tunelowanie po SSH

Jeśli potrzebujemy tylko uruchomić poje-
dynczy program ze zdalnego komputera,
to często nie ma sensu łączyć się z całym
pulpitem. Zamiast tego możemy skorzy-
stać z pewnej opcji SSH, która pozwa-

la na przesyłanie połączeń X11 bezpiecz-
nym kanałem. Wystarczy połączyć się ze
zdalnym komputerem (w naszym przy-
kładzie o adresie 192.168.1.1) za pomocą
polecenia:

ssh -X user@192.168.1.1

Po podaniu hasła użytkownika user zalo-
gujemy się tradycyjnie na nasze konto,
ale dzięki opcji -X będziemy mieli więk-
sze możliwości. Jeśli uruchomimy jakiś
program z interfejsem graficznym (np.
przeglądarkę obrazków poleceniem

gqview

lub kalkulator poleceniem

kcalc

),

to aplikacja wyświetli się na naszym
ekranie. W ten sposób możemy pracować
z tymi programami, które akurat są nam
potrzebne.

Zakończenie

Jest wiele scenariuszy, w których koniecz-
ne lub co najmniej przydatne może się
okazać zdalne korzystanie ze środowi-
ska graficznego. Jak widać z niniejszego
artykułu, do praktycznie każdego zasto-
sowania można dopasować odpowiednie
narzędzie. Oprócz omawianego w artyku-
le klienta Vncviewer można znaleźć rów-
nież wiele innych klientów (np. TightVNC
i RealVNC), często rozprowadzanych
razem z innymi serwerami VNC. Wy-
bór jednego z nich to w dużej mierze
kwestia gustu. Większość klientów bez-
problemowo działa z różnymi serwera-
mi VNC.

W Internecie:

• Strona domowa FreeNX:

http://freenx.berlios.de/

• Strona domowa NoMachine:

http://www.nomachine.com/

• Strona domowa X11vnc:

http://www.karlrunge.com/x11vnc/

• Angielska Wikipedia o VNC:

http://en.wikipedia.org/wiki/VNC

• Angielska Wikipedia o XDMCP:

http://en.wikipedia.org/wiki/XDMCP

• Angielska Wikipedia o NX:

http://en.wikipedia.org/wiki/
NX_technology

• Strona domowa TightVNC:

http://www.tightvnc.com/

• Strona domowa RealVNC:

http://www.realvnc.com/