[kwlug disc.] Understanding the X Window System

[Chris Frey]

On Tue, Feb 06, 2007 at 02:48:44PM -0500, Oksana Goertzen wrote:
> I spent some time going over my notes [and the ones you provided] - thanks!
> Hey, it was a great presentation!  The place was quiet when you were
> talking.  :)

Thanks.  I'm glad everyone felt comfortable adding to the discussion.
I wasn't sure the presentation would last the full two hours, but when
I finished, it was 9pm exactly.

Hopefully some details can be hammered out on the list here, for those
who didn't make it.


> I had heard that VNC wasn't as secure as ssh, so one should always use ssh.
> Seems like any ssh session that exports X isn't so safe.. depending on the
> machine you're connecting to... etc.  I did read the section on VNC you

I didn't mean to imply that ssh is a hazard.  Just that anyone with root
access on the remote machine can access your X server through the forwarded
port, since the xauth magic cookie can be read.  And it is just a password
of sorts... a long password, but just a password, and in the clear.

VNC on the other hand, unless I'm mistaken, has no encryption whatsoever.
The password challenge might be hashed or obfuscated in some versions,
but for the most part, everything is out there:  your mouse movements,
your keystrokes, and the screen itself.

As Unsolicited mentioned, all that could be sniffed and put back together
on some third party's machine.  I don't think the bandwidth concerns are
that great of an obstacle either.  The data is already reduced as much
as possible by VNC itself, and a hacker might want to watch it in real time.

So to secure VNC sessions, I tend to use ssh's plain port forwarding,
similar to:

	ssh -x -L5901:localhost:5900 user at remote
	vncviewer localhost:5901

Then all the vnc traffic is tunneled through the already-encrypted ssh
connection.


> provided below - the url.  VNC works more like a traditional client-server,
> whereas exporting X through ssh (or port forwarding) the data is exported
> but the X server is on your local machine.  Do I have this right?  And X
> server uses udp - is that what you said?  In looking up VNC it says it uses
> something called remote framebuffer.  For some reason I thought VNC used
> screen scrapes.  VNC doesn't use encryption by default I thought.  On KDE

VNC on Linux behaves like this:

                         The VNC X Server
                    +-----------------------+
     vncviewer ---> [ VNC Server<->X Server ] <---- X client programs
                    +-----------------------+

So I imagine this "framebuffer" is the buffer that the VNC server uses
to draw the X client output.  It then translates any updates on the
internal "screen" into data for the vncviewer, and sends those updates
in its own Remote Framebuffer Protocol.

On Windows, there is no such thing as an X Server or X client programs,
so VNC has to do screen scrapes, and try to hook into Windows events
to optimize this as much as possible.


> I found in xterm or actually I guess Konsole in KDE that the ctrl-right
> click or ctrl-left click didn't work for the font menu - but it's not
> strictly xterm.  However, the ctrl+right click brought up other Konsole
> options.  Just using the middle button only pasted a selection (not a cut
> buffer) from Firefox.

Yep, the Ctrl+mouse is xterm specific.


> I"m assuming if you use ssh only it doesn't produce the
> mit.magic.cookiesfile.

That's correct.  If you turn off X forwarding (either explicitly with the
-x switch, or through /etc/ssh/ssh_config) then the magic cookie doesn't
get created, and furthermore, the forwarded TCP port doesn't get created
either.

You can test this yourself with:

	ssh -X remotehost
	remote> netstat -ant

You'll see port 6010 open.  That's your forwarded X port.  If you use
ssh -x remotehost, that port will not exist.


> My understanding is that ssh uses the public
> key from the server and
> the public key from the client to encrypt the data stream.  If the client's
> public key is found on the server, then you don't have to use a password to
> connect - but I guess you would need the client private key to decrypt the
> stream of data... so there is still something on the client side that needs
> to be there.  It sounds as though ssh -X creates a temporary key - and uses
> this key as a symmetric cipher  - i.e. that it uses the same key for both
> encryption and decryption... and this key is available for that session, to
> anyone who has root [or can become root] on the system.

In ssh's case, there is only one public/private key pair that is required,
and that lives on the server.  The public key is sent to the ssh client the
first time it connects, which is why you get that prompt "Accept this key?"
etc.

Once the ssh client has the public key, it can communicate securely
with the server.  As Unsolicited explained, this is used to setup a random
key, which is then used for the main data encryption.  The public/private
keys are then done, and the new secret random key is used for that session.

I believe that is called symmetric encryption, and different from
public/private encryption.  It is more suited for streams of data.

So this handshake still needs to ask the client for a password.

To avoid the password, the client can additionally use its own public/private
key pair, and place the public key on the server.  Then the authentication
is based on the client proving he has the private key to the expected
public key.


So that explains how ssh does the encryption.  This is not repeated
when you do ssh -X.  ssh -X merely forwards a tcp port to the remote
machine, so that connecting to it is the same as connecting to your local
X server.  And in doing so, ssh creates its own magic cookie, which is
just a password for the X server.


> I'm assuming that if your home directory mounted as a fileshare then
> possibly your hidden directory for .gnupg could be also more or less
> available.  When I looked at the file on my machine it's a binary file - so
> would that make it more protected?

Your private key should not be on a network filesystem, just for paranoia's
sake. :-)

But it is protected, by your passphrase.  As long as you have a good
passphrase, any attacker would have to crack that first before being
able to unlock your encrypted files.

And the ssh client's handling of its private key can be done in the same way,
using a passphrase to unlock it before using it to authenticate to the
ssh server.

- Chris