Forum Stats

  • 3,827,877 Users
  • 2,260,836 Discussions
  • 7,897,402 Comments

Discussions

SGD SSH to Unix Application Servers Explained

Jan-Oracle
Jan-Oracle Member Posts: 122 Employee
edited Feb 21, 2019 6:23PM in Secure Global Desktop

image

Standard SSH parameters

Oracle Secure Global Desktop (SGD) uses SSH with X11Forwarding when connecting to Unix based application servers. Standard sshd_config settings of Unix should work out of the box, but if you encounter problems, please make sure that the application server contains the following configuration settings

/etc/ssh/sshd_config of application server

AddressFamily inet

X11Forwarding yes

SSH connection with Password Authentication

Usually sshd is configured to allow PasswordAuthentication as well as PublicKey authentication. SGD supports both authentication methods. For enhanced security, instances provisioned in Oracle Cloud Infrastructure (OCI) only allow PublicKey authentication.

For SGD to access those application servers every user would have to own a private key to the public key added to the users $HOME/.ssh/authorized_keys file. Sometimes it might be more convenient to allow SGD to authenticate to those instances with a regular username/password combination.

To enable restricted Password Authentication, the sshd_config on the application server needs to be changed to allow the SGD server to authenticate via password as well. In the example below I added a directive to allow password authentication from within my Virtual Cloud Network (VCN) and from localhost. These addresses can be adjusted to your particular environment, or the specific address(es) of your SGD server(s)

/etc/ssh/sshd_config of application server

# adjust address and CIDR based on your network

Match Address 10.0.0.0/8,127.0.0.1,::1

        PasswordAuthentication yes

SGD SSH connection failure

When launching an application on a Unix application server, SGD (usually)  establishes the SSH connection to that host to run the specified command for the application. That SSH process runs as user ttasys on the SGD server (or array member chosen to run the application). By default ssh stores the host key in $HOME/.ssh/know_hosts, in this case ~ttasys/.ssh/know_hosts.

pastedImage_2.png

Connection Failure Explanation and Solution

When an application server is re-installed or otherwise changes, ie. a different server responds to the same hostname or IP address, the SSH connection fails because the stored SSH host key no longer matches with what is stored in ~ttasys/.ssh/known_hosts and the application launch fails and the end user sees the following message

There are three ways to remedy this

  1. Edit ~ttasys/.ssh/known_hosts on the SGD server and remove the offending key
    or
  2. Change the SSH Arguments to -X -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no
    or
  3. Edit /etc/ssh/ssh_config on the SGD server and add the following configuration (in this example I added the IP network my VNC in OCI, this can be adjusted/limited to specific application servers)

    /etc/ssh/ssh_config of SGD server

    Host 10.0.0.*

      StrictHostKeyChecking no

      UserKnownHostsFile /dev/null

    </code></li></ol><p class="number3 index2 alt2 line" style="padding: 0 1em 0 0; text-align: left; font-family: Consolas, 'Bitstream Vera Sans Mono', 'Courier New', Courier, monospace; font-weight: normal; font-style: normal; font-size: 14px; color: #333333; text-indent: 0px; background-position: 0px center;"><code class="spaces bash" style="font-family: Consolas, 'Bitstream Vera Sans Mono', 'Courier New', Courier, monospace; text-align: left; font-weight: normal; font-style: normal; font-size: 14px; background-position: 0px center;">    <br/>