Zdalny pulpit i system LINUX

Transkrypt

1 Wprowadzenie: Popularność systemów rodziny MS Windows na komputerach osobistych nie podlega dyskusji. Wielu administratorów maszyn wykorzystujących pracujących po Linuksie zadaje pytania związane z uzyskaniem pełnego dostępu do systemu Linux ze swego komputera osobistego. Najczęściej wykorzystują oni w tym celu popularne oprogramowanie PuTTY, które realizuje takie połączenie za pomocą protokołu SSH (opcjonalnie telnet) jednakże jedynie w trybie znakowym. Możliwość wykonywania podstawowych czynności administracyjnych w środowisku graficznym jest dla wielu administratorów na tyle atrakcyjna, że producenci dystrybucji systemu LINUX (w tym RedHat Enterprise Linux) stawiają do dyspozycji coraz bogatszy zestaw przeznaczonych do takiej administracji narzędzi programistycznych. Nie tylko przyspieszają one wykonywanie codziennych zadań administracyjnych, lecz również w wielu przypadkach zapobiegają popełnianiu prostych błędów. Efektywna administracja wymaga dostępu w trybie terminalowym, a więc tylko taki tryb będzie rozważany w dalszej części tego opracowania. Projekt mający na celu opracowanie serwera protokołu RDP (Remote Desktop Protocol) dla systemu LINUX ( ). Wersja dla systemu RedHat jest dostępna w repozytorium EPEL ( ) jako pakiet o nazwie xrdp. Instalujemy go standardowo ( yum install xrdp ). Serwer xrdp wymaga do działania obsługi zdalnego bufora ramki (RFB), niezbędna więc może być instalacja serwera VNC (o ile nie zainstalowaliśmy go już wcześniej). Uruchomienie xrdp jest bardzo proste ponieważ skrypt startowy serwera znajdzie się po instalacji w standardowym katalogu: [root@main init.d]# cd /etc/init.d [root@main init.d]#./xrdp start Uruchamianie xrdp: [ OK ] Uruchamianie xrdp-sesman: [ OK ] Serwer xrdp (w standardowej konfiguracji) jest gotowy do pracy i możemy połączyć się z naszą maszyną RedHat Enterprise Linux z dowolnego komputera MS Windows. Strona 1 z 11

2 W systemie Windows uruchamiamy program Remote Desktop Connection (z grupy Accesories): Serwer xrdp wyświetli winietę logowania: Strona 2 z 11

3 i po uwierzytelnieniu na ekranie komputera z systemem MS Windows pojawi się pulpit systemu RedHat Enterprise Linux: Serwer xrdp można wykorzystać również do uzyskania zdalnego dostępu do systemu LINUX z każdego systemu operacyjnego, który jest wyposażony w klienta programowego protokołu RDP. Może to być więc także system LINUX (inna dystrybucja). Strona 3 z 11

4 Po nawiązaniu połączenia otwarte zostanie okno na pulpicie umożliwiające dostęp terminalowy zdalnego systemu LINUX: Oczywiście nie ma żadnych przeszkód, aby przygotować odpowiedni aktywator automatyzujący nawiązywanie takiego połączenia. Strona 4 z 11

5 Zaawansowana konfiguracja serwera xrdp: Zgodnie z praktyką stosowaną w systemie LINUX pliki konfiguracyjne serwera xrdp są umieszczane w osobnym katalogu: # ls -l /etc/xrdp... -rw root root :19 rsakeys.ini -rw-r--r-- 1 root root sesman.ini -rwxr-xr-x 1 root root startwm.sh -rw-r--r-- 1 root root xrdp.ini -rwxr-xr-x 1 root root xrdp.sh (celowo pominięto pliki zawierające mapy klawiatur) Po uruchomieniu serwera xrdp uruchamiane są dwa procesy (demony): [root@main xrdp]# ps -ef grep xrdp root :09 pts/1 00:00:00 /usr/sbin/xrdp root :09 pts/1 00:00:00 /usr/sbin/xrdp-sesman Każdy z nich posiada własny plik konfiguracyjny w katalogu /etc/xrdp. Pliki te można edytować, co skutkuje zmianami właściwości serwera xrdp. Pełne opisy tych plików i wyjaśnienia definiowanych przez nie parametrów są dostępne za pomocą standardowego systemu man: man xdrp.ini man sesman.ini Niewątpliwą zaletą xrdp jest możliwość korzystania z dowolnego klienta programowego protokołu RDP, który jest dołączany do wielu systemów operacyjnych. Największa wada to stosunkowo spore wymagania stawiane kanałom komunikacyjnym, co powoduje trudności w jego wykorzystywaniu w sieciach rozległych. Bezpieczeństwo xrdp opiera się o algorytm RSA. Klucze są generowane automatycznie i umieszczane w pliku /etc/xrdp/rsakeys.ini. Możemy także wygenerować własne klucze za pomocą polecenia xrdp-keygen. Wygenerowane klucze zastępują poprzednie (zawarte w pliku rsakeys.ini), które już nie mogą być przywrócone. Autorzy oprogramowania nie polecają (a właściwie wprost zabraniają) użycia opcji test programu xrdp-keygen. Strona 5 z 11

6 NoMachine NX Włoska firma NoMachine ( ) oferuje swe produkty na zasadach subskrypcyjnych (podobnych do stosowanych przez firmę RedHat), jednakże dla celów zdalnej administracji udostępnia nieodpłatnie wersję Free NX Sever, dla którego liczbę połączeń ograniczono do 2 użytkowników. Jest to oczywiście całkowicie wystarczające dla administratorów systemu (z zasady przecież korzystają oni z jednego połączenia). Oprogramowanie serwera NX jest dostępne dla praktycznie wszystkich dystrybucji Linuksa (oraz dla systemu Solaris). Firma NoMachine udostępnia również nieodpłatnie oprogramowanie NX Client dla wszystkich wersji systemów rodziny MS Windows, Linux, MacOS oraz Solaris. Oprogramowanie NX opracowano zwracając szczególną uwagę na wydajność połączenia, ograniczenie opóźnień round-trip delay oraz na zapewnienie bezpieczeństwa. Uzyskano to stosując adaptacyjny mechanizm kompresji transmitowanych danych oraz tunelowanie transmisji graficznych protokołu X Window za pomocą protokołu SSH. Instalacja oprogramowania jest bardzo prosta. Na serwerze należy zainstalować trzy moduły programowe NXclient, NXserver oraz NXnode. Są one dostępne w postaci pakietów (również rpm). Po instalacji sprawdzamy, czy demon sshd jest uruchomiony: ps -ef grep sshd root :48? 00:00:00 /usr/sbin/sshd -o PidFile=/var/run/sshd.init.pid oraz, czy w pliku /etc/passwd istnieje wpis użytkownika o nazwie nx: grep nx /etc/passwd nx:x:111:100::/usr/nx/home/nx:/usr/nx/bin/nxserver Na komputerze klienta (MS Windows, Linux, MacOS, Solaris) instalujemy odpowiednią wersję klienta. Jeśli instalacja przebiegła bez problemów przystępujemy do konfiguracji klienta NX. Strona 6 z 11

7 Program konfiguracyjny typu Wizard (z punktu widzenia użytkownika identyczny dla różnych systemów operacyjnych) jest intuicyjny i nie wymaga dokładniejszego opisu. Zakładka Advanced umożliwia zmiany parametrów transmisji i pamięci cache, Services pozwala na udostępnienie zasobów klienta serwerowi oraz włączenie obsługi multimediów, Environment pozwala na konfigurację środowiska klienta. Konfigurację kończy umieszczenie aktywatora (skrótu) połączenia na pulpicie użytkownika: Strona 7 z 11

8 Klient NX tworzy dla każdej sesji plik konfiguracyjny o nazwie <nazwa_sesji>.nxs. Poniżej zamieszczono jego początkowy fragment: <!DOCTYPE NXClientSettings> <NXClientSettings application="nxclient" version="1.3" > <group name="advanced" > <option key="cache size" value="64" /> <option key="cache size on disk" value="256" /> <option key="current keyboard" value="true" /> <option key="custom keyboard layout" value="" /> <option key="disable DirectDraw" value="false" /> <option key="disable ZLIB stream compression" value="false" /> <option key="disable deferred updates" value="false" /> <option key="enable HTTP proxy" value="false" /> <option key="enable SSL encryption" value="true" /> <option key="enable response time optimisations" value="false" /> Pliki konfiguracyjne sesji są identyczne dla różnych systemów i mogą być bezpośrednio edytowane, jednak ze względu na różnice w formatowaniu użytkownicy systemu MS Windows używający np. notepada powinni zachować szczególną ostrożność podczas edycji, ponieważ jest on traktowany jako jedna linia: Po wybraniu aktywatora połączenia pojawi się winieta klienta NX: Strona 8 z 11

9 Umożliwia ona dokonanie wyboru sesji spośród wcześniej skonfigurowanych i zapisanych w plikach o <nazwa_sesji>.nxs w katalogu ~/.nx/config. Połączenie klienta z serwerem jest realizowane w dosyć wyrafinowany sposób. Klient łączy się wstępnie z serwerem wykorzystując konto użytkownika nx, którego powłoką systemową jest program nxserver: nx:x:111:100::/usr/nx/home/nx:/usr/nx/bin/nxserver Uwierzytelnienie następuje z wykorzystaniem algorytmu DSA (Digital Signature Algorithm). Domyślne klucze klienta i serwera mogą być zastąpione przez wygenerowane indywidualnie za pomocą polecenia: /usr/nx/scripts/setup/nxserver --keygen Wygenerowaną parę kluczy należy zainstalować na serwerze oraz kliencie (zgodnie ze wskazówkami dokumentacji). Funkcja Import key w zakładce General NX klienta ułatwia to zadanie: Strona 9 z 11

10 Przygotowanie własnej pary kluczy pozwala na wprowadzenie uwierzytelnienia klientów NX z serwerem. Połączenie może zostać dokonane jedynie wówczas, gdy klucze serwera i klienta tworzą odpowiadającą sobie parę. Po uwierzytelnieniu i nawiązaniu wstępnego połączenia uruchamiany jest program xserver (powłoka użytkownika nx) i klient przekazuje dane użytkownika (login i hasło). Oczywiście jest ono przekazywane już po pozytywnym obustronnym uwierzytelnieniu za pomocą szyfrowanego kanału transmisji. W zależności od konfiguracji serwera możliwe jest wykorzystanie dwóch różnych mechanizmów uwierzytelnienia użytkownika (II etap): 1. mechanizm systemowy (sshd + pam), 2. własna baza danych NoMachine NX (NX Password DB) W pierwszym przypadku dostęp do systemu może uzyskać każdy użytkownik posiadający odpowiednio skonfigurowane konto w systemie, w drugim dostęp mogą uzyskać tylko użytkownicy, których dane umieszczono w bazie NoMachine NX. Wybór metody uwierzytelnienia użytkowników należy ustawić w pliku konfiguracyjnym serwer NX ( /usr/nx/etc/server.cfg ): EnablePasswordDB = "1" (hasła dostępu przechowywane w bazie NX) lub EnablePasswordDB = "0" (systemowe hasła dostępu) Możliwe jest także utworzenie bazy uprawnionych użytkowników serwera NX za pomocą dyrektywy: EnableUserDB = "0"/"1" NoMachine NX nie pozwala na realizację połączeń SSH bez użycia hasła użytkownika. Szczegółowe opisy instalacji oraz konfiguracji oprogramowania NoMachine NX znajdują się w dokumentacji udostępnianej przez producenta. Komercyjne wersje oprogramowania umożliwiają realizację połączeń przez wielu użytkowników, pracę w klastrach z równoważeniem obciążenia, monitorowanie i zarządzanie sesjami itp., należy jednak zdecydowanie stwierdzić, że dla celów zdalnej administracji serwerami Linux z komputerów wykorzystujących inne systemy operacyjne (np. MS Windows) wersja nieodpłatna jest całkowicie wystarczająca. Strona 10 z 11

11 Uwagi końcowe: Największą zaletą oprogramowania NX jest możliwość pracy w sieci rozległej. Producent udostępnia serwer testowy zlokalizowany w Niemczech testdrive.millenux.com, z którym można się połączyć wykorzystując opcję guest i przetestować pracę i wydajność połączenia: Łącze internetowe o przepustowości 1 Mbps umożliwia bezproblemową pracę na tym testowym serwerze (oczywiście zależy to również od chwilowego obciążenia tego serwera). Praca w sieci lokalnej praktycznie nie narzuca żadnych znaczących ograniczeń w porównaniu z pracą na konsoli lokalnej. Połączenie jest równie bezpieczne jak w przypadku wykorzystywania SSH (PuTTY) i wymaga również takiej samej konfiguracji systemów Firewall (standardowy port SSH 22 lub inny w zależności od koncepcji rozwiązania sieciowego). Strona 11 z 11