Discussions
Categories
- 17.9K All Categories
- 3.4K Industry Applications
- 3.4K Intelligent Advisor
- 75 Insurance
- 537.7K On-Premises Infrastructure
- 138.7K Analytics Software
- 38.6K Application Development Software
- 6.1K Cloud Platform
- 109.6K Database Software
- 17.6K Enterprise Manager
- 8.8K Hardware
- 71.3K Infrastructure Software
- 105.4K Integration
- 41.6K Security Software
Using the SGD Password Cache as a Mechanism for a Trusted Host for SSH Access to 3rd-tier Applicatio
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
sgdserver# tarantella passcache new \
|
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
[email protected]# su - ttasys
|
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
ray12-70# echo > /etc/ssh/authorized_keys <<EOF
|
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