Hi All, Just a curious question regarding connection to remote X11 machines through ssh.
Today, I was wanting to edit some remote files on my university's data server. I used the following command to connect:
ssh -Y ...
I noticed though on connecting and using emacs to open the required file the GUI of the server (which uses KDE) was loaded not my local GUI (Gnome) with the data of the file imported.
I was wondering if anyone knew how to configure ssh or X11 so that my local GUI is loaded and remote data is imported.
Thanks for all your help.
All the best.
Cheers, Tony Crouch
Hi,
Today, I was wanting to edit some remote files on my university's data server. I used the following command to connect:
ssh -Y ...
I noticed though on connecting and using emacs to open the required file the GUI of the server (which uses KDE) was loaded not my local GUI (Gnome) with the data of the file imported.
What exactly do you mean here ? emacs does not uses gnome or KDE.
what you did was log on to the remote server and run emacs there, on that box. ssh was simply forwarding the X window back through the remote connection, to be displayed on your machine. Your machine was not really doing any else other than this.
I guess what you mean is the emacs window you get from your remote server 'looks' different in some way to the one you get when running locally. This could be due to any number of reasons, like a different emacs version (in Fedora7 for instance a new version is used which does look quite different to most other distros which have an older one), or just what you have in your ~/.emacs file on either system.
I was wondering if anyone knew how to configure ssh or X11 so that my local GUI is loaded and remote data is imported.
Again guessing, what I think you are asking is how to start an emacs session on your local machine, but give it access to the data on the remote server ? if so, then you need to set up some way to make the files on the remote server accessible to your local machine (connecting via ssh does not do this, you are simply logged on to the remote machine directly.)
one way, which I use to do exactly this and works nicely is to use sshfs - a fuse based userland file system which lets you mount remote filesystems via ssh. you can install it via
yum install fuse-sshfs
googling for sshfs will bring up loads of sites explaining how to use it, but this is as good as any
http://en.wikipedia.org/wiki/SSHFS
note - one gotcha is you will need to add your local user to the fuse group on your machine, in order to be allow to run fusermount
cheers Chris
Thanks for all your help.
All the best.
Cheers, Tony Crouch
On Sat, 2007-08-04 at 20:17 +1000, Tony Crouch wrote:
Hi All, Just a curious question regarding connection to remote X11 machines through ssh.
Today, I was wanting to edit some remote files on my university's data server. I used the following command to connect:
ssh -Y ...
I noticed though on connecting and using emacs to open the required file the GUI of the server (which uses KDE) was loaded not my local GUI (Gnome) with the data of the file imported.
I was wondering if anyone knew how to configure ssh or X11 so that my local GUI is loaded and remote data is imported.
What you experience is what I would expect to happen. I am not sure this behavior can be changed. You are running the remote window manager under your X.
-- ========================================================== Do not despair of life. You have no doubt force enough to overcome your obstacles. Think of the fox prowling through wood and field in a winter night for something to satisfy his hunger. Notwithstanding cold and hounds and traps, his race survives. I do not believe any of them ever committed suicide. -- Henry David Thoreau ======================================================================= Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam@sbcglobal.net
What you experience is what I would expect to happen. I am not sure this behavior can be changed. You are running the remote window manager under your X.
I don't think think it is the window manager. Logging on via ssh does not start a full session, so no window manager would have been started on the remote machine. All he did was start a single emacs process on the remote machine and export the display back to the local machines X session, where the local window manager takes care of the window.
I suspect any visual differences are just due to different versions of emacs, or different emacs configurations.
Chris
On Saturday 4 August 2007 7:28:29 pm Konstantin Svist wrote:
Chris Jones wrote:
Logging on via ssh does not start a full session
Somewhat off topic: is there a way to start a full session remotely?
Yes, several ways ...
Firstly, at the login window, under the menu you should see an option for remote login (at least on my Fedora7 box here, installed from the KDE live CD thats the case. On the standard Fedora7 install, or a different distro it might be label different or missing).
If you do have this you can type in the IP address of the remote session and attempt to login. Note this will only work in the sysadmin at the remote site have configured things to allow this sort of a connection (xdm I think, not sure). In any case I wouldn't want to use it over anything other than a fast (100Mb plus) local network.
Other ways include starting a VNC session on the remote service, and connecting to that via vncviewer. Another would be to use the freenx system. Googling for either of these should bring up loadds of info.
A real low level way would be to start a empty X server on your local machine, then login into the remote site via SSH, through the console for instance, export the display back to the new empty Xserver and run 'startkde' or whatever to fireup your remote session on your local X server. Again, only try this on a fast network.
Chris
Firstly, at the login window, under the menu you should see an option for remote login (at least on my Fedora7 box here, installed from the KDE live CD thats the case. On the standard Fedora7 install, or a different distro it might be label different or missing).
Thought of another way ;)
Switch to the console on your local machine (alt-cntrl-F1) and login. Then run
X :2 -query <remote-host>
This is basically what the suggestion above does.
One other nice things about this, is if you use the local host name in place of <remote-host> you basically start a second X session on your local box. ( This is effectively all that the 'switch-user' buttons in the latest KDE/gnome releases, but useful on systems which don't have this. )
Chris
Chris Jones wrote:
Firstly, at the login window, under the menu you should see an option for remote login (at least on my Fedora7 box here, installed from the KDE live CD thats the case. On the standard Fedora7 install, or a different distro it might be label different or missing).
Thought of another way ;)
Switch to the console on your local machine (alt-cntrl-F1) and login. Then run
X :2 -query <remote-host>
This is basically what the suggestion above does.
One other nice things about this, is if you use the local host name in place of <remote-host> you basically start a second X session on your local box. ( This is effectively all that the 'switch-user' buttons in the latest KDE/gnome releases, but useful on systems which don't have this. )
Chris
Very cool, thanks!
Now let's assume SSH is the only open port on remote machine (local, too, but that doesn't usually matter). Which of the methods you mentioned are still viable?
Thanks!
Very cool, thanks!
Now let's assume SSH is the only open port on remote machine (local, too, but that doesn't usually matter). Which of the methods you mentioned are still viable?
If we are talking about connections over a slow network (by which I mean anything less than a 100Mbp local network !) I would go the vnc or freenx route. Anything else is likely to be too slow to use in practice.
I have no experience with freenx (although I've heard good things about it) but have used vnc, so I'll describe this.
First, you have to start a vnc session on the remote machine. Note that vnc is not an inherently secure system, not at all in fact but it can be used securely. I would run something like
vncserver :8 -localhost -geometry 1024x768
to start a vncserver session, on display 8, screen dimensions 1024x768
The -localhost is important, as this means you can only connect to the vnc session from the 'localhost' (i.e. the remote one). Whats use this I hear you ask, well ...
on you local host run
vncviewer -via <username>@<remote-host> :8
The via means vncviewer will first establish an SSH connection to the remote host. Then, once there it will connect to the vnc server, and pipe everything back to you via the SSH tunnel. Hence at the remote machine the vncserver is connected to from its 'localhost' and all is well.
one final thing, killing the vncviewer does *not* kill the session. This is partly what makes this useful as it means you can disconnect at one location, move to another machine and reconnect and find you desktop just as it was before. However, for security reasons when you finally no longer need the vnc session, you need to explicitly kill it with
vncserver -kill :8
from the remote site.
As I said at the start, I've also heard good things about freenx. I gather it makes the process much slicker, without the need for all the CLI stuff. However, its not at all standard in most distros, whilst vnc is and installing in places significant burden on the remote sys-admin, so you might have to fight to convince them to do so (unless you happen to be that admin ;) )
Chris
Chris Jones wrote:
Very cool, thanks!
Now let's assume SSH is the only open port on remote machine (local, too, but that doesn't usually matter). Which of the methods you mentioned are still viable?
If we are talking about connections over a slow network (by which I mean anything less than a 100Mbp local network !) I would go the vnc or freenx route. Anything else is likely to be too slow to use in practice.
I have no experience with freenx (although I've heard good things about it) but have used vnc, so I'll describe this.
First, you have to start a vnc session on the remote machine. Note that vnc is not an inherently secure system, not at all in fact but it can be used securely. I would run something like
vncserver :8 -localhost -geometry 1024x768
to start a vncserver session, on display 8, screen dimensions 1024x768
The -localhost is important, as this means you can only connect to the vnc session from the 'localhost' (i.e. the remote one). Whats use this I hear you ask, well ...
on you local host run
vncviewer -via <username>@<remote-host> :8
The via means vncviewer will first establish an SSH connection to the remote host. Then, once there it will connect to the vnc server, and pipe everything back to you via the SSH tunnel. Hence at the remote machine the vncserver is connected to from its 'localhost' and all is well.
one final thing, killing the vncviewer does *not* kill the session. This is partly what makes this useful as it means you can disconnect at one location, move to another machine and reconnect and find you desktop just as it was before. However, for security reasons when you finally no longer need the vnc session, you need to explicitly kill it with
vncserver -kill :8
from the remote site.
As I said at the start, I've also heard good things about freenx. I gather it makes the process much slicker, without the need for all the CLI stuff. However, its not at all standard in most distros, whilst vnc is and installing in places significant burden on the remote sys-admin, so you might have to fight to convince them to do so (unless you happen to be that admin ;) )
What about 100/1000 connections with SSH-only?
What about 100/1000 connections with SSH-only?
Well, at the end of the day I cannot tell you whats best for you - why not try out the alternatives and see what fits ?
FWIW, I would probably still use vnc(or freenx) - As Les says it has the advantage that you can close the session and reopen it as it was at a later date / different location.
Chris
Konstantin Svist wrote:
As I said at the start, I've also heard good things about freenx. I gather it makes the process much slicker, without the need for all the CLI stuff. However, its not at all standard in most distros, whilst vnc is and installing in places significant burden on the remote sys-admin, so you might have to fight to convince them to do so (unless you happen to be that admin ;) )
What about 100/1000 connections with SSH-only?
You can ssh-tunnel just about anything, but I'd still pick freenx/NX as the first choice if you plan to use it much and only consider the others where that isn't available. If the target is fedora, just 'yum install freenx'. Then you need to get the client ssh key from /etc/nxserver to the client machine and import it in the client configuration program - and make sure the 'use ssl encryption for entire session' option is set. Everything else is pretty obvious. I've only used the windows and mac clients though, so I'm not quite sure how the linux client setup works.
thanks everyone for the advice
and sorry for threadjacking 0:-)
Les Mikesell wrote:
Konstantin Svist wrote:
As I said at the start, I've also heard good things about freenx. I gather it makes the process much slicker, without the need for all the CLI stuff. However, its not at all standard in most distros, whilst vnc is and installing in places significant burden on the remote sys-admin, so you might have to fight to convince them to do so (unless you happen to be that admin ;) )
What about 100/1000 connections with SSH-only?
You can ssh-tunnel just about anything, but I'd still pick freenx/NX as the first choice if you plan to use it much and only consider the others where that isn't available. If the target is fedora, just 'yum install freenx'. Then you need to get the client ssh key from /etc/nxserver to the client machine and import it in the client configuration program - and make sure the 'use ssl encryption for entire session' option is set. Everything else is pretty obvious. I've only used the windows and mac clients though, so I'm not quite sure how the linux client setup works.
Chris Jones wrote:
On Saturday 4 August 2007 7:28:29 pm Konstantin Svist wrote:
Chris Jones wrote:
Logging on via ssh does not start a full session
Somewhat off topic: is there a way to start a full session remotely?
Yes, several ways ...
Firstly, at the login window, under the menu you should see an option for remote login (at least on my Fedora7 box here, installed from the KDE live CD thats the case. On the standard Fedora7 install, or a different distro it might be label different or missing).
If you do have this you can type in the IP address of the remote session and attempt to login. Note this will only work in the sysadmin at the remote site have configured things to allow this sort of a connection (xdm I think, not sure). In any case I wouldn't want to use it over anything other than a fast (100Mb plus) local network.
Other ways include starting a VNC session on the remote service, and connecting to that via vncviewer. Another would be to use the freenx system. Googling for either of these should bring up loadds of info.
A real low level way would be to start a empty X server on your local machine, then login into the remote site via SSH, through the console for instance, export the display back to the new empty Xserver and run 'startkde' or whatever to fireup your remote session on your local X server. Again, only try this on a fast network.
On a local LAN, if you have gdm configured to accept remote sessions, you can bring up another system in runlevel 3 so X doesn't start automatically, then start it with "X -query remote_host" and you'll get a GUI login prompt followed by the remote desktop. This also works with the Cygwin Windows version with "Xwin -query remote_host". If you want to run a remote desktop in an already running X session, use "Xnest -query remote_host". However, for remote access over lower bandwidth connections and often even locally there are advantages to using freenx on the server and the cross-platform NX clients from http://www.nomachine.com. Among other things it will let you disconnect a running session and reconnect later, perhaps from a different location, with everything still running.
If you want to run a remote desktop in an already running X session, use "Xnest -query remote_host".
Ah yes, I knew I would forget one ;)
BTW : In the above command you need to specific the display number, otherwise it defaults to :0 and thus will complain as that is normally your current X session. Just run for instance
Xnest :10 -query remote_host
to start Xnest using display 10 (10 is an example, any number will do)
see
http://en.wikipedia.org/wiki/Xnest
for more details
Chris
Chris Jones wrote:
If you want to run a remote desktop in an already running X session, use "Xnest -query remote_host".
Ah yes, I knew I would forget one ;)
BTW : In the above command you need to specific the display number, otherwise it defaults to :0 and thus will complain as that is normally your current X session. Just run for instance
Xnest :10 -query remote_host
to start Xnest using display 10 (10 is an example, any number will do)
see
http://en.wikipedia.org/wiki/Xnest
for more details
Chris
To do it over an ssh connection, I usually start an xterm in the xnest window, and ssh to the remote machine and start the window manager there.
Xnest :2 -once -auth ~/.Xauthority & xterm -display :2
Then run ssh -Y <remote_host> and run your window manager on the remote host. I would not try for the full gnome or KDE desktop, but something like blackbox would work. Without the -auth option to Xnest, it will reject connection attempts.
Mikkel
-
Aaron Konstam -
Chris Jones -
Konstantin Svist -
Les Mikesell -
Mikkel -
Tony Crouch