On Tue, May 6, 2014 at 10:33 PM, Yasha Karant <ykar...@csusb.edu> 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 >> >> >> >
