[FreeNX-kNX] nxssh and nxproxy protocol
Fabian Franz
FabianFranz at gmx.de
Fri Feb 25 13:36:36 UTC 2005
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am Freitag, 25. Februar 2005 13:16 schrieb LROUFAIL at nc.rr.com:
> I have updated my notes on the protocol used by nxproxy and nxssh. See
> below. Please point out any errors.
>
> 1. Connect to the server using nxssh
>
> nxssh -nx -i /usr/NX/share/client.id_dsa.key nx@<host address>
Ok.
>
> If you are using encrypted session:
>
> nxssh -nx -i /usr/NX/share/client.id_dsa.key nx@<host address> -B
Ok.
>
> 3. NX> 105 is kind of like a shell prompt. Now you respond with the
> client version
Yes.
>
> type: hello NXCLIENT - Version 1.4.0
>
> You will get the following response:
>
> NX> 105 hello NXCLIENT - Version 1.4.0
> NX> 134 Accepted protocol: 1.4.0
> NX> 105
Yes.
>
> 4. I think the production client then sends the following:
>
> SET SHELL_MODE SHELL
>
> response:
> NX> 105 SET SHELL_MODE SHELL
> NX> 105
>
> SET AUTH_MODE PASSWORD
> NX> 105 SET AUTH_MODE PASSWORD
> NX> 105
Yes.
>
> 5. Then you send the login command
>
> type: login
>
> response:
> NX> 105 login
> NX> 101 User:
>
> type: <username>
>
> repsonse:
>
> NX> 102 Password:
>
> type: <your password>
>
> If you type <enter> instead, you will get the following from the commercial
> server (but not freenx)
Yes, because FreeNX is dependent on clear-text passwords, as almost no FreeNX
user will use the provided passdb backend. This would also lead to problems
as FreeNX does not yet have the password algorithm integrated.
>
> NX> 109 MD5 Password:
>
> type: <md5 of usernamepassword>
>
> You can get this password value by using the nxpassgen utility I have for
> moznx
I think sending cleartext passwords has some advantages, but thats just me.
>
> response:
> NX> 103 Welcome to: <host> user: <username>
> NX> 105
Ok.
>
> 6. Now you can request a session
>
> type: startsession --session="<session>" --type="unix-kde" --
> cache="8M" --images="32M" --
> cookie="6726ad07a80d73c69a74c5f341b52a68" --link="adsl" --
> render="1" --encryption="0" --backingstore="when_requested" --
> imagecompressionmethod="2" --geometry="1024x768+188+118" --
> keyboard="defkeymap" --kbtype="pc102/defkeymap" --media="0" --
> agent_server="" --agent_user="" --agent_password="" --
> screeninfo="1024x768x16+render"
>
> For encrypted session, send --encryption="1"
Yes.
>
> note: I have always had trouble getting this to work and have to use '&' as
> a delimeter instead of ' --'. It seems this issue is solved if you SET
> SHELL_MODE and SET AUTH_MODE as described above. I have not confirmed yet.
Yes, thats the case with !M NX. FreeNX however will always accept, whatever
you send it.
>
> response:
>
> NX> 105 startsession --session="<session>" --type="unix-kde" --
> cache="8M" --images="32M" --
> cookie="6726ad07a80d73c69a74c5f341b52a68" --link="adsl" --
> render="1" --encryption="0" --backingstore="when_requested" --
> imagecompressionmethod="2" --geometry="1024x768+188+118" --
> keyboard="defkeymap" --kbtype="pc102/defkeymap" --media="0" --
> agent_server="" --agent_user="" --agent_password="" --
> screeninfo="1024x768x16+render"
>
> you can also just type startsession<enter> then the response will be
>
> NX> 106 Parameters:
>
> Then you type all the parameters
Yes, delimited with &.
>
> You can replace startsession with restoresession if you want to restore an
> existing session. You add the additional attribute --id="<session id you
> want to restore>".
Yes.
>
> 7. Now the server sends back all of its parameters followed by a 105
>
> NX> 700 Session id: <hostname>-1058-CA3511103B37ADB2ABDAAF3EB510E99D
> NX> 705 Session display: 1058
> NX> 703 Session type: unix-kde
> NX> 701 Proxy cookie: A4BFD3EAE09B28A0EB0399A3EFD26392
> NX> 702 Proxy IP: 127.0.0.1
> NX> 706 Agent cookie: 6fff2cd4222776acd605d42fbb4bdfb5
> NX> 704 Session cache: unix-kde
> NX> 707 SSL tunneling: 0
> NX> 710 Session status: running
> NX> 105
>
> For encrypted sessions, NX> 707 SSL tunneling: 1
Yes.
>
> 8. Now in another session invoke nxproxy with the proper parameters on the
> command line and in the options file.
>
> nxproxy -S options=<path to options file>/options:<Session display>
>
> for example above: nxproxy -S
> options=/.nx/S-hostname-1058-CA3511103B37ADB2ABDAAF3EB510E99D/options:1058
>
> Then, in the options file:
>
> nx,session=<sesname>,cookie=A4BFD3EAE09B28A0EB0399A3EFD26392,root=/.nx,id=h
>ostname-1058-CA3511103B37ADB2ABDAAF3EB510E99D,listen=33057:1058
>
> listen=<port:display> is only needed for encrypted sessions. Also, all
> these parameters can be sent on the command line instead of the options
> file.
Yes, but this should not be done. Think of ps aux, where all users can see the
magic cookie, which actually is the magic cookie of the real Xserver.
>
> For the listen=<port:display>, I always just hardcode a port number. I am
> not sure where the commercial client gets the port number. I have asked
> but not gotten a response.
I don't know either.
>
> 9. Now back to our NXSSH session.
>
> type 'bye'
Yes.
>
> Response:
>
> 999> Bye
>
> 10. For encrypted sessions, now enter the switch command
>
> type: NX> 299 Switching connection to 127.0.0.1:33507 cookie:
> A4BFD3EAE09B28A0EB0399A3EFD26392
Exactly, that is a very nice explanation. Can I put this to the FreeNX
developer pages if someone wants to write yet another client?
cu
Fabian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFCHynmI0lSH7CXz7MRAu2PAJ978xNK/uW4BgTbq8n9vbqSsuJ0XwCeL6k/
Ky3ctsk9uV2BGSfo76oRsIc=
=vm7+
-----END PGP SIGNATURE-----
More information about the FreeNX-kNX
mailing list