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