Terms and Conditions

Some brief instructions on X11 forwarding/tunneling using SSH, PuTTY & Xming. These instructions also cover the commands required to forward X11 after you su to another user. I encountered a small but irritating issue launching the Oracle Universal Installer (OUI) when the E-Business Suite Applications Tier environment was set, so that solution is here too. Two methods are covered.

  1. Using a direct X11 connection (Port 5900)
  2. Tunneling the connection over SSH for that added bit of security and cutting down on the firewall ports you need to have opened.

Steps Required For Both Methods

For this you'll need PuTTY & Xming running on your own computer. Check Out the instructions on configuring Xming Here.

On the server you intend to connect to you'll need to enable X11 Forwarding in /etc/ssh/sshd_config
 $ vi  /etc/ssh/sshd_config

Then find X11Forwarding and change it to X11Forwarding yes. File will look something like:

Port 22
PermitRootLogin no
IgnoreRhosts yes
#X11Forwarding no
X11Forwarding yes # lowercase yes is important 
PasswordAuthentication yes
PermitEmptyPasswords no

You will need to restart the SSHD service on the server once you have made this change. Existing SSH connections will not be affected but new connections will not be possible while the restart is underway. Something like this:

$ stopsrc -s sshd;startsrc -s sshd  # AIX
$ sudo /etc/init.d/sshd restart # Linux 

Open PuTTY and load, but do not launch, the session you wish to use X11 with. In the left hand menu navigate to SSH -> X11.

Tick the Enable X11 forwarding box and add localhost:0 to the X display location.


You should save that to your session for future use. No harm will be done to a session if it is left enabled.  If you do not save the session, X11 forwarding must be turned on in Putty Configuration for each required session in the future.

Putty is then launched and used as normal.

1. Direct X11 forwarding

You will need communication to be available on port 5900 from the server to the computer you are sitting at.

Once Logged into Server execute following command. Where the IP Address is the IP address of the Machine you are sitting at. The :0.0 at the end is required. basically it means use display zero.

 $ export DISPLAY= 

The Quickest and Easiest way to test for a X11 connection is to enter:

 $ xclock & 


xclock example

Once you see the xclock appear you know you have done it correctly. Congrats.

If the xclock command hangs briefly then errors out you probably have a firewall issue, if the command fails instantly with:

 Error: Can't open display: 

Then you have missed a step and should confirm the steps again.

2. X11 Tunneling with SSH

The Direct X11 forwarding instructions are really only there for the sake of it. This is the method you should use.

As mentioned in "Steps Required For Both Methods" if you do not save your PuTTY session configuration before opening PuTTY and connecting to the server, the next time you go to use PuTTY with X11 the new settings will obviously not have been saved.

When you connect to the server with PuTTY if you echo $DISPLAY you should get the value localhost:10:0 if you do not get a similiar value then you may have not set X11Forwarding to yes in your sshd_config or you may be setting a different DISPLAY value in your .profile. You can issue the below command to force set your DISPLAY, if you wish, but check for a configuration issue first.

 $ export DISPLAY=localhost:10:0 

Once that is done you should be able to launch xclock and test that it works.

 $ xclock & 

To be fair that is quite straightforward, but if you su to another user and try and do xclock it will not work. The reason it will not work is because when you originally connected to the server a MIT-Magic-Cookie got set. When you su to another user that setting is not passed to the second account. Thankfully it is possible to set that variable manually after you su the new account.

In order to pass the magic cookie to the su session you need to know what the cookie is. The xauth command can list all cookies you have available to you and can be used to add cookies also. When you su to the other account you simply add the cookie and export the display variable again.

$ xauth list 
  oradev/unix:10  MIT-MAGIC-COOKIE-1  1f955959328c36d0b8312c6d8ae85185  
$ echo $DISPLAY  
$ su - otheruser  
$ xauth add oradev/unix:10  MIT-MAGIC-COOKIE-1  1f955959328c36d0b8312c6d8ae85185  
$ export DISPLAY=localhost:10.0 
$ xclock &

Again, quite straight forward now that you know.

This cookie setting is held for as long as you keep that PuTTY terminal open. Without closing the PuTTY terminal you can su to any number of other user accounts, exit back to your own and within any account that you have used "xauth add" to share the magic cookie you will still be able to launch xclock.

Everytime you open a new terminal you will again have to "xauth add" the newly generated magic cookie to accounts you wish to su to.

Now you get to learn why I have Oracle E-Business Suite in the title.

When I tried to use "xauth add" with Oracle 11i E-Business Suite I got a whole heap of errors:

$ xauth list
  oradev/unix:10  MIT-MAGIC-COOKIE-1  1f955959328c36d0b8312c6d8ae85185
$ echo $DISPLAY
$ su - oracleuser
$ export DISPLAY=localhost:10.0
$ xauth add oradev/unix:10  MIT-MAGIC-COOKIE-1  1f955959328c36d0b8312c6d8ae85185
exec(): 0509-036 Cannot load program xauth because of the following errors:
        0509-130 Symbol resolution failed for xauth because:
        0509-136   Symbol XSecurityGenerateAuthorization (number 65) is not exported from
                   dependent module /u01/oracle/RED/redora/8.0.6/network/jre11/lib/aix/native_threads/libXext.a(shr.o).
        0509-136   Symbol XSecurityFreeXauth (number 66) is not exported from
                   dependent module /u01/oracle/RED/redora/8.0.6/network/jre11/lib/aix/native_threads/libXext.a(shr.o).
        0509-136   Symbol XSecurityAllocXauth (number 67) is not exported from
                   dependent module /u01/oracle/RED/redora/8.0.6/network/jre11/lib/aix/native_threads/libXext.a(shr.o).
        0509-136   Symbol XSecurityQueryExtension (number 68) is not exported from
                   dependent module /u01/oracle/RED/redora/8.0.6/network/jre11/lib/aix/native_threads/libXext.a(shr.o).
        0509-192 Examine .loader section symbols with the
                 'dump -Tv' command.
$ xclock &
[1]     4309114
Xlib: connection to "localhost:10.0" refused by server
Xlib: PuTTY X11 proxy: MIT-MAGIC-COOKIE-1 data did not match
Error: Can't open display: localhost:10.0

This is because the oracleuser account that I use with Oracle E-Business Suite sets up the application environment in the .profile automagically for me. The .profile executes APPSORA.env. One of the variables that is set with the APPSORA.env causes a conflict for xauth. Why this happens I do not know. Once I figured out the workaround I gave up looking for the reason to be honest.

You can comment out that line from the .profile and try again or you can set the database environment settings instead before doing xauth add.

$ xauth list
  oradev/unix:10  MIT-MAGIC-COOKIE-1  1f955959328c36d0b8312c6d8ae85185
$ echo $DISPLAY
$ su - oracleuser
$ dbhome # Alias that sets the database environment file
$ xauth add oradev/unix:10  MIT-MAGIC-COOKIE-1  1f955959328c36d0b8312c6d8ae85185 
$ export DISPLAY=localhost:10.0 
$ xclock &

If you wish to launch the OUI for the application tier you can exit back to your own user account and su to the oracleuser again because as stated above one you set your magic cookie it stays set for your PuTTY session or you just set the applications environment file manually. Once done you can cd to the required location and runinstaller as normal.

Any Tips, Tricks, Questions or Suggestions please use the comment form below.

I hope this was of benefit to you.