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
>>>
>>>
>>>