SSH - how does it work?

Hello all there! I’m a new in Linux and trying to understand, how the shh stuff works. My situation is:
1-st computer with openSuse 11.0 (remote)
2-nd computer with openSuse 11.0 (work machine).
Computers are connected locally to each other by Ethernet.
On both computers I’ve VLC Player installed. On the remote computer located some video files which I wanna play on my work machine. I did the following:

  • on the work machine in console I typed “ssh -X user_name_on_remote_machine@remote_machine_host_name”
  • typed the password
  • when it said I’m on remote machine, execute “vlc path/to/video/file”
    On my work machine I see the video, that, actually located on the remote machine. As far, as I understood, I even can delete VLC Player from my work machine and it still would work. I’m trying to imagine a scheme how does it works?
    I have:
  1. X Server (on the remote computer)
  2. X Client (it my VLC Player), that comes from the same remote computer
  3. X Server (on the work machine)
    How do these 3 elements work together in the situation above? Are there some additional instruments/devices I did not mentioned? Is RFB (Remote Frame Buffer) somehow related to this situation?
    Thanks in advance.

ssh <username>@<ipofremotecomputer>

for example if you desired remote user name is user on remote 192.168.1.1

~>ssh user@192.168.1.1
you should ask for password

you have connect to console exactly like in console (ctr+alt+F2:F6)

When you use the -X option for ssh, you are enabling X-forwarding. X-windows is the program that draws things on the screen. X-windows has a client-server architecture, a consequence of which is that the graphics can be displayed on a different machine. In your case, the machine you ssh to is the server, and the one you are sitting at is the client. The X-forwarding is sending all the commands to do the drawing to the client from the server. That way, you are running the program on the server, but the graphics show up on the client.

So, all the client is doing is receiving the instructions on what to draw on the screen from the server, it is not doing any other processing.

I should point out that this only works if you have X-windows on both. In other words, attempting this from a windows machine will not work, unless you install something like Cygwin.

Hope this clears it up a bit for you.

10 minutes fro changing message expires…

i understand later that it is not the answer on your question. sorry. i do not use vlc… afaik mplayer use framebuffer :
maybe you need another one for answer to your question…

You only have two elements at work:

the x client program (vlc) on the remote machine
the x server on your local (work) machine

When you logged in to the remote machine with the -X option, it is saying that programs on this remote machine should connect to the x server on the other (to you- local) machine.

On Wed, 2008-10-22 at 16:16 +0000, diktofon wrote:
> Hello all there! I’m a new in Linux and trying to understand, how the
> shh stuff works. My situation is:
> 1-st computer with openSuse 11.0 (remote)
> 2-nd computer with openSuse 11.0 (work machine).
> Computers are connected locally to each other by Ethernet.
> On both computers I’ve VLC Player installed. On the remote computer
> located some video files which I wanna play on my work machine. I did
> the following:
> - on the work machine in console I typed “ssh -X
> user_name_on_remote_machine@remote_machine_host_name”
> - typed the password
> - when it said I’m on remote machine, execute “vlc path/to/video/file”
> On my work machine I see the video, that, actually located on the
> remote machine. As far, as I understood, I even can delete VLC Player
> from my work machine and it still would work. I’m trying to imagine a
> scheme how does it works?
> I have:

> 1. X Server (on the remote computer)

An X Server “services” the remote computer’s display (it can
be more complex than this… just speaking in general).

> 2. X Client (it my VLC Player), that comes from the same remote
> computer

An X Client communicates with an X Server which services a display.
Therefore an X Client could be anywhere as long as it can somehow
communicate with an X Server.

> 3. X Server (on the work machine)

X Server servicing (apparently) your display.

> How do these 3 elements work together in the situation above? Are there
> some additional instruments/devices I did not mentioned? Is RFB (Remote
> Frame Buffer) somehow related to this situation?
> Thanks in advance.

The remote computer X Server doesn’t really play a part.

The ssh -X allows remote X clients to attach to a local X server
as if they were started locally. This allows the X server to
run in a more secure mode disallowing remote X client connects.
Also, the tunnel via ssh is encrypted and thus interjecting
packets into the X protocol stream between the client and
server is nearly impossible. The tunneling does open up
a security issue on the side of the X client (not anything
new though) where it’s possible to communicate with the
X Server (sort of makes sense… if the client from the
remote host can communicate with the X server then there’s
a potential hole if the remote client host isn’t secure).

So, in your case the vlc is running on the remote client
an forwarding X11 protocol via the ssh tunnel to your
local X server managing your display. This isn’t all
that efficient though. It’s neat that it is possible, but
might not be the most effective way to do what you are
wanting.

One option (try if you want to) is to use a remote file
system (NFS, Samba, other) to allow your machine to get to the
files on the remote host and then use a local vlc player.
It’s possible that might not work as well though… you’ll
have to experiment. There are even some media streamers
out there that might also be an option… though
you’ll have to see if they are “better”.

I made a picture of how I imagined this information. Am I correct?
X_Windowing_scheme.pdf

Here is one additional moment:
when I use “ssh -X remote_user@remote_host” and then start an application on the remote machine, the result is drawing on local machine. That is because, as far as i understood, secure connection manager automatically changes my local $DISPLAY variable to, say, “localhost:10.0”. If I’ll change the variable $DISPLAY from “localhost:10.0” to, say “remote_host:0.0”, then an application result should appear on the remote machine. Is there any possibility to draw the application result on both machines? Maybe it is possible to put both local and remote display into the $DISPLAY variable?

Doesn’t work that way, you cannot send a screen to two locations simultaneously like that.

And anyway it would not be remote:10, it would normally be remote:0. And you would not have the authentication cookie to allow you to write to it. You would have to load the cookie first, usually stored in ~/.Xauthority.

Indeed, and diktofon, a story along the lines of ken_yaps observation … there was a time when I had a couple extra really old PCs on our home LAN running Linux. Running X on them was a pain, because they were so slow.

Hence typically, I ran them in “run level 3” , which means an ascii/text prompt (in a bash terminal session), with net working (ie they had LAN and internet access from an ascii/text prompt). But with run level 3, X window is NOT running. They were running no graphics. ie I did not boot to X on them, … I booted instead them to run level 3.

Then from another (slightly newer) PC on our home LAN, where this “other” slightly newer pc was a bit faster, I ran KDE-3.5.5 (back in those days) and I would log on to the the much older PCs (that were in run level 3 and NOT running X window) with ssh. I would then run applications (remotely) on those older PCs, and pipe the graphics back over the LAN to my slightly newer PC. … I found that worked much better with these older PCs.

It was also educational.

Ok, thanks, this problem with two desktops seems resolved to me. But what about the scheme I made in my previous post?

No one knows about scheme I made?
[size=]X_Windowing_scheme.pdf[/size]](http://rapidshare.com/files/156935125/X_Windowing_scheme.pdf)