Overview

When launching an application via SSH to a Unix based 3rd-tier server, the SGD server initiates a SSH connection and the unix.exp script listens for the ssh authentication dialog (username, password). If the SGD Password Cache, or passcache is enabled and an entry pair for the SGD identity and the Application Server exists, SGD will provide the credentials, otherwise the dialog for the end user to authenticate to the app server with user name password, or in SGD >=5.4 with a ssh private key, pops up.

Use a username / password Password Cache

In the case of multiple users trying to launch an application on an Application Server, it might be prohibitive to add every users public key on the Application Server. In the following examples the SGD infrastructure uses Active Directory as authentication mechanism.

When a user authenticates to SGD, the internal identity is something like this (example is my own account)

.../_service/sco/tta/ldapcache/CN=Jan Hendrik Mangold,CN=Users,DC=demopod,DC=com

which can be used with the tarantella command to create a passcache entry. Let's say I wanted to provide a passcache entry for the 3rd-tier system know to SGD as

.../_ens/o=appservers/cn=Tarantella server ray12-70

I can use the following command

tarantella passcache

|

sgdserver``# tarantella passcache new \

`--person` `".../_service/sco/tta/ldapcache/CN=Jan Hendrik Mangold,CN=Users,DC=demopod,DC=com"` `\`

`--resource` `".../_ens/o=appservers/cn=Tarantella server ray12-70"` `\`

`--``type` `Standard \`

`--resuser unix-login \`

`--respass unix-password`

sgdserver``# tarantella passcache list \

`--person` `".../_service/sco/tta/ldapcache/CN=Jan Hendrik Mangold,CN=Users,DC=demopod,DC=com"` `\`

`--resource` `".../_ens/o=appservers/cn=Tarantella server ray12-70"`

Person: ...``/_service/sco/tta/ldapcache/CN``=Jan Hendrik Mangold,CN=Users,DC=demopod,DC=com

Resource: ...``/_ens/o``=appservers``/cn``=Tarantella server ray12-70

Scope:

Type: Standard

User: unix-login

sgdserver``#

|

When trying to launch an Application on Tarantella server ray12-70, SGD will now use that passcache entry and authenticate with unix-login and unix-password to launch the application.

Backdraw

This approach requires the SGD administrator to know the credentials for every user, which again might not be feasible.

Use SSH private key via Password Cache

Alternatively a SSH private key can be used for the authentication. The ssh connection to the 3rd-tier system is initiated from the SGD server as user ttasys, so by providing a ssh key in ~ttasys/.ssh and making sure that the 3rd-tier server knows about that key, authentication can happen without the use of a unix password.

In the following example we change to the ttasys user and create a SSH private key. We then add a Password Cache entry for a User Profile

ttasys ssh-keygen

|

root@sgdserver``# su - ttasys

ttasys@sgdserver$ ssh``-keygen -t rsa

Generating public``/private rsa key pair.

Enter file in which to save the key (``/home/ttasys/``.``ssh``/id_rsa``):

Enter passphrase (empty for no passphrase): test123

Enter same passphrase again: test123

Your identification has been saved in /home/ttasys/``.``ssh``/id_rsa``.

Your public key has been saved in /home/ttasys/``.``ssh``/id_rsa``.pub.

The key fingerprint is:

d2:73:23:bf:6f:47:70:05:b8:fb:99:69:ff:c2:85:a0 [ttasys@sray21-113.us.oracle.com](mailto:ttasys@sray21-113.us.oracle.com)

ttasys@sgdserver$ cat /home/ttasys/``.``ssh``/id_rsa``.pub

ssh``-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAunHPPZbjuVc+1yKfcggnFr0KBHJEYDx5K94xfjdTYLZUptCskTWsNsfmZTh1wLHmq73a0ru9hXV2WIbbEK+SxldYb62DTyRSaObcqX+b86HOnAq1HzHBsZMLIC1cC0IYdyRD4g5BdUy7UNtLI``/sdfR4DENJFnJpz8Kuo5udTVdE``= ttasys@ray12-70

ttasys@sgdserver$ exit

root@sgdserver``# tarantella passcache edit \

`--person` `".../_service/sco/tta/ldapcache/CN=Jan Hendrik Mangold,CN=Users,DC=demopod,DC=com"` `\`

`--resource` `".../_ens/o=appservers/cn=Tarantella server ray12-70"` `\`

`--``type` `Standard \`

`--resuser unix_user_on_ray12-70 \`

`--respass test123`

root@sgdserver``#

|

On the receiving Application Server we need to make sure that the sshd knows about our ssh key. This can be accomplished in two different ways. Either the public part of the key is added to .ssh/authorized_keys of every user that needs to authenticate to the 3rd-tier server, or sshd_config on that server can be changed to use a global authorized_keys file by adding the following line to the sshd_config and restarting the ssh daemon

In this example we choose the second approach and add the public key of our ttasys user to a system global authorized_keys file

**/etc/ssh/sshd_config on Application Server
**

|

ray12-70``# echo > /etc/ssh/authorized_keys <<EOF

ssh``-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAunHPPZbjuVc+1yKfcggnFr0KBHJEYDx5K94xfjdTYLZUptCskTWsNsfmZTh1wLHmq73a0ru9hXV2WIbbEK+SxldYb62DTyRSaObcqX+b86HOnAq1HzHBsZMLIC1cC0IYdyRD4g5BdUy7UNtLI``/sdfR4DENJFnJpz8Kuo5udTVdE``= ttasys@ray12-70

EOF

ray12-70``# echo "AuthorizedKeysFile2 /etc/ssh/authorized_keys" >> /etc/ssh/sshd_config

ray12-70``# # restart ssh (svcadm refresh ssh for Solaris; systemctl reload sshd on OL7)

|

The /etc/ssh/sshd_config does not support multiple files specified for AuthorizedKeys directive, but there is directive AuthorizedKeysFile2. On Linux a workaround that can be used is a wrapper script in AuthorizedKeysCommand, that can internally read as much files as needed.

Now any User Profile authorized for an Application that uses Application Server o=appservers/cn=Tarantella server ray12-70 will be able to launch the Application as user unix_user_on_ray12-70

This approach potentially allows a user to login to the 3rd-tier system as someone else, if the ssh private key is generated without a passcode, or if the passcode is communicated to all users