Voraussetzung für alle Server¶

Die Kommunikation zwischen Server und Client läuft bei NX grundsätzlich verschlüsselt ab. Daher muss zunächst ein SSH-Server installiert werden ^[1]:

• openssh-server

Befehl zum Installieren der Pakete:

sudo apt-get install openssh-server  

Oder mit apturl installieren, Link: apt://openssh-server

Die Voreinstellungen sind für den Heimanwender akzeptabel. Weitergehende Informationen befinden sich im Artikel SSH.

FreeNX¶

Die beste Alternative zum Original-Server von NoMachine stellt der FreeNX Server 🇬🇧 dar. FreeNX ist eine Implementierung des NX-Servers unter der GPL-Lizenz, nachdem die Basisbibliotheken und alle wichtigen Kernbestandteile von NX von NoMachine freigegeben wurden (aber nicht der Quellcode der Client- bzw. Server-Software).

Adresszeile zum Hinzufügen des PPAs:

• ppa:freenx-team/ppa

Dann installiert man folgendes Paket:

• freenx-server (ppa)

Befehl zum Installieren der Pakete:

sudo apt-get install freenx-server 

Oder mit apturl installieren, Link: apt://freenx-server

sudo /usr/lib/nx/nxsetup --install 

sudo dpkg-reconfigure freenx-server 

Do you want to abort now? [y/N]

Do you want to use your own custom KeyPair? [y/N]

Are you sure you want to continue connecting (yes/no)?

HELLO NXSERVER - Version 1.4.0-45-SVN OS (GPL)
NX> 105 quit
Quit
<--- done
Ok, nxserver is ready.
PAM authentication enabled:
  All users will be able to login with their normal passwords.
  PAM authentication will be done through SSH.
  Please ensure that SSHD on localhost accepts password authentication.
  You can change this behaviour in the /etc/nxserver/node.conf file.
Have Fun!

NoMachine NX Server¶

Das italienische Unternehmen NoMachine 🇬🇧 hat die Software NX ursprünglich entwickelt und stellt selbst eine Serveranwendung zur freien Verfügung, allerdings mit der Einschränkung, dass in der aktuellen Version 3 lediglich zwei Benutzer gleichzeitig auf den Server Zugriff haben. Benötigt man mehr als zwei gleichzeitige Benutzer, so muss man eine entsprechende Lizenz erwerben oder auf eine der anderen Alternativen ausweichen.

Zur Installation wählt man auf der NoMachine 🇬🇧 Seite "NX Free Edition for Linux", dann die Variante "DEB - i386" bzw. "DEB - x86_64" entsprechend der eigenen Architektur und lädt anschließend die Pakete Client, Node und Server herunter. Bei der Installation der Pakete ^[3] sollte die folgende Reihenfolge eingehalten werden:

• nxclient_*_i386.deb bzw. nxclient_*_x86_64.deb (enthält wichtige Bibliotheken für nxnode)

• nxnode_*_i386.deb bzw. nxnode_*_x86_64.deb (enthält wichtige Bibliotheken für nxserver)

• nxserver_*_i386.deb bzw. nxserver_*_x86_64.deb

Der Server erhält grundsätzlich keinen Menüeintrag, sondern wird mit dem Start des Rechners als Dienst automatisch gestartet. Die manuelle Steuerung erfolgt über die Befehle ^[2]:

/usr/NX/bin/nxserver --start 

bzw.

/usr/NX/bin/nxserver --stop 

Benutzer können über die Benutzerverwaltung von NX festgelegt werden. Dazu dienen die Befehle:

/usr/NX/bin/nxserver --useradd <Benutzername> 

und

/usr/NX/bin/nxserver --userdel <Benutzername> 

Neatx¶

Bei Neatx 🇬🇧 handelt es sich um eine von Google initiierte freie Implementierung der NX-Technologie. Für Ubuntu 10.04 Lucid Lynx steht ein entsprechendes Paket im PPA des FreeNX-Teams bereit. Es muss folgendes Paket installiert werden:

• neatx (ppa)

Befehl zum Installieren der Pakete:

sudo apt-get install neatx 

Oder mit apturl installieren, Link: apt://neatx

Für anderen Versionen stehen kein Pakete zur Verfügung, weswegen Neatx dann aus dem Quellcode kompiliert werden muss. Weitere Informationen finden sich auf der Projektseite 🇬🇧 und im Artikel Subversion.

NoMachine NX Client¶

Die Installation des NoMachine-NX-Clients gestaltet sich analog zum Server. Für einen Ubuntu-Client wählt man auf der Download-Seite 🇬🇧 von NoMachine "NX Client Products", dann Linux und anschließend die Variante "DEB - i386" bzw. "DEB - x86_64" entsprechend der eigenen Architektur. Nach dem Herunterladen des Pakets kann dieses installiert werden ^[3]:

• nxclient_*_i386.deb bzw. nxclient_*_x86_64.deb

Evtl. erfolgt für den Client unter Umständen kein automatischer Menüeintrag ("Internet → NX Client for Linux"). Dann muss man die Dateien /usr/NX/share/applnk/network-gnome/*.desktop manuell nach ~/.local/share/applications kopieren.

Benutzt man eine anderes Betriebssystem, muss das für dieses Betriebssystem passende Paket ausgewählt und entsprechend installiert werden.

QtNX¶

Eine Alternative zum Client von NoMachine ist QtNX.

Eine Einschränkung besteht dadurch, dass 'Custom-Einstellungen' nicht aktiviert werden können und damit nicht ausschließlich ein einzelnes Programm-Fenster gestartet und entsprechend schneller übertragen werden kann; dies funktioniert beim Original.

QtNX ist in den Paketquellen enthalten und kann direkt installiert werden:

• qtnx (universe)

Befehl zum Installieren der Pakete:

sudo apt-get install qtnx 

Oder mit apturl installieren, Link: apt://qtnx

Nach der Installation kann das Programm via qtnx in einem Terminal gestartet werden. Bei Bedarf kann man dem Anwendungsmenü manuell einen Eintrag hinzufügen ^[4].

OpenNX¶

OpenNX 🇬🇧 ist zwar kein Bestand der offiziellen Paketquellen, aber über ein OBS-Repository bis einschließlich Ubuntu 12.10 verfügbar. Dieses fügt man in zwei Schritten als Paketquelle hinzu. Beispiel für Ubuntu 12.04:

1. Einbinden der Paketquelle:

   sudo add-apt-repository 'deb http://download.opensuse.org/repositories/home:/felfert/xUbuntu_12.04 ./'  

   Hinweis!

   Zusätzliche Fremdquellen können das System gefährden.

2. Authentifizieren der Paketquelle:

   wget -q http://download.opensuse.org/repositories/home:/felfert/xUbuntu_12.04/Release.key -O- | sudo apt-key add - 

Nach dem Aktualisieren der Paketquellen kann folgendes Paket installiert werden:

• opennx

Befehl zum Installieren der Pakete:

sudo apt-get install opennx 

Oder mit apturl installieren, Link: apt://opennx

Paralleles Arbeiten am Server¶

Nutzer A sitzt zu Hause am PC und arbeitet unter seinem Account. Nutzer B meldet sich von unterwegs mit seinem eigenen Account an und arbeitet ebenfalls am PC. Wenn man davon absieht, dass jeder weitere Nutzer und die von ihm gestartet Programme Rechenleistung beanspruchen und Ressourcen belegen, läuft dieser Vorgang für A und B unbemerkt ab und stört nicht.

Gleichzeitiges Arbeiten am Server¶

Nutzer A sitzt zu Hause am PC und hat ein Problem, für das er Nutzer B um Hilfe bittet. Dieser meldet sich am Server als Nutzer A an (benötigt also dessen Benutzernamen und Passwort!) und bekommt eine neue Session. B sieht bei sich nicht den aktuellen Bildschirminhalt von A, obwohl er als A (aber in einer eigenen Session) angemeldet ist!

Auch werden hier im Gegensatz zur klassischen Lösung via VNC Tastatur- und Mausbewegungen nicht ausgetauscht. Davon abgesehen bedeutet die Herausgabe von Benutzernamen und Passwort bei einem gleichzeitig aktiven SSH-Server ein praktisch unkontrollierbares Sicherheitsrisiko.

Der Nachteil kann aber umgangen werden, indem von Nutzer A dessen NX-Session für "Entfernten Desktop" freigegeben wird und sich Nutzer B zu dieser über eine VNC-Verbindung (ggf. über einen SSH-Tunnel) dahin verbindet.

Spezielle Bedienhinweise¶

Kann keine Verbindung aufbauen¶

Kann keine Verbindung zum Server aufgebaut werden, sollte überprüft werden, ob auf dem Server der SSH-Dienst gestartet wurde. Dazu folgenden Befehl auf dem Server im Terminal ^[2] ausführen:

ssh localhost 

Erscheint etwas in der Art wie

The authenticity of host 'localhost (127.0.0.1)' can't be established.
RSA key fingerprint is 66:58:88:c8:c8:ab:2d:67:14:5a:66:89:33:41:b6:71.
Are you sure you want to continue connecting (yes/no)? yes
username@localhost's password:

so ist der SSH Server gestartet. Falls nicht, sollte man überprüfen, warum der Dienst nicht korrekt läuft. Weitere Probleme bei der Authentifizierung können durch eine speziell angepasste ssh-Konfiguration (OpenSSH: /etc/ssh/sshd_config) entstehen (Ausschluss von Passwortauthentifizierung, spezielle Key-Pfade usw.). Evtl. muss man die ssh-Standardkonfigurationen mit NX zu testen. Mehr dazu im Artikel SSH.

Passwortauthentifizierung unter SSH verboten¶

Server: NoMachine NX Free Server (gilt für FreeNX analog)
Client: NoMachine NX Client

Ist der SSH-Server in der Datei /etc/ssh/sshd_config so eingestellt, dass die Anmeldung nur mit öffentlichen und privaten Schlüsseln erfolgen darf ("PubkeyAuthentication yes") und die Anmeldung mit Passwörtern verboten ist ("PasswordAuthentication no"), so gelingt es dem NX Client nicht, sich vollständig anzumelden. Dies liegt daran, dass NX sich zunächst mittels seiner eigenen Schlüssel (siehe Abschnitt "Einrichtung der Schlüssel") als Benutzer nx anmeldet, anschließend aber außerdem den vom Client angegebenen Benutzer mit dessen Passwort beim SSH-Server anmelden will, was natürlich fehlschlägt.

In diesem Fall kann man die Anmeldung statt über SSH durch NX selbst erfolgen lassen. Dazu ändert man in der Datei /usr/NX/etc/server.cfg (Nomachine NX Server) bzw. /etc/nxserver/node.conf (FreeNX) den Eintrag

EnablePasswordDB = "0"

in

EnablePasswordDB = "1"

Anschließend fügt man der Passwort-Datenbank von NX noch den gewünschten Benutzer zu. Dies geschieht mit dem Befehl:

sudo /usr/NX/bin/nxserver --useradd <Benutzername> 

Dabei vergibt man ein Passwort, mit dem man sich anschließend bei NX anmelden kann.

Falls in der Datei /etc/ssh/sshd_config die Zeile

AllowUsers

steht, muss man außerdem die Benutzer nx und den in die NX-Datenbank eingetragenen Nutzer eintragen, damit die Anmeldung möglich ist.

Maximale Anzahl an erlaubten Benutzern erreicht¶

Server: NoMachine NX Free Server

Fehlermeldung: Reached the maximum number of allowed users on this server.

Diese Fehlermeldung tritt beim Verbinden auf, wenn man als dritter Benutzer C versucht, sich auf dem Server anzumelden – obwohl bereits die Benutzer A und B auf dem Server bekannt sind. Dies bedeutet nicht, dass von Benutzer A oder B eine aktive Sitzung auf dem Server laufen muss! Die Lizenzbegrenzung gilt für Benutzer und nicht für aktive Sitzungen. Benötigen alle drei Benutzer Zugriff, muss man entweder einen gemeinsamen Account einrichten, eine Lizenz erwerben oder auf einen freien Server umsteigen (siehe oben).

Möchte man, das Benutzer C Zugriff bekommt und benötigt gleichzeitig Benutzer B keinen Zugriff mehr auf diesen Server, so muss man lediglich die Benutzer in NX anpassen. Dazu öffnet man auf dem Server ein Terminal ^[2]:

sudo /usr/NX/bin/nxserver --userdel <Benutzername B>
sudo /usr/NX/bin/nxserver --useradd <Benutzername C> 

Danach kann sich Benutzer C anmelden, jedoch Benutzer B nicht mehr.

NoMachine NX Client funktioniert nicht mit Xubuntu auf dem Server¶

Server: NoMachine NX Free Server
Client: NoMachine NX Client

Wenn man Xubuntu als Desktop auf dem Server nutzt, so muss man den NoMachine NX Client folgendermaßen konfigurieren: Im Tab "General" ist unter Desktop "Unix" zu wählen, aber dann "Custom" wählen und unter "Settings" bei "Run the following command:" folgendes eingeben: "startxfce4". Manchmal kann es nötig sein, unter Optionen "New virtual desktop" zu wählen. Danach sollte man auf den Server kommen.

Floating Window Modus funktioniert nicht¶

Server: NoMachine NX Free Server
Client: NoMachine NX Client

Der "Floating Window"-Modus – bei dem nicht ein kompletter entfernter Desktop, sondern nur ein entferntes Programm mit grafischer Oberfläche geöffnet wird – funktioniert bei manchen Programmen nicht richtig. Ursache ist, dass das Paket von NoMachine auf dem Server das Programm lsof unter /usr/sbin/lsof erwartet. Bei Ubuntu befindet es sich mittlerweile aber unter /usr/bin/lsof. Wo sich das Programm befindet, kann man mit dem Befehl:

which lsof 

ermitteln. Entsprechend muss in der Konfigurationsdatei /usr/NX/etc/node.cfg der Wert der Variable "CommandLsof" angepasst werden.

NX mit key-basierten SSH-Login¶

Server: NoMachine NX Free Server
Client: NoMachine NX Client

In der Datei /usr/NX/etc/server.cfg muss mit Root-Rechten folgende Zeile abgeändert oder ggf. eingefügt werden:

EnablePasswordDB = "1"

Anschließend ist der NX-Server neu zu starten:

sudo /usr/NX/bin/nxserver --restart 

Nun kann man einen NX-Benutzer hinzufügen:

sudo /usr/NX/bin/nxserver --useradd <username> 

wobei <username> durch den richtigen Benutzernamen zu ersetzen ist. Dann vergibt man für diesen NX-Benutzer noch ein NX-Passwort:

sudo /usr/NX/bin/nxserver --passwd <username> 

Auch hier ist <username> durch den richtigen Benutzername zu ersetzen. Sollte es sich um einen bereits existierenden System-Benutzer handeln, sollte unbedingt ein abweichendes Passwort vergeben werden. Sollte das NX-Passwort mal geknackt werden, dann kann der "ungebetene Besucher" zumindest nicht mit Root-Rechten via ""sudo"" arbeiten, da er hierfür das System-Passwort der NX-Benutzers kennen müßte.

Desktop eingefroren¶

Klickt man auf den "Beenden"-Button im Panel, dann friert oft die NX-Session ein und man kann nichts mehr machen. Auch das Beenden funktioniert nur noch durch gewaltsames Beenden des NX-Prozesses (unter Windows). Dazu es gibt zwei Lösungen:

1. Per SSH-Session (z.B. mit PuTTY) einloggen und den Dienst GDM neu starten:

   sudo /etc/init.d/gdm restart 

   Danach ist die NX Session wieder nutzbar.

2. Mit dem "NX Session Administrator" die Verbindung trennen und wieder neu verbinden.

Soundausgabe¶

Die Soundausgabe funktioniert nur dann, wenn das Programm ESD (Enlightenment Sound Daemon) verwendet wird. Bei einigen Programmen kann man das umstellen. Siehe auch den FAQ 🇬🇧 Eintrag von NoMachine.

Um den Remotesound an den lokalen Desktop weiterzuleiten, einfach folgende Zeilen in die ~/.bash_profile Datei einfügen:

if [ -n "$NXSESSIONID" ]; then
export PULSE_SERVER="your_desktop_ip"
fi

Konflikt mit ~/.ssh/config¶

Wenn diese Datei vorhanden ist, kommt es beim Einrichten von NX (z.B. mit nxserver) häufig zu einer Fehlermeldung, welche fehlerhafte Rechte der ~/.ssh/config bemängelt:

Bad owner or permissions on /home/<username>/.ssh/config

Es hilft jedoch nichts, die Berechtigungen der Datei zu verändern. Stattdessen sollte die Datei kurz umbenannt

mv ~/.ssh/config ~/.ssh/config_ 

und nach Durchführung der Einrichtung wieder zurückbenannt werden:

mv ~/.ssh/config_ ~/.ssh/config