Forum Stats

  • 3,836,657 Users
  • 2,262,164 Discussions
  • 7,900,066 Comments

Discussions

Using the SGD Password Cache as a Mechanism for a Trusted Host for SSH Access to 3rd-tier Applicatio

Julie Wong-Oracle
Julie Wong-Oracle Posts: 49 Employee
edited Feb 21, 2019 7:55PM in Secure Global Desktop

image

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.

pastedImage_0.png

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<span class="Apple-converted-space"> </span>".../_service/sco/tta/ldapcache/CN=Jan Hendrik Mangold,CN=Users,DC=demopod,DC=com" \

    --resource<span class="Apple-converted-space"> </span>".../_ens/o=appservers/cn=Tarantella server ray12-70" \

    --type Standard \

    --resuser unix-login \

    --respass unix-password

sgdserver# tarantella passcache list \

    --person<span class="Apple-converted-space"> </span>".../_service/sco/tta/ldapcache/CN=Jan Hendrik Mangold,CN=Users,DC=demopod,DC=com" \

    --resource<span class="Apple-converted-space"> </span>".../_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:<span class="Apple-converted-space"> </span>

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
[email protected]# su - ttasys

[email protected]$ ssh-keygen -t rsa

Generating public/private rsa key pair.

Enter<span class="Apple-converted-space"> </span>file in which to save the key (/home/ttasys/.ssh/id_rsa):<span class="Apple-converted-space"> </span>

Enter passphrase (empty<span class="Apple-converted-space"> </span>for no passphrase): test123

Enter same passphrase again: test123

Your identification has been saved<span class="Apple-converted-space"> </span>in /home/ttasys/.ssh/id_rsa.

Your public key has been saved<span class="Apple-converted-space"> </span>in /home/ttasys/.ssh/id_rsa.pub.

The key fingerprint is:

<span>d2:73:23:bf:6f:47:70:05:b8:fb:99:69:ff:c2:85:a0 </span><a class="jive-link-email-small" href="mailto:[email protected]">[email protected]</a>

[email protected]$<span class="Apple-converted-space"> </span>cat /home/ttasys/.ssh/id_rsa.pub

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAunHPPZbjuVc+1yKfcggnFr0KBHJEYDx5K94xfjdTYLZUptCskTWsNsfmZTh1wLHmq73a0ru9hXV2WIbbEK+SxldYb62DTyRSaObcqX+b86HOnAq1HzHBsZMLIC1cC0IYdyRD4g5BdUy7UNtLI/sdfR4DENJFnJpz8Kuo5udTVdE= [email protected]

[email protected]$<span class="Apple-converted-space"> </span>exit

[email protected]# tarantella passcache edit \

    --person<span class="Apple-converted-space"> </span>".../_service/sco/tta/ldapcache/CN=Jan Hendrik Mangold,CN=Users,DC=demopod,DC=com" \

    --resource<span class="Apple-converted-space"> </span>".../_ens/o=appservers/cn=Tarantella server ray12-70" \

    --type Standard \

    --resuser unix_user_on_ray12-70 \

    --respass test123

[email protected]#

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= [email protected]

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