4.6. Using SSH

SGD can use SSH to provide secure connections between SGD servers and application servers. SSH provides the following benefits:

This section includes the following topics:

4.6.1. SSH Support

SGD works with SSH version 2 or later. Because of SSH version compatibility problems, use the same major version of SSH, either version 2 or version 3, on all SGD hosts and application servers.

SGD can automatically detect that SSH is installed on the SGD host if SSH is installed in one of the following directories:

  • /usr/local/bin

  • /usr/bin

  • /usr/sbin

  • /usr/lbin

  • /bin

  • /sbin

If you want to run the SSH client from a different location, or you want to specify particular command-line arguments for the client, see Section 4.6.2, “Configuring the SSH Client” for details.

To connect to an application server using SSH, the following must be true:

  • SSH must be installed on the SGD host and on the application server

  • The application object's Connection Method attribute must be ssh

4.6.2. Configuring the SSH Client

When using SSH with SGD, you can configure the command-line arguments used by the SSH client. The arguments can be configured globally, for individual applications, or a combination of both.

You configure the global options for the SSH client by setting the TTASSHCLIENT environment variable, see Section 4.6.2.1, “How to Set Global SSH Client Options” for details. Use the global SSH client configuration in the following situations:

  • SSH is not installed in one of the default locations

  • To use the same SSH client command-line arguments for all applications

You configure the application options for the SSH client by configuring the SSH Arguments attribute for the application object, see Section 4.6.2.2, “How to Set Application SSH Client Options” for details.

You can combine the global and application SSH client configuration to set the path to the SSH client and set the command-line arguments.

Note

If you do this, any global command-line arguments are ignored.

The following table shows the effect of global and application configuration on the ssh command used.

Global Configuration

Application Configuration

SSH Command Used

[none]

[none]

ssh -l user@host

[none]

-X

ssh -X -l user@host

/usr/ssh -X

[none]

/usr/ssh -X -l user@host

/usr/ssh -X

-p port

/usr/ssh -p port -l user@host

4.6.2.1. How to Set Global SSH Client Options

Ensure that no users are logged in to the SGD server and that there are no running application sessions, including suspended application sessions.

  1. Log on as superuser (root) on the SGD host.

  2. Stop the SGD server.

  3. Set the TTASSHCLIENT environment variable.

    Include the full path to the SSH client program and any required command-line arguments. For example:

    # TTASSHCLIENT="/usr/local/bin/ssh -q -X"; export TTASSHCLIENT
    Note

    If you only want to set command-line arguments for the SSH client, you have to include the full path to the SSH client program, even if the SSH program is in a location where SGD can detect it.

  4. Restart the SGD server.

4.6.2.2. How to Set Application SSH Client Options

  1. In the Administration Console, go the Applications tab and select the application.

  2. Go to the Launch tab.

  3. Ensure that the ssh option is selected for the Connection Method.

  4. In the SSH Arguments field, type the SSH arguments you want to use for the application.

  5. Click Save.

4.6.3. Enabling X11 Forwarding for X Applications

To display X applications using SGD using an SSH connection, you must enable X11 forwarding. See Section 4.6.3.1, “How to Enable X11 Forwarding”.

As a fallback, you can enable the Allow SSH Downgrade (--allowsshdowngrade) attribute on X application objects. If this attribute is enabled and X11 forwarding is not working or not configured, SGD tries to display the application using a regular unsecured X11 connection. Depending on your configuration, users might be prompted to accept the downgrade. The following table shows the effect of enabling the Allow SSH Downgrade attribute.

X11 Forwarding Configured

X11 Forwarding Working

Allow SSH Downgrade Attribute Enabled

What Happens When Users Start the Application

Yes

Yes

Yes

Application starts, SSH connection used

Yes

Yes

No

Application starts, SSH connection used

Yes

No

Yes

User prompted to allow downgrade to X11 connection

Yes

No

No

Application does not start

No

Not applicable

No

Application does not start

No

Not applicable

Yes

Application starts, X11 connection used

If an X11 connection is used, SGD sets the DISPLAY variable and X authorization cookie in the normal way. The SSH connection is only used for application authentication and for starting the application.

4.6.3.1. How to Enable X11 Forwarding

  1. Log in as superuser (root) on the SGD host.

  2. Configure the SSH daemon.

    Edit the sshd_config file and add the following line:

    X11Forwarding yes

  3. Configure the SSH client.

    Do either of the following:

  4. Restart the SSH daemon.

4.6.4. Using SSH and the X Security Extension

SGD supports the X Security extension. The X Security extension only works with versions of SSH that support the -Y option. For OpenSSH, this is version 3.8 or later. You enable the X Security extension by configuring the application objects individual applications as follows:

4.6.4.1. How to Enable the X Security Extension

  1. In the Administration Console, go to the Applications tab and select the application.

  2. Go to the Launch tab.

  3. Ensure that the ssh option is selected for the Connection Method.

  4. Select the X Security Extension check box.

  5. Click Save.

4.6.5. Using SSH and X Authorization

If SSH connections fail when X authorization is enabled, you might have to run the SSH daemon in IPv4-only mode because SGD might not support the X Security extension used on your server. You enable IP version 4 mode by editing your system SSH configuration file.

For example, on Oracle Linux, edit the /etc/ssh/sshd_config file and add the following line:

AddressFamily inet

You must restart the SSH daemon after making this change.

4.6.6. Using Advanced SSH Functions

Certain SSH functionality, such as client keys, requires that the SSH client process runs as a privileged user. However, for security reasons, the SGD server processes and the SSH client process run as a non-privileged user.

To use advanced SSH functions, you must make the SGD ttasshhelper application a setuid root process. You do this by running the following commands as superuser (root) on each SGD server in the array:

# chown root /opt/tarantella/bin/bin/ttasshhelper
# chmod 4510 /opt/tarantella/bin/bin/ttasshhelper
Caution

If you make these changes, you must protect your SGD servers from unauthorized access.

4.6.6.1. Known Limitation With Client Keys

If you are using the SSH client keys functionality, users might be prompted for a user name and password when they start an application. Users are prompted because SGD needs to know the user name to use for the SSH connection. Although users are also prompted for a password, the password is not actually used. Users are only prompted for a user name and password if they do not have an entry in the password cache for the application server, or if the password cache is disabled. If users are prompted, they only need to provide a user name. The password field can be left blank.