Remotely Useful?

Mark McLoughlin

FUDCon2 @ LinuxTag

Overview

Covering a pretty random selection of topics related to making the Fedora Desktop more useful over the network

Use cases

Vino

Terminal services

Session migration

Secure terminal services

The goal here is to pique hackers' interests here – this is an area where hackers can have a whole lot of fun

Use Cases

Abby has a problem and calls helpdesk; how can Horatio fix Abby's problem while showing her how to fix it herself in future?

If Horatio needs to shut down a runaway program on Abby's computer while Abby is away, how does he do it?

Horatio needs to set up a call-centre office – lots of computers, low impact users, needs something cheap and easy to manage – what does he do?

Abby needs to give a presentation in a nearby meeting room. Wouldn't it be nice if she could just get to her running desktop session from the meeting room?

Horatio wants to guide a colleagure in a remote office through some new process; what does he do?

Use Cases

Put more simply:

Remote administration

Collaboration

Terminal services

Mobile sessions

Remote Display Protocols

VNC/RFB

X11 (of course)

NX (compressed X11)

Microsoft's RDP

Citrix ICA

Tarantella's AIP

Sun Ray

Remote Display Protocols

On a high bandwidth, low latency network, X11 actually works pretty well

Main interesting optimisation point is reducing roundtrips – fix the apps, use a proxy server?

On lower bandwidth, higher latency networks, VNC works better because the client rate-limits the server

On these types of networks, NX has also been shown to do well when a proxy server is used

Another interesting difference between X11 and VNC is where the display state is maintained – with X, its all on the client (i.e. the Xserver) and with VNC the client maintains no state

Vino

Designed for the “remote administration” use case

With some more hacking would work very well for collaboration

Vino is a VNC server which which exports an unmodified GNOME session

Two possible strategies to get the screen contents:

GetImage based polling algorithm; very slow

No polling necessary when using XDAMAGE extension

The RFB protocol code was grabbed from the libvncserver project, which in turn is made up of copied and pasted code from RealVNC, UltraVNC and TightVNC

Future Vino Work

Protocol is unencrypted and authentication is weak

Some work done to support TLS/SSL, but did not support client or server authentication

Perhaps direct support for SSH tunnels might be a more interesting approach

No UI to support collaboration

Notification area icon which notifies the user when someone has connected; would allow the user to disconnect other users

Perhaps an “invitation” ticket – e.g. a limited lifetime password; KDE does this

Service discovery

Needing to know the hostname of the remote session sucks

DNS-SD maybe? There's an reasonable looking patch to use howl in bugzilla

Thin Clients and Terminal Services

Several orthogonal problems in the area of thin clients, two of which are

How to get an operating system loaded onto the thin client

How to get that operating system to display a useful user interface

Projects like LTSP, PXES, ThinStation and Stateless Linux tackle the first problem with solutions like PXE or Boot ROMs with an NFS mounted root directory or an initrd containing an entire root image

What solutions does Fedora have for the second problem?

GDM Exposed

GDM is critical in this area, so lets quickly look at how GDM does what it does

On startup GDM “manages” any available local displays

What “manages” really means is “displays a login screen”

Users can then login and GDM will start a GNOME session on the display

GDM Exposed

GDM starts up

Master

GDM Exposed

Master process starts a slave process for each display

Master

Slave

GDM Exposed

Slave process starts an Xserver for the display

Master

Slave

Xserver

GDM Exposed

Slave displays a login screen; waits for username/password

Master

Slave

Xserver

Greeter

GDM Exposed

Once the user enters username/password, slave starts the GNOME session

Master

Slave

Xserver

Greeter

Session

GDM Exposed

Finally, the slave shuts down the greeter

Master

Slave

Xserver

Session

GDM and XDMCP

With a terminal server, the Xserver isn't running on the same machine as GDM

The Xserver uses the X Display Manager Protocol (XDMCP) to request that GDM manage it

GDM and XDMCP

GDM running on server; Xserver starts up on terminal

Xserver

Master

Server

Terminal

GDM and XDMCP

Xserver requests a login screen from GDM using XDMCP

Xserver

Master

Server

Terminal

GDM and XDMCP

GDM starts a slave process; slave in turn starts the greeter

Xserver

Master

Slave

Greeter

Server

Terminal

GDM and XDMCP

Once authenticated, slave starts the GNOME session

Xserver

Master

Slave

Greeter

Session

Server

Terminal

GDM and XDMCP

Finally, the slave shuts down the greeter

Xserver

Master

Slave

Session

Server

Terminal

GDM and Session Migration With VNC

When it comes to terminal services, a very interesting feature is “session migration” or “hotdesking”

Users should be able to login at one terminal, disconnect, login at another terminal and get their session back again unchanged

First-cut implementation of this used VNC rather than X11/XDMCP

GDM and Session Migration With VNC

GDM running on the server; vncviewer starts up on the terminal

vncviewer

Master

Server

Terminal

GDM and Session Migration With VNC

VNC client opens a VNC connection with GDM

vncviewer

Master

Server

Terminal

GDM and Session Migration With VNC

In response GDM starts a slave which launches a VNC server

vncviewer

Master

Slave

Server

Terminal

Xvnc

GDM and Session Migration With VNC

GDM drops the VNC connection and Xvnc takes it over

vncviewer

Master

Slave

Xvnc

Server

Terminal

GDM and Session Migration With VNC

Greeter started; displays login screen

vncviewer

Master

Slave

Greeter

Xvnc

Server

Terminal

GDM and Session Migration With VNC

User authenticates; GNOME session started

vncviewer

Master

Slave

Greeter

Session

Xvnc

Server

Terminal

GDM and Session Migration With VNC

Greeter shuts down

vncviewer

Master

Slave

Session

Xvnc

Server

Terminal

GDM and Session Migration With VNC

At some point the user disconnects the VNC client, session stays running

Master

Slave

Session

Xvnc

Server

Terminal

GDM and Session Migration With VNC

At another terminal, a different VNC client starts up

vncviewer

Master

Slave

Session

Xvnc

Terminal

Server

GDM and Session Migration With VNC

Again, the client initiates a VNC connection with GDM

vncviewer

Master

Slave

Session

Xvnc

Server

Terminal

GDM and Session Migration With VNC

Slave spawned; starts a new VNC server

vncviewer

Master

Slave

Session

Xvnc

Slave

Server

Terminal

Xvnc

GDM and Session Migration With VNC

VNC server takes over the connection; greeter starts up

vncviewer

Master

Slave

Session

Xvnc

Slave

Xvnc

Server

Terminal

Greeter

GDM and Session Migration With VNC

User authenticates; GDM takes control of VNC connection again

vncviewer

Master

Slave

Session

Xvnc

Slave

Xvnc

Server

Terminal

Greeter

GDM and Session Migration With VNC

GDM transfers VNC connection to original VNC server

vncviewer

Master

Slave

Greeter

Session

Xvnc

Slave

Xvnc

Server

Terminal

GDM and Session Migration With VNC

GDM shuts down the slave and greeter; user continues using original session

vncviewer

Master

Slave

Session

Xvnc

Server

Terminal

GDM and Session Migration With X11

This works reasonably well, but one worry was that when we have a new rendering system based on Composite/Cairo/GL (or whatever); a low level bit pushing protocol like VNC won't perform as well as a higher level protocol

Think about wobbly windows – with VNC, you'd have to continually re-push the contents of the window during the animation, but with X11 you'd only need to send the commands to update the windows transformation matrix

In order to implement the same feature using X, you need an X proxy server (like Xnest, DMX etc.) which is capable of disconnecting from its parent display and later re-connecting to another display

GDM and Session Migration With X11

GDM running on server; Xserver starts up on terminal

Xserver

Master

Server

Terminal

GDM and Session Migration With X11

Xserver requests login screen using XDMCP

Xserver

Master

Server

Terminal

GDM and Session Migration With X11

Slave spawned; starts an X proxy server

Xserver

Master

Slave

Xproxy

Server

Terminal

GDM and Session Migration With X11

Greeter displays login screen on the proxy

Xserver

Master

Slave

Greeter

Xproxy

Server

Terminal

GDM and Session Migration With X11

User authenticates; session runs on proxy; greeter shuts down

Xserver

Master

Slave

Session

Xproxy

Server

Terminal

GDM and Session Migration With X11

At some point the user disconnects at the terminal; session stays running

Master

Slave

Session

Xproxy

Server

Terminal

GDM and Session Migration With X11

At a new terminal; Xserver starts up; requests login screen with XDMCP

Xserver

Master

Slave

Session

Xproxy

Server

Terminal

GDM and Session Migration With X11

Slave spawned; a new X proxy starts

Xserver

Master

Slave

Session

Xproxy

Slave

Xproxy

Server

Terminal

GDM and Session Migration With X11

Greeter displays login screen on new proxy

Xserver

Master

Slave

Greeter

Session

Xproxy

Slave

Xproxy

Server

Terminal

GDM and Session Migration With X11

User authenticates; GDM tells new X proxy to disconnect

Xserver

Master

Slave

Greeter

Session

Xproxy

Slave

Xproxy

Server

Terminal

GDM and Session Migration With X11

GDM now tells original X proxy to connect to the new Xserver

Xserver

Master

Slave

Greeter

Session

Xproxy

Slave

Xproxy

Server

Terminal

GDM and Session Migration With X11

New slave and X proxy shuts down; user continues with original session

Xserver

Master

Slave

Session

Xproxy

Server

Terminal

Secure Terminal Services and GDM

Several major problems remain with GDM, XDMCP and X11 for terminal services

The protocols are unencrypted – attackers can easily snoop keystrokes, the X display cookie, observe the session etc.

Authentication is extremely resource hungry on the server – because authentication involves launching an X server and displaying a login screen, denial of service attacks are straightforward

It should be possible to solve both problems using SSH

(This is the last set of wacky diagrams. I promise.)

Secure Terminal Services and GDM

GDM runs on both terminal and server; SSH server on server too

Master

Master

SSH

Server

Server

Terminal

Secure Terminal Services and GDM

GDM on terminal starts slave; slave starts Xserver and greeter

Master

Master

Slave

Xserver

Greeter

SSH

Server

Server

Terminal

Secure Terminal Services and GDM

Slave starts an SSH client; SSH authentication happens through greeter

Master

Master

Slave

Xserver

Greeter

SSH Client

SSH

Server

Server

Terminal

Secure Terminal Services and GDM

SSH authentication complete; slave uses SSH connection to contact remote GDM

Master

Master

Slave

Xserver

SSH Client

SSH

Server

Server

Terminal

Secure Terminal Services and GDM

GDM on server then starts a slave and X proxy

Master

Master

Slave

Xserver

SSH Client

Slave

Xproxy

SSH

Server

Server

Terminal

Secure Terminal Services and GDM

Proxy connects to parent Xserver using SSH X11 forwarding

Master

Master

Slave

Xserver

SSH Client

Slave

Xproxy

SSH

Server

Server

Terminal

Secure Terminal Services and GDM

Slave immediately starts GNOME session on proxy; user already authenticated

Master

Master

Slave

Xserver

SSH Client

Slave

Session

Xproxy

SSH

Server

Terminal

Server

Summary

Vino has been fairly successful; still needs

Collaboration features

Secure authentication and protocol encryption

Service discovery

Lots of potential for really kick-ass terminal services support in GDM

Hotdesking support

Performance improvements using an X proxy

Secure authentication and protocol encryption

2005-05-23T13:58:37