Hi Yasha:

The NX protocol, as used pre4.0 and served by freenx and others, is X11 that has been protocol-compressed so that no unnecessary X events go over the wire. As it is encapsulated inside ssh, and uses ssh as its only transport, it is indistinguishable from any ssh session.  This is NOT true of the current NoMachine offerings, which can make getting clients a bit chancy, but the protocol will work wherever ssh will work.  If you install the freenx server on your X11 host system, and connect with a 3.x NX client, it will appear to them that you used a key based login to access a ssh session.  No -X is needed, as it uses the channel that it has to talk to its own X11 server on your host system, which it starts and stops on demand. The client software provides the X server on the windows end of things.
Contact me directly for help with clients, as the 3.x clients are no longer available from NoMachine, but have been archived at many institutions. The FreeNX server is available on one of the repositories with all the dependencies, which makes installation a breeze.

Sincerely

Jim

James Fait, Ph.D.
Email: [log in to unmask]

----- Original Message -----
| From: "Yasha Karant" <[log in to unmask]>
| To: "Scientific Linux Users" <[log in to unmask]>
| Sent: Wednesday, May 7, 2014 3:02:05 PM
| Subject: Re: ssh -X xinit failure
| 
| Thank you for the information on www.nomachine.com, etc.  Two points:
|  I
| was not confused about the mechanisms and terminology of X windows,
| but
| the university network security czar administrative (not academic)
| group
| evidently was -- I simply "followed instructions" that clearly are
| incorrect, and, silly me, did not experiment with simple tests.
| Second:
| does the package you recommend behave *IDENTICALLY* to ssh -X so far
| as
| any network security (ports, protocols, packet headers, etc.) can
| detect?  Almost all network protocols are blocked by the same
| security
| group, including some internal packet examination that may be able to
| detect if ssh -X is not being used.  Only ssh -X is "permitted" by
| this
| group for remote X windows, and none of the MS Windows (currently 7)
| university-wide-supplied classroom console "workstations" have any X
| windows servers -- thus I must bring my research laptop to class to
| demonstrate any GUI running on a Linux machine (such as a compute
| server
| with a graphical debugger).  Of necessity, we have more control over
| the
| protocols, etc., used on the research networks, but these are not
| used
| by any direct instructional facility.  Within our Department
| (technically, School), our instructional technicians run our own
| instructional network (separate from any research network), and this
| is
| more permissive of protocols than the university czar group allows --
| although the czar group has attempted to gain control of, and thus
| effectively shut down, our instructional network (that mostly has SL6
| workstations).  However, the question I am pursuing is for use in
| classrooms outside those we control.
| 
| Yasha Karant
| 
| On 05/06/2014 08:43 PM, Nico Kadel-Garcia wrote:
| > On Tue, May 6, 2014 at 10:33 PM, Yasha Karant <[log in to unmask]>
| > wrote:
| >> Thanks for the information.  At my institution, we were told by
| >> the
| >> university network security group that after ssh -X, one still
| >> needed to
| >> "activate" X for the session by xinit or the like for security
| >> reasons.
| >> Evidently, the persons were thinking of some other environment (MS
| >> Windows
| >> perhaps?).  Indeed, xeyes and firefox both work fine from the
| >> remote host to
| >> the local client workstation.
| > *Sigh*. OK, time for some lessons. X reverses the concept of
| > "server"
| > and "client" from how people think of them. "xinit" is used to
| > start
| > an X "server" on your local machine, so that X applications can
| > work
| > correctly. The graphical login presented as a default on most Linux
| > environments is an X based login manager, with an X session already
| > running, so for most Linux environments you don't need it. If you
| > run
| > a server that is at "run level 3", where an X session isn't
| > normally
| > used for logins, then you'd need to run "xinit" on your local
| > system
| > to get things working.
| >
| > "ssh -X" would then run from a terminal session or SSH tool in that
| > X
| > session, running on your local X "server" On the SSH server you log
| > into, if you start X applications, they are then "clients" of your
| > local X "server" connected over SSH.
| >
| > The more common problem is when people neglect to install the
| > necessary X libraries on the remote SSH server, and wonder why "ssh
| > -X" won't work. The necessary tools include "xauth" and X library
| > dependencies and fonts. Start by making sure the remote side has
| > "xauth" installed, if you have trouble that way.
| >
| > Now, with all that said: bare X sessions tend to be bandwidth and
| > resource greedy, and don't share sessions well or hve good tools
| > for
| > controlling how many or which clients are allowed. And the "X
| > servers"
| > for Windows clients often stink. If you need something more
| > effective,
| > and with a *much better* security model than tools like "vnc" for
| > remote X sessions, strongly consider the "www.nomachine.com"
| > toolkits.
| > They'e extremely effective multi-platform X servers wired into
| > their
| > optimized X protocol, and they work very well to provide much
| > better
| > security control of X sessions. It's commercial software, free for
| > personal use, and I do like it greatly over VNC. (I wrote the first
| > SunOS ports of VNC: there's a lot wrong with it.)
| >
| >> A question:  as a regular X window manager desktop from the remote
| >> machine
| >> is not displayed (that is, the pull down menu "Applications" under
| >> Gnome or
| >> the equivalent from KDE), is there any mechanism to get such a
| >> menu, etc.,
| >> displayed?  What is the default GUI file manager (that allows an
| >> end user to
| >> "point and click" on an executable file to execute the
| >> application) that can
| >> be invoked from a remote terminal?
| > See above tools from www.nomachine.com for graceful window manager
| > environments. What you seem to really want is for the X session to
| > be
| > inside a window manager environment, rather than simply running X
| > applications against your local X server. If you want window
| > managers,
| > as it stands, you need to run one *locally* as part of your X
| > server
| > session.
| >
| > The easy way to do this is to run your Linux box in "run level 5",
| > with a GUI based login, so the window manager is alrady running.
| > Otherwise, to run it locally, you'll need to install a window
| > manager
| > and enable it in your .xinitrc or start it from the command line in
| > your running X server terminal session.
| >
| >> Yasha Karant
| >>
| >> On 05/06/2014 02:09 PM, ToddAndMargo wrote:
| >>> On 05/06/2014 01:38 PM, Yasha Karant wrote:
| >>>> I am attempting to get ssh -X working to a remote machine for
| >>>> which I am
| >>>> root.
| >>>
| >>> Hi Yasha,
| >>>
| >>> I can not make heads or tails aver what you wrote: probably
| >>> not smart enough.
| >>>
| >>> Are you able to create a simple terminal?
| >>>
| >>>      ssh -l yasha -t -X -p port IP_address
| >>>
| >>> If it helps, here are my notes on "ssh -X";
| >>>
| >>>    syntax:
| >>>          ssh -l <username> -t -X <ip.of.your.guest> <command>
| >>>
| >>>     For Example:
| >>>          ssh -l todd -t -X 192.168.255.185 /usr/bin/gedit
| >>>
| >>> HTH,
| >>> -T
| >>>
| >>>
| >>>
|