VanDyke Software

Tips

Index

Configuring X11 Forwarding in SecureCRT

SecureCRT supports X11 forwarding, which allows SecureCRT and an SSH2 server to secure X11 traffic so that an X11 client process running on the remote SSH2 server machine can be displayed locally.

Requirements
SecureCRT does not currently include an X11 server product. In order for X11 traffic to be displayed locally on your SecureCRT machine you must already have an X11 server product installed and running ("xming", for example).

Overview

Graphic showing an overview of X11 forwarding in SecureCRT

When properly configured, SecureCRT enables X11 forwarding by making a special "X11 forwarding request" to the SSH2 server just after successful authentication has been completed. If allowed by the SSH2 server, the SSH2 server will perform two actions:

  • The SSH2 server begins listening on a local loopback address and port dynamically calculated and assigned to this specific SSH2 connection. SSH2 servers typically determine/calculate this port based on the following conventional formula:
  • 6000 + 10 + x (where x is the 0-based current accumulation of X11 forwarding requests being serviced by the SSH2 server)

  • The SSH2 server also configures a unique DISPLAY environment variable (for that specific SSH2 connection only) matching the dynamically determined port on which the server is now listening for incoming X11 client connections. For example, an SSH2 server that decided to listen on port 6010 for the current SSH2 client will set the DISPLAY environment variable to localhost:10.0 (The 10 coming from port 6010).

When SecureCRT is configured with the Forward X11 packets option enabled, individuals SHOULD NOT manually set the remote shell’s DISPLAY environment variable. As described earlier, the DISPLAY environment variable will automatically be defined by the remote SSH server for that specific SSH client-to-server connection.

When an X client process is executed on the remote side through the shell connection you already have established with SecureCRT, the X11 client automatically connects to the correct DISPLAY, and X11 traffic will be forwarded through the encrypted SSH transport to the X11 server application running on the SecureCRT machine.

Configuration
To configure SecureCRT to perform X11 forwarding, simply open Session Options, and in the Connection / Port Forwarding / Remote/X11 category, enable the Forward X11 packets option.

Screenshot showing settings to enable X11 packet forwarding in the Session Options dialog

The SSH2 server must also be configured to allow X11 forwarding to occur; otherwise, SecureCRT’s X11 forwarding request will fail. Such failures are visible within SecureCRT’s Trace Options output (select File / Trace Options prior to attempting your connection). (For detailed instructions on how to use Trace Options, see the video, Trace Options Debug Logging in SecureCRT).

Customization

Display Number

X11 server applications typically listen on TCP port 6000 by default, which is equivalent to "display number 0". Some X11 server applications may be configured with a display number that is higher than zero. If the X11 server is configured as display 40, for example, it means the X11 server application is listening on port 6040; you would need to configure SecureCRT’s Display value to reflect 127.0.0.1:40.0.

Screenshot showing SecureCRT's Session Options / X11 Forwarding Display value set to 127.0.0.1:40.0

X11 Authentication

By default, SecureCRT enforces X11 authentication to prevent unauthorized users from being able to display X client applications on an X server that does not belong to them. This security feature may impact your ability to display X client applications after switching user contexts within the remote shell to which you are connected with SecureCRT.

For example, if you su root, X client apps launched as "root" cannot be displayed within the X server application running on the SecureCRT machine because the "root" user won’t have the same X11 authentication credentials to access the display.

If you require access to the local X11 server display for multiple accounts, the first approach would be to copy the .Xauthority file from the home directory of your non-root remote user account (the account you used for authentication to the SSH2 server) to the home directory of the root user account.

If copying the .Xauthority file isn’t possible or desired, the Enforce X11 authentication option can be disabled to allow unauthenticated X11 traffic.

VanDyke Software uses cookies to give you the best online experience. Before continuing to use this site, please confirm that you agree to our use of cookies. Please see our Cookie Usage for details.