SECURING X COMMUNICATIONS WITH SECURE SHELL

Now you've got better access control over your X server, but you still have all of your X data passing in the clear over the network. Even though X traffic is very hard to reconstruct (considering graphics and mouse movements among other things), you might want to add encryption to the equation.

The Secure Shell (SSH) protocol allows for the forwarding of TCP connections through an SSH tunnel. If you have an implementation of a secure shell client that supports X11 forwarding, you can encrypt your X client connections back to the X server.

Let's go back to the HOST1 and HOST2 example from earlier. Assume that the X server is on HOST1, and you want to run X client applications on HOST2 and display them on HOST1. First, both SSH implementations on HOST1 and HOST2 need to be built with X11 forwarding support (they are by default). Next, you'll want to make sure that the SSH server on HOST2 has X11 forwarding enabled and that the SSH client on HOST1 has X11 forwarding enabled. You can check this by looking in the ssh_config and sshd_config files in your SSH configuration directories (location varies with installations but it's typically /etc/ssh). Check for lines that say X11Forwarding or ForwardX11 and set them to "yes" if you want this to work.

Note 

X11 forwarding on SSH servers is usually turned off by default in the sshd_config file. Check this file on the server first when tracking down display problems.

Use the X option for SSH to explicitly request X11 forwarding:

 [HOST1:~] mike% echo $DISPLAY localhost:0.0 [HOST1:~] mike% ssh -X HOST2 mike@HOST2's password: [mike@HOST2 /]$ echo $DISPLAY localhost:10.0 

Wait a minute! The display number is 10 and the display host is localhost (which is now HOST2), but you wanted X applications to display on HOST1. SSH automatically sets the DISPLAY variable when you connect using the X option. The display number 10 on HOST2 is mapped to a local "proxy" X server that tunnels X client traffic through your current SSH connection to the X server on HOST1. Run an application like xclock on HOST2 and you should see a clock pop up on your screen on HOST1. There's also the added benefit that your interaction with xclock is encrypted because it's passing over the SSH connection. Encryption is not terribly necessary for an application like xclock , but it might be more crucial if you were running a remote xemacs application.

Tip 

It's important that you remember not to use the display option with any X commands you run through the SSH tunnel; otherwise , the X clients will not gain the benefit of encryption.

The SSH X11 forwarding even takes care of X authentication. In addition to setting up your display for its "proxy" X server automatically, the SSH client sets up "junk" xauth cookies and sends them to the SSH server. The server, in turn , puts the xauth cookies in your Xauthority file on the remote system, automatically giving you access to your X server. In other words, if you started the X server on HOST1, the SSH client would tell the "proxy" X server on HOST2 to create the following Xauthority entry:

 HOST2:10 MIT-MAGIC-COOKIE-1 121812483b0b3f19367c1541062b472b 

One nice thing about this behavior is that it keeps any real xauth cookies from ever being sent over the network. Only the junk cookie is passed back and forth (and it's even encrypted). Connections that go back through the proxy will map the junk xauth cookie for HOST2:10 to a real xauth cookie for HOST1:0. This mapping takes place on the SSH client side . This allows only the authorized user who started the X server and SSH client on HOST1 to forward X clients back to the X server through the SSH tunnel.

Confused? This can get pretty complicatedso here's a diagram that shows what's going on.

Tip 

SSH is the secure replacement for remote file access (FTP) and remote shell access (telnet). As with any application, it is only a secure replacement as long as you remain vigilant about software updates. SSH provides security by encrypting communication, but it has been just as vulnerable to buffer overflows and remote exploits as its FTP and telnet predecessors.



Anti-Hacker Tool Kit
Anti-Hacker Tool Kit, Third Edition
ISBN: 0072262877
EAN: 2147483647
Year: 2006
Pages: 175

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net