The Arrival of NX, Part 1

How I came to know NX.

This is the first in a seven-part series written by FreeNX Development Team member Kurt Pfeifle about his involvement with NX technology. Along the way, he gives some basic insight into the inner workings of NX and FreeNX while outlining its future roadmap. Much of what Kurt describes here can be reproduced and verified with one or two recent Knoppix CDs, version 3.6 or later. A working FreeNX Server setup and the NoMachine NX Client has been included in Knoppix now for over a year.

Figure 1. A remote KDE session viewed on a local Windows XP Professional desktop using the NX client for Windows. The NX server is installed on the remote Linux machine, konstruct@10.160.47.201, identified at the top left of the window frame.

NX is a new technology that allows one to run remote X11 sessions across slow or low-bandwidth network connections. User experience with NX is one of excellent responsiveness. Users with previous remote X11 session experience are stunned by NX's speed and its snappy application interaction. Moreover, NX also can connect to remote RDP and VNC sessions and offer big performance wins over TightVNC and rdesktop remote access. NX can do all of this from Linux, Mac OS X, Solaris and Windows workstations as well as from some types of PDA gadgets.

What Is Low Bandwidth?

Let's first get the yardstick defined. What do I mean by "slow link" or "narrow bandwidth"? People from some corners of the world think of a DSL link with a 384kb/sec connection as low-end connectivity. To them, slower links are not even worth considering. On my own horizon, low bandwidth means ISDN speed (64kbit/sec) down to even GXM modem speed (9.6kbit/sec or 9600bits/sec). A developer spoiled by fast links may not see a need to improve the performance of graphical applications running remotely. For him, X tends to be good enough. But not for me.

Plain vanilla remote X connections suck. I can't really work with them. I used to use them because there was no alternative. They still feel sluggish and unresponsive. Even across a 384kbit/sec DSL link, they are not much joy.

Is Citrix/Windows Fated to Be Faster than X11/UNIX for Remote GUI Displays?

Ever since I saw how well ICA performed across an ISDN line for the Microsoft/Citrix Metaframe Server access, I envied their users. I wanted the same speed and responsiveness for remote X. But every expert I talked to told me, "It's impossible. See, Keith Packard tried it once. He started to create a Low Bandwidth X (LBX) protocol, but even he gave up. Read his farewell document, "LBX Postmortem", and you'll see it is impossible!"

So, I read Keith's conclusive proof, dated January 2001, about this impossible dream. I admit that I didn't grasp all of the technical details of his arguments. I am not a developer; I can't read and understand C or C++ source code, and I am not an X11 expert. I have to trust some third-party expertise or my own user experience with a certain piece of software.

Keith based his conclusions on measurements of real-life applications and real-life networks. He was able to accept even unflattering results--his own baby, LBX, failed to live up to expectations, including his own. LBX would never work better than SSH with ZLIB-compression, he concluded; and SSH with ZLIB-compression already was at everybody's fingertips. So his final recommendation was simply to use something like:

ssh -X -C username@remotehost start-my-X-application.command.sh

where ssh creates the connection and gives you encryption and security, -C gives the best compression you can get and -X forwards X11 output to your local X display.

If someone of Keith Packard's stature says that X network performance can't be improved considerably without drastic changes in the internals of applications, there is no hope, right? At this point, I played nice and gave up asking.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

NX client works great on

Jeeva's picture

NX client works great on Windows, but i can not get it to work on a Mac OSX10 It needed X11 to be installed, but it still no luck. I tested ssh works to the remote server, i am trying to connect to. NX Authentication passes, but after that it prompts the login page again.

Accessing XP pro through RDP

Anonymous's picture

I'm intrigued by this comment from the article "Furthermore, NX also let me access a Windows XP Professional box or an MS Windows Terminal Server, which both use RDP" and would be interested if anyone can tell me how this is achieved

Thanks
Paul

I was told that RDP has to pa

Anonymous's picture

I was told that RDP has to pass through a FreeNX (linux) server.. and it (NoMachine Client) can't connect to a vanilla Windows Terminal server.

Differences?

Caleb's picture

So wait a second.. what is the difference between NoMachine's project and FreeNX ?

And which of them is still actively developed?

nomachine & freenx comparison

undefined's picture

the difference between nomachine & freenx is a matter of maturity, user-friendliness, & support; what some would consider a stereotypical closed vs open source comparison.

but uniquely, both are based on nomachine's GPLed nx protocol libraries (and as such should be totally interoperable).

to answer your question: both are being actively developed.

nomachine is the closed-source nx client/server; the client is free, the server is not. freenx is the open-source free-software nx server (with a kde client in the works).

nomachine's implementation/installation is more mature & polished as nomachine has more man-hours invested in their product than freenx. commercial products are expected to "just work". free software users are gluttons for punishment. ;-)

nomachine offers support with the purchase of their product. freenx support is volunteer based.

those are the obvious differences.

it is sometimes confusing because the nomachine client is often discussed with the freenx server, because until recently nomachine's client was the only client available.

NoMachine's nxclient

Anonymous's picture

Is this 'free beer' or 'free software'. Based on an old version of the Cygwin/X code from Xfree86, no recent bug fixes from Xorg have been incorporated in the nxclient code or any given back to the community (I've not found any!). Source code is available, but I can't found CVS (or equivalent traceable access). Two years old at least this crutial component to NoMachine's software suite (the MS Windows bit that everyone wants!) doesn't look too fresh or original.
I would go for Cygwin/X or Xming on MS Windows and use the X Window server out of the box from Xorg on Linux.
I am the current maintainer of Xming, which is available GNU GPL from SourceForge. Current version is built from X11R6.9 Xorg using MinGW.

Colin Harrison

NX Documentation

Nick's picture

If the blurb is to be believed then this is a truly useful product. I have tried to get both the commercial demo and FreeNX versions to work but to no avail and I believe most of the issues lies in the documentation. There seems to be some around but it's so spread out on the NoMachine site it's difficult to find what you're looking for. For example I cannot find a definitive answer to whether my firewall needs to open up more than the SSH port of 22.

Firewall needs only to open up for port 22

Kurt W. Pfeifle's picture

"I cannot find a definitive answer to whether my firewall needs to open up more than the SSH port of 22."
-----
If you make sure that the "Enable SSL encryption for all traffic" in your NX Client Configuration is checked for each connection, then NX will use this port as the only one.

Oh, and (Free)NX does not run a daemon of its own -- it is all handled through your NX server system's SSH, so make sure that sshd is running. If you can access a (Linux) box via SSH, then you can also access it via NX (provided it has a GUI installed).

Oh, and BTW, on the NoMachine website it is described here:

  • http://www.nomachine.com/ar/view.php?ar_id=AR12B00115
  • .
    Or try this link:

  • NoMachine Knowledge Base Search

    .
    Cheers,
    Kurt

  • Port problems

    John Paul Alcala's picture

    First off, I'm no expert in Linux. I just would like to share something interesting I just found out a few hours ago regarding NX Client's usage of ports (or most probably NX Server's).

    For the past 2 weeks, I've been trying to find out how to connect to an NX Server using only 1 port. And basically, the solution to that is to simply "Enable SSL encryption for all traffic". However, for some reason this does not apply to some users, including me. I've been searching for answers for the past 2 weeks, but to no avail. Thus, I was forced to open other ports on my server just to allow incoming connections. I administer my server via Webmin.

    A few hours ago, I had a thought of disabling Webmin's usage of SSL, so it can run under HTTP port 10000(our office blocked all access to all ports except port 80. I can use brute force to punch a hole in the firewall so I can still connect to port 10000, but still, the firewall blocks usage of port 443). After which, I forced my SSH server to use port 80. I tried running NX Client again with SSL enabled for all traffic, and voila! NX Client uses port 80 only!

    btw, I was monitoring the port usage via netstat of windows.

    So, for those users having problems with this feature, take a look at any SSL-related daemons running and shut them down.

    For Fedora users...

    Al G.'s picture

    Here's a great howto and rpms from Rick Stout:

    http://fedoranews.org/contributors/rick_stout/freenx/

    I've been using it since fc2 or so (IIRC) - it's excellent, and the speed is impressive.

    It does use a client key file for each server - since I want to be able to connect to multiple servers from a single client w/o modifying their randomly generated keys - there's a crude little bash script that provides a workaround for that here:

    http://www.mantic.org/wiki/Freenx_tips

    Simple is Best

    goaty's picture

    I use NX daily. I think the underlying protocol technology is good. Unfortunately, instead of the tried-and-tested ssh authentication system they use a DIY authentication scheme. Not only does this rule out the use of NX for enterprises using challenge-response authentication, etc., but the way they've bypassed ssh security is by shipping a fixed private key with every client! To avoid letting the entire planet authenticate as "nx" on my machines, I have to manually change the key for every install.

    The best comment I saw on NX was when someone pointed out it should really just be a commandline option to ssh. In other words, where you'd do

    ssh -X machine xterm

    you do

    ssh -X --nx machine xterm

    and you get the full NX protocol goodness without compromising your security.

    Unfortunately, since that would pretty much kill NoMachine's business model, I don't think it will ever happen.

    an example (but not exemplary) response

    undefined's picture

    they say people should lead by example, and i've said plenty in previous responses to this post, but let me put my words in action:

    yes, you are correct in that distributing and using a known ssh client key pair is probably not exactly how tatu envisioned ssh passwordless public-private key authentication be used.

    you see, nx simply uses ssh to create a server-authentic, encrypted tunnel, and nx's non-standard use of ssh still accomplishes this. this alleviates nx from reimplementing the wheel (and all the detriments that brings) by using ssh to create a secure tunnel for nx client-server communications.

    but as the default key pair is known by everybody, the ssh protocol cannot meaningfully use client authentication (ie the ssh server cannot authenticate the ssh client). this does allow anybody to connect to a default installation of nx server and have access to the nx shell.

    the nx server tries to mitigate this risk by greatly limiting the nx shell until a user authenticates (using a name & password) with it. the nx shell has been audited by a novell-suse team to insure the user is safely restricted until after authentication. the nx server's use of ssh insures the user's name & password is sent encrypted to the authenticated server.

    anybody installing freenx and concerned about the use of a known client key pair (as it does deviate from the standard use of client key pairs in ssh) is encouraged to generate a new key pair and integrate it into their client installations. an installation-specific key pair will help insure that only intended users of nx can try to authenticate themselves to the nx server (much like how tcpd, hosts.allow, and hosts.deny restricts which clients can connect to services, for those familiar with tcpwrappers).

    a majority of the users are satisfied with the level of security & ease of use the default installation provides with freenx & the nomachine client. feel free to build upon the default security by creating a client key pair unique to your installation as that option is available and only requires a little work on your part (feel free to contact the mailing list if you need more details).

    On NX Authentication and Security

    Kurt W. Pfeifle's picture

    "I use NX daily. I think the underlying protocol technology is good."
    -----
    Mr./Mrs. goaty,

    thank you for your comment, and for your acknowledgement of at least some of NX's benefits. Unfortunately, the remainder of your talkback is .... (let's call it politely) rather "uninformed".

    I'll take it as an opportunity -- it gives me the chance to set the record straight concerning some popular, but wrong assumptions spread by postings such as yours.

    -

    "Unfortunately, instead of the tried-and-tested ssh authentication system they use a DIY authentication scheme."
    -----
    The NX authentication scheme is not a "Do It Yourself" one. As a matter of fact, it is a two-stage authentication, where each stage is based on a different tried-and-tested, trusted scheme: the first one is SSH; the second one is SSL.

    The first stage uses SSH public key authentication. In the first stage the NX client creates an encrypted tunnel to the NX server as the special user "nx". This this pubkey authentication doesn't give any normal shell access to "nx", but it yields a second, prompt that is good for only two things:

    • letting take place the real user's authenticaton (password based, SSL challenge-response).
    • and after that authentication starting up the real NX session.

    The nx user sees the "special" NX login prompt, looking like this:

    NX> 105

    You can try if you can break into your own system, by running a command like this one:

    Danka:~> ssh -i /usr/NX/share/client.id_dsa.key nx@localhost
    HELLO NXSERVER - Version 1.5.0-05 OS (GPL)
    NX> 105

    and then play around with that prompt. See how far you get. To make it even more easy for you, have a look at the documentation as provided here:

    Basically, this prompt represents a very limited special shell, useful only for SSL challenge-response authentication as the real user "goaty". You have to know the username and the password to really get into the system. NX runs some processes (nxagent, nxnode) as the user "nx". The user "nx" does not have access to any "nx" can not even used for portforwarding, or to execute any other command but "nxserver".

    I would compare this to a HTTPS server: like NX, the HTTPS service is run by a special user (instead of "nx", in this case that user is often named "wwwrun"). The situation where the pubkey authenticated user "nx" sees the NX login prompt may be compared to a HTTPS server access: it also shows you a login dialog -- but your browser has not even used a pubkey SSH authentication to get as far as to the login prompt.

    -

    "the way they've bypassed ssh security is by shipping a fixed private key with every client!"
    -----
    NX does not bypass ssh security. The shipped key has a purpose: to make it secure to run NX sessions, and to make it easy at the same time. The design of the NX authentication as a two-stage affair has a purpose too: to not restrict NX to mere peer-to-peer situations, but to also be able and construct clustered, load-balanced environments of NX servers and services.

    The shipped fixed key is meant to make it possible to provide "public" NX servers. This still means that you in addition have to assign a username and a password to each user whom you want to enable to run an NX session on your NX server. Users logging in with their password credentials can be sure that their password isn't transferred over the net in clear text:

    • first, it is going through the encrpyted tunnel already created by the "nx" logging in via pub-key authentication (using either the "NoMachine" key, or the custom key you created).
    • second, it is using the SSL challenge response mechanism to do that password authentication, which makes sure that the actual password is not transferred over the wire, not even in encrypted form.

    This is a secure way to run NX.

    You can increase the security provided by default even more: by not using the NoMachine-provideed key to authenticate the "nx" user, but to create a custom key-pair. But there is a price for that increased security you surely are aware of: you need to distribute the client part of the keypair to each of your remote users in a secure way first, and these must make sure to install it correctly.

    BTW, the 1.5.0 NX Client by NoMachine now has a builtin convenience function to handle different keys for the users. So, if a user regularly accesses different NX servers with different "nx" user keys, these can be saved with the session setup configuration file.

    -

    "To avoid letting the entire planet authenticate as "nx" on my machines, I have to manually change the key for every install."
    -----
    Mr./Mrs. goaty,

    you shouldn't pose to the world as if you had "managed" to invent a new way to make NX more secure, when it is actually published on the NoMachine website (as part of their excellent, very large Knowledge Base):

    -

    "Not only does this rule out the use of NX for enterprises using challenge-response authentication (...)"
    -----
    As you have noticed by now, you are wrong with your assumption that challenge-response authentication is "bypassed" by NX. And do you believe that he SUSE Linux Security Team (who made an extensive code audit of the FreeNX code a year ago) would not have noticed a flaw like that, which you attempt to now tell to the world here?

    And as for the "use of NX for enterprises is ruled out".... you better tell this to the many enterprises that already use NX to date.

    -

    "someone pointed out it should really just be a commandline option to ssh. In other words, where you'd do (....) ssh -X --nx machine xterm and you get the full NX protocol goodness without compromising your security.
    -----
    That "someone" very likely was me... And again, NX doesn't compromise your security.

    And you can have that already. Look at the nxtunnel scripts by Neal Walfield or at nxshell by Marcus Schaefer from SUSE/Novell. You can find them here:

    -

    "Unfortunately, since that would pretty much kill NoMachine's business model, I don't think it will ever happen."
    -----
    Wrong again.

    Firstly, it *did* happen already. Second, it doesn't kill NoMachine's business model -- because otherwise they wouldn't have released their NX compression algorithm code under the GPL in the first place, wouldn't they?

    Cheers, and have a nice day!
    Kurt Pfeifle (FreeNX Developer Team)

    I love you. Very detailed

    Anonymous's picture

    I love you.

    Very detailed answer. I'm a believer.

    nx protocol security analysis

    undefined's picture

    * first, it is going through the encrpyted tunnel already created by the "nx" logging in via pub-key authentication (using either the "NoMachine" key, or the custom key you created).

    please do recognize that using the "NoMachine" key does effectively eliminate client authentication from the protocol, meaning that any client can connect to the server. not a big deal by itself, but in concert with a man-in-the-middle attack, can allow for some remote exploitation.

    my curiousity in studying the nx protocol (or maybe this aspect pertains to freenx's particular implementation) is how nxssh handles connecting to a host with:

    • an unknown host key
    • an incorrect host key

    mitm attacks can be recognized and avoided if the ssh server can be authenticated, based on public key fingerprints (communicated out-of-band or remembered from previous sessions).

    i know how openssh handles such situations (which nxssh might be a wrapper for or based on), but i was curious how nxssh (and possibly other implementations) handle such without digging into the source code.

    * second, it is using the SSL challenge response mechanism to do that password authentication, which makes sure that the actual password is not transferred over the wire, not even in encrypted form.

    does freenx now implement md5 passwords?

    the moznx nx protocol documentation you earlier quoted and this related email thread state that as of last feb 25, freenx sent user passwords in clear-text. actually, the moznx website still hints at such ("Clear passwords (required for FreeNX, compatible with Nomachine server)").

    and md5 by itself does not constitute a challenge-response system. in the example moznx client-server transcript, i see no challenge ever issued (even in the case of a md5 password).

    for example, what are the inputs to nxpassgen (which should be the inputs to the md5 algorithm)? unless there is some one-time input to the algorithm (session key, time-date stamp issued by server, etc), then the md5 password will always be the same and susceptible to replay & dictionary (precomputed md5 hash) attacks.

    and you make reference to "SSL" but i don't see it. the only use of SSL i see is in (optionally) tunneling the nx session (as commanded by the "startsession" or "resumesession" protocol commands), but that only appears to occur after authentication (according to moznx transcript).

    to put it all together: i stage a ssh man-in-the-middle attack (most likely using a zombied machine on the client's or server's side of the network; doubtfully somewhere in the middle on the internet), capture the user's name & clear-text/md5 password (those prompts/strings are easy enough to be pulled out with a script), and now i can connect to the nx server as the user. the best part of a mitm attack, is that it's somewhat user dependent: when nxssh alerts the user to the changed server fingerprint (assuming nxssh does so and the server's fingerprint is known before hand), will the user blindly proceed with the connection or not?

    of course, all of this doesn't negate security, as security is really nothing more than deterents and not guarantees, and there are still deterents even with a known ssh private key and clear text passwords. but i don't see the strength of your claims (use of ssh, ssl challenge-response authentication) being supported, though i admit i don't know everything about nx and may have overlooked something in what little i have read.

    NX Security

    Lawrence Roufail's picture

    I hate to see my documentation used as a case against NX security (especially when it is misinterpreted).

    The short response to this is that none of the FUD you mention has anything to do with FreeNX security.

    It is true that the user password for the session is passed in clear text - within an encrypted SSH session. For the commercial client an md5 hash is used, but the inputs are just userid and password.

    NXSSH does challenge the client program if the authenticity of the server is nt known. My client happens to gobble up the message but the nomachine client presents it to the user. It will also fail if the fingerprint of the server changes. So how do you do man-in-the-middle?

    As far as the nomachine keys presenting a security threat - this criticism has been around for a while. While I don't see the issue, FreeNX, the nomachine clients, and my clients all support alternate keys in one form or another. Is it convenient - no. But it works for those that need the additional assurance.

    Finally - Where is your proof? Have you done the proof-of-concept, or is this theory. All the tools are available. I would be interested in your results.

    where's the openness in open source?

    undefined's picture

    "I hate to see my documentation used as a case against NX security (especially when it is misinterpreted)."

    my apologies if i misinterpreted your documentation. please point out my misinterpretations and i will correct myself.

    "The short response to this is that none of the FUD you mention has anything to do with FreeNX security."

    my apologies if anything i said was incorrect or dishonest (in general or specific to freenx's security). again, please specify the points i presented that you feel are wrong and mean-spirited and i will correct myself.

    "It is true that the user password for the session is passed in clear text - within an encrypted SSH session."

    this is contrary to what kurt stated in response to goaty, which i previously quoted but will quote again:

    "second, it is using the SSL challenge response mechanism to do that password authentication, which makes sure that the actual password is not transferred over the wire, not even in encrypted form"

    for freenx, what kurt states is explicitly wrong as the actual password is transferred in clear text within the ssh session. and for the official nx client/server the situation is not much better as the md5 password never changes (consisting entirely of username + password) and is vulnerable to replay attacks the same as a clear text password, so the benefit of md5 is dubious.

    and most assuredly there is no "SSL challenge response mechanism" as kurt claims, not even in the case of the official nx client/server. so why did he make such claims? is he not familiar with the nx protocol? i would be willing to discount it as a simple mistake, but he bases his entire argument on the point:

    • "As a matter of fact, it is a two-stage authentication, where each stage is based on a different tried-and-tested, trusted scheme: the first one is SSH; the second one is SSL."
    • "letting take place the real user's authenticaton (password based, SSL challenge-response)"
    • "Basically, this prompt represents a very limited special shell, useful only for SSL challenge-response authentication"
    • "second, it is using the SSL challenge response mechanism to do that password authentication"

    "So how do you do man-in-the-middle?"

    oh, i concede that the ssh man-in-the-middle attack is technically the weak link in my concept. but i am at least objective in saying that a man-in-the-middle attack is possible and realistic (as ssh is popular/widespread, tools have been created for mitm attacks) and preys on the human error of non-technical users (or are only geeks going to use nx).

    upon the first connection to a server, does freenx (or moznx, or the official client, etc) present the ssh server's finger print for the user and encourage him to verify it through out-of-band communications (phone call or email to server admin or tech support)? if on a follow-up connection the server's public certificate doesn't match the one on file, does the client issue a warning and allow the user to continue or present a highly-technical and difficult-to-understand error message (which the user might not understand and leave him attempting to work around the perceived "client failure").

    "As far as the nomachine keys presenting a security threat... I don't see the issue"

    please do see the issue. only when we recognize, study, & understand a problem can we help ourselves (authors) & others (server admins and end-users) deal with the problem.

    do you agree that using precomputed ssh client key pairs allows anybody to connect to the nx server? that's the problem. is it a big problem? not by itself. but using an installation-specific ssh-client key-pair would greatly mitigate a prior mitm attack because even though the attacker might have a user's name & password, he would be unable to initiate a new nx session of his own with which to use the user's name & password. i haven't studied the nx protocol in depth, but i presume starting a new nx session is much easier than hijacking a nx session during a mitm attack. as a system administrator i can technically limit the effects of a mitm attack by using installation-specific keys, because it's difficult to control the human aspect of a mitm attack. (how many non-technical users still click "yes" when their browser warns them about an invalid ssl certificate and asks if they still want to continue. even if the browser didn't allow a user to continue, how many users would fail to grasp the gravity & implications of the situation and try another browser/computer in an attempt to work around the "problem"?)

    "Finally - Where is your proof? Have you done the proof-of-concept, or is this theory."

    proof of what? the fact that nx distribute precomputed ssh client key pairs? you acknowledge that. the fact that precomputed ssh client key pairs allows anybody to connect to the server? kurt acknowledges that. the fact that "ssl challenge response authentication" doesn't exist? your nx protocol transcript proves that. the fact that using the md5 of the user name & password is no better than issuing the password in clear text? that should be intuitively obvious as once i have learned the md5 i can submit that to the server the same as the password. the fact that a man-in-the-middle attack is possible? take your pick of proof texts. but automating my previously described attack is left as an exercise to the reader if they are unable to mentally piece together the above proven concepts.

    what concerns me the most and prompted me to write this series of responses is that authors of free software are ignoring, glossing over, and/or covering up the security of their software instead of being frank and honest. i expect this behavior of closed-source commercial vendors who have a monetary stake in keeping potential customers unaware of perceived short-comings in their software, but not free software authors who cannot keeping anything hidden as the source is open.

    notice i said "perceived short-comings" because security is not absolute and comes in varying degrees. is it a short-coming that though i have a lock on my car door, a thief could break a window and steal valuables from within the car? that's okay. i accept it, acknowledge it, and mitigate it by removing or hiding the valuables in my car. so freenx distributes precomputed ssh client key pairs; accept it, acknowledge it, and help users mitigate it (create a script or wizard to allow easy generation and importation of new key pairs or simply let users know the additional security provided with installation-specific key pairs). but don't ignore it, pretend it doesn't have any possible consequences, and/or make up features that supposedly negate it. don't have the time or desire to make your software mitigate possible risks? that's fine, i understand, i don't expect my car manufacturer to equip my vehicle with bullet-proof glass to physically deter theft. but neither does he claim that even should a thief break a car window that the security alarm will sound, interfere with his nervous system, and paralyze him on the ground. instead he recommends that i lock values in the glove compartment or simply store out of sight. that's all i expected in kurt's response to goaty or any response to me.

    security is about risk mitigation, but software authors can only mitigate what they accept, and users can only mitigate what has been acknowledged. so let's stop being defensive, correct the misinformation, promote security analyses, and decide what security we want to improve programmatically or advertise for the user to handle.

    (ps i find it sadly humorous that in every response to my initial comment, no one has addressed the fact that the author of a nx protocol server implementation was grossly incorrect about its authentication mechanism. don't get me wrong, i respect kurt for the time & dedication he has shown in freenx, and in this series of articles alone, but is everybody too lazy to research the protocol and see this error for themselves or are the authors of high profile free software projects so exalted as to be beyond reproach?)

    so freenx distributes precomp

    Lawrence Roufail's picture

    so freenx distributes precomputed ssh client key pairs; accept it, acknowledge it, and help users mitigate it (create a script or wizard to allow easy generation and importation of new key pairs or simply let users know the additional security provided with installation-specific key pairs).

    Have you ever even installed FreeNX? This is exactly what it does! You have to use a non-default command line extension to use the default nomachine keys and there is a utility that makes it simple to generate unique keys.

    What else would you have them do?

    This is an example of the FUD I was taling about. If you use the default installation with unique keys, then how would you get access to the server? How would you extract the userid/password from an encrypted session?

    Unless you actually take the time to use the software, how do you verify your assumptions?

    We may seem defensive, but that is because we are constantly chasing these windmills. We don't have the option of just writing about these things - we have to implement them in software which takes a lot of time with no compensation. We provide a service and are undermined by people who don't even take the time to install the software much less provide a functioning test case for a true vulnerability.

    my assumption, my apology

    undefined's picture

    i apologize for assuming that freenx installs with the default nomachine key. this was based on my previous research into freenx and the original poster's comment.

    i researched freenx about a year ago (shortly after kurt announced the project) and again ~6 months ago (when highlighted in knoppix). i reviewed the project's documentation and looked into installing it on debian, but never found any simplistic howtos, guides, or even recountings (using google). for the few times i've needed remote desktop access, vnc was sufficient for my needs (easy to install, straightforward concept, and performs well enough), so i passed on the possibly difficult freenx installation.

    i withdraw my concern about freenx using publically-known ssh key-pairs, as that is not the case. everything i've said still applies should users decide to use the distributed key-pair, but the users' decision is not the fault of the freenx developers.

    i still contend with the glaring error concerning nx authentication (which i've noticed no one has addressed), but i've said enough.

    Re: my assumption, my apology

    Gian Filippo Pinzari's picture

    > i still contend with the glaring error concerning nx authentication
    >(which i've noticed no one has addressed), but i've said enough.

    I think other posters have extensively addressed your concerns. They might have missed to explain some of the inner SSH technical details, but this is because SSH is a complex software. If you still can't find your answers, I think it's because you probably miss the difference between SSH authentication, SSH session encryption, host authentication and SSH session integrity. They are different problems and SSH provides a diffent answers to any of them. You end up putting everything in a big pot, and this doesn't help the discussion.

    What NX does is to handle authentication at the application level. The fact SSH -can- also handle authentication doesn't mean it -has- to. In our case the server accepting the connection needs to decide what to do -before- the user would get a system shell. There is no difference compared to the way a HTTPS server works in combination with any Web application. Still, I've never heard the argument that HTTPS is insecure as all users can easily get a shell running as the Apache users by just connecting to the right port.

    As others have written, if you can get the NX password while it is traveling over the Internet (being it the MD5 or the clear text), you have broken into the SSH session. If you can do that, having a private key-pair would not save your ass.

    About the poster noting that the use NX does of SSH can be out of the scope initially envisioned by Tatu Ylonen, I have to say that I'm not 100% sure of that. SSH provides the ability to tie a key-pair to a restricted shell, and that is what NX uses.

    Rest assured that if you want to stay on the mainline and keep using SSH the only way you -suppose- it -must- work, you are free to do that. Before arguing about the security of a system, anyway, you should at least provide some documentation, proof of concept and, possibly, an actual exploit. I suggest you get a good book on SSH/SSL and go deeper into the concepts. This can be a good starting point:

    http://www.hn.edu.cn/book/NetWork/NetworkingBookshelf_2ndEd/ssh/index.htm

    /Gian Filippo.

    i know how openssh handles su

    mabinogi's picture

    i know how openssh handles such situations (which nxssh might be a wrapper for or based on), but i was curious how nxssh (and possibly other implementations) handle such without digging into the source code.

    As it uses SSH, it also benefits from SSH's MITM protection. Try it yourself - the first time you connect to a server, you should get a warning that the host is unknown. If you regenerate the host key for that server and try to connect again it will warn you that the host identification has changed and that it may indicate that someone has attempted to hijack the connection.

    > to put it all together: i s

    mangoo's picture

    > to put it all together: i stage a ssh man-in-the-middle attack (most
    > likely using a zombied machine on the client's or server's side of the
    > network; doubtfully somewhere in the middle on the internet), capture
    > the user's name & clear-text/md5 password (those prompts/strings are
    > easy enough to be pulled out with a script), and now i can connect to
    > the nx server as the user.

    If you manage to capture the username and password using the midm attack, congratulations - you just managed to crack the whole SSH session (within which all NX data is transmitted during "negotiation"; and later if you use SSL tunneling).

    ssh mitm attack

    Gotti's picture

    I use NX and I think it is relative secure. The mentioned thing about the same public/private key pair on each host, is not so trivial as it seems. SSH should protect for mitm attacks, but not if the session is started the first time. Then you accept the host key which is presented there. Or did you know all host keys?? If then the attacker can catch an userid with the md5 hash of the password. Then he can also log in as the user he had catched the password from. I mean this is not really impossible to do this, in an smaller network. If the network is bigger you become problems with catching such a session. I will try this with a friend of me, in the net of my FH. I want to know if it's really doable by someone. I will try it a little more simpler. I will try to simulate the real Server, but will give the client an error message, after he had sent his userid and md5 password. Because the SSH encryption is secured only by the known public/private key it should be possible. (Only if I be the Server the host is connected to, because the SSH2 session is protected with an random Session Key. Or something like that)
    With the userid and the md5 hash it should be no problem, for someone who know the underlying protocol, not for me, to get access to the server. That wouldn't be so simple, as I've mentioned, but it is a real possibility.
    I think the writer which criticized the security issues was not completely wrong. I think he wants only to mention, that there is an issue, over which we should think about. I think an integrated GUI for generating a new pair of keys in the client as example, would be a solution for him. This makes it for not so keen users simpler to generate and use new keys. (Not everyone knows how to use the command line). Another possibility is the use of MD5-Challenge, then are the MD5 passwords not static, and not the same on each session. If such a Procedure is already used, then is a attack nearly impossible.

    Gotti

    PS: Sorry for the awful english, but I'm not a native.

    nxserver

    Alex's picture

    I don't think that this is a good, at least now, package. I tryied to start is about 10 minutes on redhat 4 as and it failed. I have no more time to try it. It failed in both cases(/etc/init.d/nxserver start and /etc/init.d/nxserver stop) with errors already running or already stopped.
    Another issue where package is installed - /usr/NX/...? Does developers knows something about standards?

    Commercial server?

    Fabianx's picture

    Hi,

    it seems like you were trying to run the commercial server.

    If you read the shipped README-server it explains that you should run nxsetup before using the service and then just connect from a client.

    And yes its very easy to setup, still even easier then FreeNX. I have to admit that.

    cu

    Fabian

    /usr/NX/(...) installation path

    Kurt W. Pfeifle's picture

    "I tryied to start is about 10 minutes on redhat 4 as and it failed."
    -------
    I am sure you had in the past also many newcomer packages which were not yet bundled by the OS vendors and you couldnt get them to work within 10 minutes. :-)

    "I have no more time to try it."
    -------
    That is a pity. I can not even attempt to help you then.

    "Another issue where package is installed - /usr/NX/...? Does developers knows something about standards?"
    -------
    The binaries compiled directly from GPL sources by NoMachine are indeed intended to go into /usr/NX/.

    This is modelled after the traditional example of /usr/X11/(...).

    And this has also advantages: because you can relatively easily delete the package too.

    Regarding standards: if you are offering a software not just for Linux, but also for other Unix-like platforms, you need to look after many "standards". I can understand that NoMachine wanted to focus on making the software work well rather than meeting dozens of packaging standards of various OSes.

    The Linux packagers packaging FreeNX for the different distributions are going to go as close to your desired "standard" as they can.

    have no time

    Alex's picture

    Ok, my previous email was a little sharp. But... If package cost money, I'm expecting at least easy installation in quick starting. It was not happaned. Will try later and now I wish success to NX developers.

    We installed nxserver on RHES

    Mike's picture

    We installed nxserver on RHES4 in ~15 minutes without any problem.

    Perhaps the 5 minutes we took to read the documentation have made the difference, or perhaps you encounters a problem between the chair and the keyboard.

    I suppose you didn't test Metaframe or TSE for talking about quick starting :)

    M

    NX Server

    Binoj's picture

    I have the same problem. Server doesn't start. I downloaded the rpms for fedora 4 and for a week I am seraching the site for a documentation to troubleshoot it. There is no documents which I could find to solve the problem. The standard document describes installation procedure and to start the server and that's all. No troubleshooting help. I will hold on to it till some good form of support emerges.

    NX Install

    Khurt Williams's picture

    I installed the client and server from RPMS. After extracting the key file I installed the Windows client and connected to my remote host with no problem. You do NOT need to execute the init script in /etc/init.d to use the software. The software will use the existing SSH deamon.

    On windows NX gets often stuck

    Anonymous's picture

    NX is really great, I'm using it right now. I use the nomachine
    nxclient from a linux machine it never let's me down. I can
    always login a windows system (through a vnc tunnel). However,
    someone else, who is using nxclient from windows, is often not
    able to login to the windows machine. This happens often, other
    times he can just login. Is such a unreliable behaviour reported
    before by MS users (with regards to NX)? Or does this seem to be
    a special case??

    I'm haviing the same problem

    Anonymous's picture

    I'm haviing the same problem with a windows client connecting to Linux. somtimes ii just 'freezes'

    NX connection to VNC session

    pfortier's picture

    > Moreover, NX also can connect to remote RDP and VNC sessions and offer
    > big performance wins over TightVNC and rdesktop remote access.

    I installed NoMachine NX client, but was unable to use it to connect my TightVNC server (n.b. I can connect using TightVNC client to connect to server = myserver.home.ca:1 and password = ******).

    How does one use NX to connect to a VNC session?

    Connect from NX Client to VNC Server

    Kurt W. Pfeifle's picture

    You can not use an NX Client on its own to connect to a VNC server.

    The NX *client needs an NX server. It always connects to the NX server. That NX server then can act as a proxy on behalf of the NX client and on request forward the connection to a VNC server (this could be one running on the same host as the NX server, or another machine altogether).

    The NX Client always talks "NX protocol" to the NX server. The NX protocol is compressed and roundtrip-free (almost). The NX server, proxying to the VNC (or even Windows Terminal) server speaks "RFB" or "RDP", and translates that traffic to become NX when talking back to the NX Client. Despite of what looks like incredible "overhead", this is still faster and more efficient for most conditions.

    Here is a schematic drawing:

      Workstation with NXclient <-----(NXprotocol)----> NXserver <----(RFBprotocol)-----> VNCserver
                                |..."long" distance...|          |..."short" distance...|

    Compare this to the direct access:

      Workstation with VNCviewer <----------------------(RFBprotocol)-------------------> VNCserver
                                 |............."long" distance, direct access...........|

    You may find that the NX-proxied VNC connection may even be beneficial for short distances, although its superiority really shines over the longer distant and smaller bandwidth links.

    You can find a step by step howto for the connection setup on the NoMachine website

    The upcoming parts of the series will elaborate on that topic a bit more.

    step by step howto

    Kurt W. Pfeifle's picture

    You can find a step by step howto for the connection setup on the NoMachine website

    ----------

    Sorry, forgot the link: http://www.nomachine.com/howto/vnc-session.php

    Heya, I'm not sure, but ma

    Anonymous's picture

    Heya,

    I'm not sure, but maybe you need to setup an NX-proxy-first:

    unneling that VNC connection through an NX proxy link, I experienced a speed increase at least two-fold over a plain vanilla TightVNC link.

    greetings,

    Michel

    Re: Heya, I'm not sure, but

    pfortier's picture

    > I'm not sure, but maybe you need to setup an NX-proxy-first:
    > tunneling that VNC connection through an NX proxy link, I
    > experienced a speed increase at least two-fold over a plain vanilla
    > TightVNC link.

    How do you setup an NX-proxy and tunnel the VNC connection through it?

    BTW, I regularly use a RealVNC client on a highspeed link to connect to my VNC server. I compared its speed to the NoMachine NX testdrive server and found that it wasn't faster but actually slower. Since all the reports I heard said NX was faster, I concluded that the NoMachine testdrive server was too busy and not a fair comparison to my VNC server.

    When I saw the statement "Moreover, NX also can connect to remote RDP and VNC sessions and offer big performance wins over TightVNC and rdesktop remote access.", I thought it meant that one could use an NX client to connect to a vnc server session instead of a vnc client and get performance gains.

    Pierre

    Way Cool

    Peter Yellman's picture

    Waayy cool! I'm really looking forward to the rest of the series. I expect this series will be what finally gets me to kick the tires on FreeNX. Thanks Kurt, LJ.

    Peter Yellman

    You Guys are Awesome !!!

    burdicda's picture

    Kurt W. Pfeifle
    Lawrence Roufail
    Gian Filippo Pinzari

    You people are relentless
    keep up the good work
    and don't let the trolls
    especially ones that have never
    even installed it, go starting
    up some shit.

    I purchased the commercial version waaaay back when it first
    started up and have the doc's hard printed in a binder
    somewhere....

    I find now that I need or greatly desire to reconnect back to
    using nx, I look forward to recontributing both in purchase
    and in feedback in the near future.

    Thank You

    Danny W. Burdick

    White Paper
    Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

    Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

    Learn More

    Sponsored by Red Hat

    White Paper
    Private PaaS for the Agile Enterprise

    If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

    Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

    Learn More

    Sponsored by ActiveState