Tim Jansen's Blog (deutsch)


2003/07/14
NX


Nachdem ich die letzte Woche ein paar Stunden auf den NX Code gestarrt habe, habe ich mittlerweile einen ganz guten Plan davon, wie das System funktioniert. Auf dem NX Server muss sshd laufen und es wird ein spezieller User namens 'nx' angelegt. Dieser benutzt als Login-Shell eine Applikation namens nxserver, ueber den dann die endgueltige Authentifikation laeuft. Anders gesagt, der NX Client meldet sich mittels eines im Client mitgeliefertem Private Keys als nx beim Server an um an die nxserver Shell zu kommen. Dem sendet er dann erst den gewuenschten Usernamen inlusive Password. Nach dem Login wird auf dem Server ein modifizierter Xnest namens nxagent gestartet, der auf dem X-Server des Clients ein Fenster mit dem Desktop oeffnet. Die Kompression geschieht, indem auf Server und Client jeweils eine Instanz des nxproxy Tunnels laeuft, der die X11 Daten komprimiert. SSH wird nur fuer die Initialisierung benutzt, es wird (in der Regel) kein SSH Tunnel benutzt. Fuer diverse Optimierungen wird dabei eine modifizierte Xlib benutzt, die ein paar Erweiterungen fuer effizientere Kommunikation zwischen nxproxy und nxagent besitzt und zudem als DISPLAY 'nx' als Protokoll unterstuetzt (z.b. DISPLAY=hostname/nx,link=modem:1000).


Kurz gesagt, ich bin von der Server-Architektur nicht sonderlich begeistert (im Gegensatz zur Qualitaet der Kompression und Implementation des Proxy's). Die etwas laengere Version der Diskussion findet sich hier. Die Loesung ist verstaendlich angesichts dessen, dass das Ziel offenbar war, mit geringem Aufwand moeglichst viele Plattformen bedienen zu koennen. Der NoMachne-Fokus liegt stark auf groesseren Thin-Client Implementationen und Gast-Zugriffen. Mich dagegen interessiert es, dass Leute auf ihre Heim- und Arbeitsrechner zugreifen koennen und Administratoren Workstations fernadministrieren koennen. Daher ist mein vorrangiges Ziel, flexible Authentifizierungsmechanismen zu haben und vor allem maximale Sicherheit vor Angriffen aus dem Internet. Eine Loesung, die es jedem Angreifer erlaubt, sich auf dem Rechner per ssh einzologgen und in einer (speziellen) Shell herumzuhantieren, hat viel zu viel Potential fuer Sicherheitsluecken. Davon abgesehen waere eine freie Client-Implementation dieses Systems unbenutzbar, wenn ich nicht entweder noch den Server schreibe oder man halt den kommerziellen Server von NoMachine kauft.


Kurz gesagt, ich favorisiere erstmal eine andere Loesung. Ich werde wohl per Fish mich auf dem Server einloggen, dort ein Script installieren und dieses ausfuehren, wonach es sich um den Rest kuemmert. Das ist ein wenig wackelig (verschiedene Bourne Shell Varianten etc), aber einfach zu loesen und erhoeht nicht das Angriffsrisiko fuer den Server. Ausserdem funktionieren alle SSH Authentifizierungsmechanismen, und es geht auch auf Systemen ohne NX, solange Xnest vorhanden ist.




This page is powered by Blogger. Isn't yours? Creative Commons License
All text in this blog is licensed under a Creative Commons License.
(Images containing screenshots etc are excluded)