[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