Cygwin SecureX Setup Documentation
Note, this documentation is a work in progress. Please see the final "More?" heading for where feedback and general suggestions for improvement can be
Introducing Secure X
Securex is a set of Cygwin scripts that allow for an easy way to configure
preset X desktops that utilize secure principals. It depends upon Cygwins'
port of X.org's X server, OpenSSH, a shell (PDKSH) and related utilities
that are easily installed on a Windows system. It is free software
(covered under the GNU GPL) and is freely distributable. It can be obtained
(see the file release section of:
Secure X is meant to be a minimalist design for setting up Xwindow desktops on
Microsoft Windows. It is
intended as an alternative to
commercial X server products that often have a multitude
of features that the regular user simply doesn't need. Typical Windows users
simply need an X graphics server for daily productivity chores. Things like
file transfer over secure shell and windows file system interoperability are
often clunky afterthoughts in some products -- not so with Cygwin. This is
because after installation of shells, an X server and OpenSSH, the local
system behaves much the same way as the remote Unix/Linux system.
This familiarity aids the long-term usage of Cygwin and solves a glaring
problem with security that many commercial products open by default when they
install. Users are not familiar with these insecure technicalities, and they
often configure their X desktop products to simply turn of security as a
All of the packages below
are available using the setup.exe from
SecureX requires these packages. Although trimming some sub-selections from
these packages may be possible, this document only covers the general
- X11 : The X.org X server and related utilities.
- Editors : This will give you a command-line based editor.
- Net: This will give you a port of OpenSSH to Cygwin -- secure shell.
- Base: Some basic shell utilities that are used by securex.
- Utils: RPM and some other stuff.
- Shell: Bash, KSH and rxvt are under this heading.
Installing the software
The software is installed with the Cygwin RPM command. First download the
latest secureX RPM from sourceforge.net -- it's available by following the
link to the stable version, mentioned on this page:
If your Cygwin installation does not include the ability to install RPMs,
you should either update it to include this functionality, or alternatively,
you may download the source tarball, and unpack it into any suitable
temporary location (the example below shows this location as "/tmp"):
# tar xvfz securex-X.X.X.tar.gz
[ unpacking messages]
# cd securex-X.X.X
Substitute the downloaded version numbers for the X's above.
After installation, you may remove the directory and tarball from wherever
you downloaded and unpacked them -- they are no longer needed.
SecureX installs under /opt/fericyde/securex, and it creates a stub wrapper
file /usr/bin/securex which makes it available to all users. SecureX is
Free Software, covered under the GNU General Public License (GPL) -- please
feel free to send suggestions or alternatively, patches or examples of
specific configurations. The example .securex.ini file contains several
examples that were discovered using different SSH connections to various
operating systems. Please share -- it will help improve the setup of the
program. Eventually, these combinations will be easily accessible from the
documentation links at the sourceforge site.
Once the software has been installed properly, Cygwin users should run the
securex program from a bash terminal window. If the securex program does not
start an interactive command-line session to create the default .securex.ini
(and related .xinitrc file), something has gone amiss and the installation
files should be verified -- or the PATH variable examined to see if it is
The securex install will replace the users .xinitrc file. This is merely
a duplicate of the file securex.xinitrc found under the install directory.
It will also create a default .securex.ini file, which has a rather simplistic
"ini"-like syntax. See the examples section for common configurations.
Users can run multiple X-window graphics sessions, provided that the display
offsets do not collide. For example, it's possible to have a connection to
an AIX box on :0, another one to a Linux box on :1 and a VMware session
connected to :2 -- or any similar combination. The program simply sets these
variables according to the .securex.ini startup file.
Here is an example startup that connects to a SuSE 9 Linux box on display
offset 7, using XFce:
# Suse SLES 9.1 FeriCyde
The following shows the startup of this session from a Cygwin BASH prompt:
$ securex fericyde
The script takes care of the settings as needed, in other words.
Configuring Windows Short-cut Icons
this configuration, a tool-bar icon is created that has the following properties
with an appropriate icon:
C:\cygwin\bin\pdksh.exe -ls -c "securex fericyde"
- Start in:
- Shortcut key:
FeriCyde Xwindow Session
Note that the above example uses PDKSH instead of bash. Likely bash.exe
could be substituted for the call with the same or similar parameters.
- (next to icon):
SuSE 9 FeriCyde
Multiple, similar tool-bar short-cuts like the above can be created to easily
connect to different X sessions.
Considerations (display, disk space, user id configuration, etc)
Securex does not take a lot of disk space on a typical Cygwin installation.
the packages needed are (in todays terms) relatively small, freely available
and for the most part stable. Users will need to create their own
configurations, and that might be the most daunting part of a large-scale
roll-out. Since the default .securex.ini file can contain variables for
the username, the primary distributed rpm or even the Cygwin image can
be altered to include this in enterprise distributions.
Appendix: Common platform window manager configurations.
Appendix: Getting on-line help and troubleshooting
General questions about SecureX should be placed in the
forum for the BatchLogin project. Care should be taken not to ask
questions that have already been answered for someone else.
SecureX connections is as simple as manually attempting the steps with a
bare X session. To do this, use the Cygwin xinit command to open a
session with no window manager. Secure shell to the relevant server,
and type the window manager startup command that is being specified in the
.securex.ini file. Simple syntax errors are often the culprit for failed
session startup. Other typical problems are:
Once a session is up and working, the automation typically works reliably,
however. The above problems are obscure but potential problems in getting to
this working configuration. In larger environments, a trouble-shooting guide
using the above issues as a template could easily be created to address
these common shortcomings.
- The Wrong window manager call-out; Is KDE being started with the right
command on that Linux box? Is it even installed there?
- A different operating system; It's an AIX box with a Linux window
manager call-out. Not going to work. A lot of proprietary and legacy
Unix systems have convoluted or obscure Xwindow startup sequences. You may
have to roll your own startup script and place that in the home directory
of the system being accessed in order to make it all work.
- Failed login accounts; If the user cannot log in via secure shell,
SecureX is not going to work.
- No Secure Shell; SecureX does not work over telnet.
- Missing Cygwin components; No secure shell? No PDKSH? No X.org
server? You need to ensure that all of the proper components are installed
or the program is not going to run.
- Conflicting X display offsets; If another session is already running,
the current session is going to fail -- and likely break the working session
in the process. Simply make sure that there are different "xdisplay"
settings in the .securex.ini file.
Suggestions for improvement or added features? Use the
BatchLogin discussion forum to open a new thread with a topic of "suggested feature".
If you have code to contribute, contact the author. Please include SecureX in the subject line and
the code as an attachment, if possible.