Xforwarding SSH

[dev-s]

Hi all,
I checking out the X forwarding protocol and having some basic questions

Env description:
----------------
From win machine which contains X server, I'm running putty and login to remote linux machine.
Then from this SSH client, I running some x app (for example xclock)

My questions:
-------------
1. Is this possible to bypass the local X server from the SSH client.
for example, assuming I have only this SSH client (same window machine) and I changed the DISPLAY variable to something different than localhost:10.0 - can it work? is there a way to pass the display to some other display that is not the local X server display?
2. how can I block at all the X normal connection such that I make sure only x forwarding works (via SSH)?
3. Is it even possible to set real ip other then local host in the DISPLAY variable. when I do that, oit didn't work for me.
tx.
devs

[kemo]

hello

yes you can forward the X display to any X server,

# DISPLAY=X_SERVER_IP:0.0
# export DISPLAY

you can redirect to real IP, check the connectivity between the X client and the X server first.

xhost command may help you allow other clients to use the server X display.

thanks
kamal

[dev-s]

Hi kamal,
pls note that I'm using the SSH tunneling.
I wonder if the SSH client will allow me to bypass the tunnel it created between the SSH client and the Xserver.
I'm not talking about the normal X connection.

tx

[dev-s]

Let me give you all some scenario that might help you give me the direct answer:

Is the following scenario possible?
1. X server is installed on my pc
2. I open a putty from my pc (with x11 enable) to some unix remote machine
3. after login to the remote unix machine the DISPLAY is automatically set to localhost:10.0 (by the putty)
=> in this stage: can I tell putty to redirect the display to some other screen - not localhost?
Assume that someone watches the X server machine (that would be my software) and one open the putty, but did something such that my software won't be able to "see" what he does...

what do you say?

[Matti_Kurkela]

Yes, your scenario is possible.

If the other X server is unprotected (in "xhost +" mode), redirecting the display is as simple as changing the DISPLAY variable before starting a X application.

If the other X server is protected, you would also have to provide the other server's xauth "cookie" to your session in the linux machine. But if you set up the other X server, you would probably have a way of knowing that cookie: if you know the cookie, adding it requires only a simple "xauth add ..." command. (In SSH forwarded X connections, sshd does this automatically for you.)

To block your scenario, you need to understand how normal (non-forwarded) X connections work: the X *application* connects from the Linux host to the X server *in your workstation*. This is a TCP connection, and the destination port number is 6000 + (the number before the dot in the DISPLAY value).

For example, setting DISPLAY to evilbox:66.0 would make the X applications attempt to connect to the display at system "evilbox" in port 6066.

If you block all outgoing TCP connections from the Linux server with the destination port in the 6000+ range, you can stop this from working. Of course you need to make sure this does not overlap with any required network services.

In Linux, this could be done using IPTables:

# Allow outgoing X11 connections to displays 0..100 over loopback interface
iptables -A OUTPUT -o lo -p tcp --dport 6000,6100 --syn -j ACCEPT
# Drop all other outging X11 connection attempts
iptables -A OUTPUT -p tcp --dport 6000,6100 --syn -j DROP

Another way would be to set the DISPLAY variable as read-only in /etc/profile. A clever user might be able to work around this, but it works as a warning: you should not be changing that!

# Set $DISPLAY to read-only
readonly DISPLAY

MK

[dev-s]

Hi man,
tx for the good answer :)
Let me just get in to some details:

1. In Xforwarding - the port mechanism is the same as the normal x connection - yes? if so, can I block any normal x connection that is not the x forwarding protocol?

2. what is the best way for achieving my purpose:
There is the pc machine (where the xserver is running)
end users can connect via RDP to this machine and open ssh client to run x application.
The users should get the display on their screen but I also want the display on the pc screen itself (I monitoring the user's actions)
Since I want to monitor each action, I also want to avoid any screen redirection.

waiting to your answers
s

[Matti_Kurkela]

1.) Xforwarding:
When SSH X11 forwarding is requested, the SSH client requests a forwarded X11 connection from the remote sshd. Sshd then sets up a listening socket in the 6010+ range, sets up DISPLAY (pointing to the localhost socket) and xauth keys, and then starts the session.

When a X11 application starts up, it contacts sshd instead of the X server: sshd acts as a proxy, transmitting the X11 traffic in encrypted form inside the SSH protocol stream to the SSH client. The SSH client then pretends it's the X11 application and connects to the client's local X server.

Only the SSH protocol stream is encrypted: a basic X11 traffic is not encrypted at all. When SSH X11 forwarding is used, all non-encrypted connections can be from localhost to localhost (one between the X application and sshd, and another between the SSH client and the X server). Thus, all traffic that goes onto network will be encrypted and going through the SSH connection (typically port TCP/22)

So when you block all non-local X11 traffic, SSH X forwarding will be the only remaining X11 remote solution.


2.) Monitoring your users:

I'm not a Windows administrator, but Googling for "RDP session monitoring" indicates there are a lot of solutions for monitoring a RDP session. If you use such a solution, you'll see everything the RDP user sees - including the X11 session and everything that happens in it.

Since the X server is running on a Windows system, it might be more efficient to monitor at the RDP level rather than X11 level, because the RDP protocol is native to Windows: it might require less back-and-forth data conversions.

MK

[dev-s]

Best answer again.
About the RDP I'm fine.
Regarding the non-localhost:
1. so... if I'm understating correctly (and i hope this is correct) SSH X forwarding is relevant only to localhost - yes?!
2. to block all the other - I should follow what you just mentioned in the last answer - with the iptables command?
3. is it normal to run xserver per session????
(if the answer is NO, let me know how to implement the next scenario)
for example: each user connects from RDP to the xserver machine and invokes the X server with some display.
then it run some x app via ssh client.

Now, because I want each session to have its own display, each user runs its own x-server with specific display.
BUT, one user can change the DISPLAY to direct to the other session, such that operation he does will be displayed on the other session screen.
How can I avoid that?



tx a lot!
s

[Matti_Kurkela · Accepted solution]

1.) Assuming I understood your question correctly... yes.

By default, when sshd is proxying a X connection from the X application, it accepts X connections from localhost (= the Linux system in your scenario) only.

The sysadmin can allow other kinds of use by setting the /etc/ssh/sshd_config parameter X11UseLocalhost to "no"; the default setting is "yes". Normal users cannot change this setting.

2.) If there is no requirement to make outgoing connections from your Linux server to ports 6000-6100 of some other server, then go ahead. If such a requirement exists, you should create a more specific rule that allows traffic to the required port of the required server only, and prefix that to the rules I showed before. Since that port is used by whatever legitimate service is running there, there cannot be a rogue X server at the same port on that particular host.

3.) Yes, one X server for one physical keyboard + mouse + screen combination is the rule. (There are exceptions like "multi-headed" X servers, but they are very rare.)

> one user can change the DISPLAY to direct to the other session, such that operation he does will be displayed on the other session screen.

There's also a requirement to pass the xauth key from one user to the other, or to use "xhost +". In my experience, very few users and surprisingly few sysadmins know how to do that.

But remember that you cannot block everything: your users can probably use the PrintScreen button on their workstations to grab screenshots of what they see, then share them by email or by USB memory sticks. Or they might simply talk to each other about what they've seen on their own screens.

If you have two groups of users that *absolutely* must be prevented from communicating with each other, then it might be simpler to just set up two separate servers in separate networks.

Or set up the system so that a regular user can only access the application, not a X11 GUI desktop nor a terminal session. That should cut away most of your "what if the user changes DISPLAY" worries: if the user has no access to a command prompt, much mischief becomes impossible.

For example: set up a small test in /etc/profile that checks the user ID. If the user does not belong to a group that allows command-line access, force-start the application. When the application process stops, end the session.

Something like this in /etc/profile should do it:

if id -nG | grep -q ' cmdline '; then
# user belongs to "cmdline" group
echo "Command line access authorized"
else
# not a member of "cmdline" group:
# force the start of some-X-application,
# end the session when it exits.
some-X-application
exit $?
fi

MK

[dev-s]

Hi,
Tx a gain.
I'm leaving this thread open until I complete my task.
tx,
s