... 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
erzeugt. Ergebnis sind die Dateien
Gemäss Anleitung /1/ soll nun der Private-Key in das Verzeichnis
auf die Datei
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
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
/usr/NX/home/nx/.ssh/default.id_dsa.pub
/usr/NX/share/keys/default.id_dsa.key
/usr/NX/home/nx/.ssh/authorized_keys2
Gemäss Anleitung /1/ soll nun der Private-Key in das Verzeichnis
/usr/NX/share
Code:
ssh-keygen -y
/usr/NX/share/default.id_dsa.key
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