• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

NX ssh key management

vvvv

Newbie
... ein kurzer Beitrag zum Thema ssh und NX - hopefully useful...

Ich habe einige Zeit mit dem Aufsetzen von (zuerst FreeNX, und dann) NX verbracht, und ich mich mit der Authentifizierung auseinandergesetzt.
Ich habe den Mechanismus so verstanden:
NX (und wohl auch FreeNX) verwenden ssh[2?] zur Authentifizierung der Clients gegenüber dem Server.
Dies funktioniert im Prinzip wie bei ssh üblich, d.h., der Client besitzt einen Private-Key und übergibt seinen Public-Key an den Server.
Dieser trägt den Public-Key in seine authorized_keys2-Datei ein, und "alles wird gut".
Schönheitsfehler: Der Client-Private-Key wird im Standard-Szenario vom Server per
Code:
nxserver --keygen
erzeugt. Ergebnis sind die Dateien

  • /usr/NX/home/nx/.ssh/default.id_dsa.pub
    /usr/NX/share/keys/default.id_dsa.key
Zusätzlich wird die pub-Datei in die Datei

  • /usr/NX/home/nx/.ssh/authorized_keys2
kopiert. Damit ist dem Server, der unter der User-ID "nx" läuft, der Public-Key des Clients bekannt.
Gemäss Anleitung /1/ soll nun der Private-Key in das Verzeichnis

  • /usr/NX/share
des Clients kopiert werden. Lässt man nun z.Bsp. das Kommando
Code:
ssh-keygen -y
auf die Datei

  • /usr/NX/share/default.id_dsa.key
auf dem Client los, beschwert sich ssh bitter über den unzureichenden Schutz des Private-keys! Die Datei "muss" deshalb so "offen" sein, weil hierauf alle User des Clients zugreifen müssen, wenn sie erstmals eine Verbindung zum Server einrichten. Denn der Client benötigt ja "seinen" Private-Key, um sich zu identifizieren.

Also: Hier wird wohl "von hinten durch die Brust ins Auge geschossen" und diverse Beiträge werfen die Bedeutung der Schlüssel hinsichtlich des Servers oder Clients Private- bzw. Public-Key durcheinander.

Sauberer wäre wohl, für jeden User ein Schlüsselpaar zu erzeugen, und den Public-Key an die Datei authorized_keys2 anzuhängen, und den privaten Schlüssel nur im ssh-Verzeichnis des Users zu verwahren.
Alternativ sollte der Private-Key des Clients gut geschützt sein und vom Admin bei Bedarf an den User weitergegeben werden.

P.S: Ich bin auf diverse Erklärungen im Netz gestossen - zum Teil sehr tiefgreifend - habe aber keine Erklärung dieser Basics gefunden
P.P.S: Ich bin bei NX "gelandet", weil ich versucht habe, den Sound auf den Client zu bekommen. Nun hat es mit NX geklappt - warum auch immer...
P.P.P.S: Eine gute Erklärung für den Fall FreeNX und knx findet sich in /2/, eine tiefergehende Abhandlung in dieser Richtung ist /3/.

/1/ http://www.nomachine.com/documentation/admin-guide.php
/2/ http://www.mpipks-dresden.mpg.de/~mueller/docs/suse10.1/suselinux-manual_en/manual/sec.freenx.advanced.html
/3/ http://mail.kde.org/pipermail/freenx-knx/2005-July/001468.html
 
Oben