X11 tunneling, ssh and su

It's pretty well known that ssh can be used to tunnel X11 sessions, typically from a server to your local workstation.  This is extremely handy if you need to run an X program on a remote system on which you only have terminal/shell access.  If you're a windows user, I recommend using Putty, and you can enable X11 forwarding very simply.

From the initial putty menu, note the options on the left, and expand the + next to 'SSH', under the 'Connection' category:

On the next page, you should tick the 'Enable X11 forwarding' tick box:

As soon as you log into the server, you should see a message saying that a new authority file has been created:

This has now set a magic cookie (no really) to authorise the server you have just logged into.  If you're wondering what you've just authorised - you've just authorised the server to send X windows back through the ssl session to display on your computer.  Naturally, you need an Xwin server such as Cygwin-X running on your system.

If everything is working correctly, your session should have an environment variable (DISPLAY) set to something very similar to localhost:10.0, and if you run /usr/openwin/bin/xclock, it should appear magically on your desktop:

While all of this is really great and helpful in the extreme, it is covered in many places and isn't new.  What I recently worked out, and want to share, is the solution to the following two problems:


Having logged in to a system, and set up your X11 tunneling, you lose your X11 tunnel if you:


1) su to another user
2) ssh to a new system


Both of these are dead handy things to be able to do.  If you have to assume root privileges, for example, to run the command that generates an X session, you'll hit problem 1.  If you need to switch to a user on a different system, because you don't have a direct connection to that server, you'll hit problem 2.


1 - How to maintain your X11 tunnel while su-ing to a new user


a) log in to your system as described above
b) check your environment DISPLAY variable:


-bash-3.00$ echo $DISPLAY
localhost:10.0


c) Discover what your session magic cookie is:



-bash-3.00$ /usr/openwin/bin/xauth list
hostname/unix:10  MIT-MAGIC-COOKIE-1  fca50d4504788a86d4b680f3eda4628e


d) su to new user:

-bash-3.00$ su -
Password:

e) set your DISPLAY variable:

root@hostname # DISPLAY=localhost:10.0
root@hostname # export DISPLAY

f) set your magic cookie:

-bash-3.00$ /usr/openwin/bin/xauth add hostname/unix:10  MIT-MAGIC-COOKIE-1  fca50d4504788a86d4b680f3eda4628e

Congratulations - you should now be authorised again to send X11 commands to your local machine.

2 - How to maintain your X11 tunnel while ssh-ing to a new system

This is really easy - either of the following ssh commands works.

ssh -o "ForwardX11 yes" username@remotesystem

or

ssh -X -A username@remotesystem

transferring files across firewalls / piping through ssh

Operating System:  All Unix variants

Dependencies/assumptions:  Presence of gzip/gunzip

Problem:   

transferring files across firewalls /

transferring files using ssh tunneling

A problem issue in a tiered, firewalled network architecure, is how to transfer files, especially large files, between servers in different parts of the network.  There are lots of ways to do this - get your friendly network administrator to open up a temporary hole in the firewall, connect up a cable between the two servers, and transfer that way, etc.  Potentially, however, this will break your security procedures, or it might be impossible to get physical access, or your network administrator may not be available, or going through the request process would be too slow, and so on.

It's quite usual, however, for the two networks to be administered via ssh from a third network, or sometimes single ip address.  They cannot speak to each other, but this third location can speak to them both.  So the usual sidestep to the problem is to transfer the file to the third location (which is probably your desktop), then upload it to the new location.  Which is certainly fine for a small file, but when it is many gigabytes (or many hundreds of gigabytes) this may not be feasible, and certainly doubles the transfer time.

So what can be done?  The answer is to use an ssh pipe - transfer the file as a stream from the first server to the desktop, pipe this straight to an ssh connection to its new location.  The script below makes this simple (and also assumes that you'd like to gzip and gunzip the file in the stream, reducing the amount of data to be transferred (though increasing processor load).

#!/bin/ksh



# sshtransfer expects parameters:

# sshtransfer user@server1:file user@server2:file



usage() {

    print "sshtransfer expects user1@server1:file1 user2@server2:file2\n"

    exit 1

    }





testssh() {

    RESULT=failure

    RESULT=`ssh -o Batchmode=yes $1 'echo success'`

    if [[ $RESULT == "success" ]];then

        return 0

    fi

    print "Could not connect to $1 - could be connection or ssh key error.\n"

    return 1

    }



if [[ $# -ne 2 ]];then

    usage

fi



CONNECT1=`echo $1 | awk -F: '{print $1}'`

CONNECT2=`echo $2 | awk -F: '{print $1}'`

FILE1=`echo $1 | awk -F: '{print $2'}`

FILE2=`echo $2 | awk -F: '{print $2'}`



testssh $CONNECT1 && testssh $CONNECT2 && eval ssh -o Batchmode=yes $CONNECT1 \'gzip -c ${FILE1}\' 2\>/dev/null \| ssh -o Batchmode=yes $CONNECT2 \'gunzip \> $FILE2 \' 2>/dev/null



exit 0

add ssh key pair for ssh logins without password authentication

If you're trying to write a script that needs to log in to a number of remote servers, and are trying to avoid typing in passwords (or hard-coding passwords in an expect script, or similar) - this could be a lifesaver.

Create a key:

$ ssh-keygen -t dsa -f ~/.ssh/id_dsa -C "you@example.com"
Generating DSA keys: Key generation complete.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in ~/.ssh/id_dsa
Your public key is:
1024 35 [really long string] you@example.com
Your public key has been saved in ~/.ssh/id_dsa.pub

For some versions of ssh-keygen, you'll need to specify ssh-keygen -d

The -C is an optional comment.

Create a list of servers you want to be able to log into freely and save it to a file called serverlist.  Then you'll be able to run the fragment:

for server in `grep -v "^ *#" serverlist`;do
  echo $server
  cat ~/.ssh/id_dsa.pub | ssh username@$server 'cat - >> ~/.ssh/authorized_keys'
done

You may need to create the directory .ssh on the target server.


Now you should be able to ssh to the servers listed without being prompted for a password.