10 Jul 2008 10:02 AM EDT

Disclaimer

It is the responsibility of the sysadmin to take into consideration the security implications of performing the steps outlined in this article. Knowledgeable readers are invited to provide additional insight, corrections, or suggestions in their comments.

Motivation

Up until recently, the XenApp Unix Admin Guide suggested that the rsh command be used when publishing applications that needed to connect to yet another machine to provide the application. The typical use case for this was when administrators would like to publish an application on a platform that the XenApp Unix server product does not run on (e.g. Linux, FreeBSD, etc.). Due to the lack of security provided by the rsh facility, it is recommended that users use the ssh command instead. This article is meant to act as a tutorial for sysadmins who need to do this and would like a single place to go for a reference.

This update was inspired by an astute response to a previous blog article. 

Setting Up Host Based Authentication

This step is only necessary if your requirements are that users should not re-authenticate when a connection is made from the XAU server to the host providing the application (henceforth the apphost)

When your XAU server's Public Host Keyis placed in the appropriate location on the apphost, the SSH server daemon assumes that any incoming users have been properly authenticated and will not reauthenticate. However, if the incoming userid does not exist on the apphost, access will not be granted.

Configuring the XAU Server machine

  1. As root, using ssh-keygen, create a private key file at /etc/ssh/ssh_host_rsa_key
    Quite often, this is done at OS installation time, and this step is unnecessary.
  2. Make sure that file is only readable by root
  3. Copy the file /etc/ssh/ssh_host_rsa_key.pub to a secure location on the apphost.
  4. Set the ssh client binary to setuid root on the XAU Server.
  5. Find ssh-keysign on your machine, and make sure that it is setuid root .
  6. In /etc/ssh/ssh_config, set HostbasedAuthentication to yes .

Configuring the Apphost

  1. In /etc/ssh/sshd_config on the apphost, set the config option HostbasedAuthentication to yes
    (for Sun's sshd, you might need to add this directive)
  2. in the file ssh_host_rsa_key.pub that you just copied over, add the canonical hostname of the XAU Server machine to the beginning of the first (and what should be the only) line in the file, followed by a space. e.g.
    potato.citrix.com ssh-rsa AAAAB3N.../CIMtw==
    Then append ssh_host_rsa_key.pub to /etc/ssh/ssh_known_hosts
  3. Append the line
    +<hostname>
    to the file /etc/ssh/shosts.equiv where <hostname> is the canonical hostname of the XAU Server machine.
  1. Tell the sshd process to reread its configuration file.
    cat /var/run/sshd.pid | xargs kill -HUP
  2. Finally, ensure that any users on the XAU Server that you would like to allow access on the apphost have entries in /etc/passwd on the apphost.

Publishing the remote application

The steps in this section are outlined in the admin guide, but some examples of the contents of the published scripts will be provided for concreteness.

Publishing vi in text mode on the remote machine lettuce.citrix.com

#!/bin/bash
xterm -e ssh -t lettuce.citrix.com vi

Publishing emacs in graphical mode on the remote machine tomato.citrix.com:

#!/bin/bash
ssh -X tomato.citrix.com emacs

References

  • the sshd manpage
  • the ssh manpage
  • the sshd_config manpage
  • the ssh_config manpage
  • the ssh-keygen manpage
Permalink | Comments (1) |

Kudos on a good article and for listening to user comments!  For the curious we have been using ssh hostbased authentication for several years now with Solaris SPARC Red Hat (Linux), and AIX as app hosts and Solaris SPARC as the Citrix server.

I actually also had to make ssh setuid root in addtion to ssh-keysign but maybe this does not apply anymore.

And here's a more complicated story..... 

One time we ran into hostname and reverse lookup mismatch errors. I *think* this was because sshd was using just DNS while ssh was honoring nsswitch.conf (which in our case was files first and then DNS). The Citrix server in question was multi-homed which means that in Solaris each interface gets a different name in /etc/hosts -- e.g. animerules and animerules-svr2svr. Using the example names, I had to put animerules as the first entry for each IP address in /etc/hosts to get ssh working. So I had something like the following even though SUN recommends against it (I also had to edit the Sun Ray utadm command to account for this):

127.0.0.1       localhost
192.168.1.11    animerules  animerules-pvtnet loghost
192.168.2.11    animerules  animerules-user
192.168.3.11    animerules  animerules-svr2svr

A lesson to take from this is that if you are having ssh auth issues one place to look is for hostname mistmatches reverese-lookup issues, and routing issues (e.g. if the ssh packets go out one interface but come in on a different one). Actually, you can apply this to several other protocols as well.

Anyway, again, good article! Now, can we get a Linux version of XenApp Server?!

Posted by Russ LeBar at Jul 16, 2008 16:50Updated by Russ LeBar | Reply To This