
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.

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
-
Edit ~ttasys/.ssh/known_hosts on the SGD server and remove the offending key
or
-
Change the SSH Arguments to -X -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no
or
-
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
|