Certificate Authentication and Reflection for Secure IT UNIX Client 7.1 or Higher

  • 7022083
  • 16-Jul-2009
  • 02-Mar-2018

Environment

Reflection for Secure IT UNIX Client version 7.1 or higher
Reflection for Secure IT UNIX Server version 7.1 or higher
Reflection for Secure IT Windows Server version 7.1 or higher

Situation

You can use digital certificates to establish secure connections with Public Key Infrastructure (PKI). This technical note outlines how to generate a certificate request using the ssh-certtool utility, obtain a signed certificate from a Certificate Authority (CA), import it to the Reflection for Secure IT UNIX client, and properly configure the client to use certificate authentication.

Resolution

Overview of Certificates for Client Authentication

Rather than using public keys to authenticate your session, you can use certificates that authenticate the client during the Diffie-Hellman key exchange:

  1. The client sends the User Certificate (which includes the user public key) to the server.
  2. Using the Certificate Authority’s (CA) root certificate, the server verifies that the User Certificate is valid.
  3. The server contacts the PKI Services Manager to verify the user’s certificate.

Overview of Configuration Steps

Configuring Reflection for Secure IT UNIX Client for certificate authentication is a multi-step process:

  1. Generate a certificate request using the ssh-certtool utility and send it to a Certificate Authority (CA). The CA sends you your signed certificate and their Trusted Root CA Certificate.
  2. Configure the client to store and use certificates.
  3. Configure Certificate User Authorization on the Reflection for Secure IT Server.

A. Generate a Certificate Request

Follow these steps to generate a certificate request and use it to obtain the Client Certificate from a Certificate Authority:

  1. Open the ssh-certtool utility and enter the following command to generate a certificate request that you can send to your Certificate Authority for signing:
ssh-certtool –n <rsa or dsa> -o <output file name> req
CN=<"User Name">,O=<Company>,OU=<OrganizationalUnit>,L=<City>,ST=<State>,
C=<Country>

For example:

ssh-certtool –n rsa -o user1 req CN="User Name",O=Attachmate,OU=Support,L=Seattle,ST=Washington,C=US

The e-mail address can also be added to the Subject Alternative Name by including the option:

-z email=user@example.com

For example:

ssh-certtool -n rsa -o user1 -z email=UserName@myCo.com req
CN="User Name",O=Attachmate,OU=support,L=Seattle,ST=Washington,C=US
  1. The ssh-certtool will generate two files:
user1.ssh2 (the private key)
user1.pkcs10 (the certificate request)
  1. Send the resulting pkcs10 package (in our example, User1.pkcs10 file) to a Certificate Authority for signing. The package is an ASCII file that you can view in a text editor.

If you choose to submit the request by cutting and pasting the text into the CA’s pkcs10 request form, be certain to copy the entire text including

-----BEGIN CERTIFICATE-----

and

-----END CERTIFICATE-----
  1. You will receive your CA-signed client certificate in a "Base-64 encoded" or ".pem" format depending on the CA. Either format is acceptable. Note: Do not use DER encoded binary format.
  2. Rename the signed user certificate using a .crt extension, for example, User1.ssh2.crt.

B. Configure the Client to Store and Use Certificates

Follow these steps to install the certificates:

  1. Using binary format, transfer the client certificate renamed in step A-5 (User1.ssh2.crt) and the private key created in step A-2 (user1.ssh2) into your user’s $HOME/.ssh2 folder.
  2. Change to the $HOME/.ssh2 directory.
  3. Set permissions on the user key for user-only read-only access:
Chmod 400 user1.ssh
  1. Open the identification file for editing (if this is a new install, you may need to create this file) and add the line:
CertKey <myUserPrivateKey>

For example:

Certkey User1.ssh2

The certificate itself will be read from the same location where the private key is installed. In the example, it is located in the user's home /.ssh2 directory.

  1. Configure this file for user-only write access:
chmod 600 identification
  1. On the client, edit the ssh2_config file:
AllowedAuthentications must include publickey.
IdentificationFile must specify the file you configured in step B-4.
  1. Save the ssh2_config file.

C. Configure Reflection SSH Server for Certificate User Authorization

Beginning in version 7.1, both Reflection for Secure IT UNIX Server and Reflection for Secure IT Windows Server use the Reflection PKI Services Manager to provide X.509 certificate validation services. The PKI Services Manager is available for either the Windows or the UNIX environment. See KB 7021870, “Reflection PKI Services Manager Overview,” for more information and sample configurations.

Follow the steps to configure Reflection for Secure IT Server on either UNIX or Windows.

Reflection for Secure IT UNIX Server 7.1 or Higher

The steps to configure Reflection for Secure IT UNIX Server depend on whether the Reflection for Secure IT UNIX Server and the PKI Services Manager are installed on different machines or on the same machine.

Different Machines: Follow these steps if Reflection for Secure IT UNIX Server and PKI Services Manager are installed on different machines.

  1. Determine the IP Address of the PKI Service Manager.
  2. Download a copy of the PKI Service Manager’s public key. The default public key name is pki_key.pub.
  3. Transfer the pki_key.pub to /opt/attachmate/pkid/config onto the UNIX server.
  4. In the sshd2_config, edit the PkidAddress line with the PKI Service Manager’s IP address.
  5. Uncomment both PkidAddress and PkidPublickey lines.

Example:

### Add PkidAddress and pkiPublickey for testing
##
PkidAddress=10.10.1.216:18081
PkidPublicKey=/opt/attachmate/pkid/config/pki_key.pub
##
##
  1. Save the config file.

Same Machine: Follow these steps to configure Reflection for Secure IT UNIX Server to use the PKI Services Manager validation services.

  1. In the /etc/ssh2/sshd2_config file, uncomment both PkidAddress and PkidPublickey lines, keeping the defaults. For example:
### Add PkidAddress and pkiPublickey for testing
##
PkidAddress=localhost:18081
PkidPublicKey=/opt/attachmate/pkid/config/pki_key.pub
##
##
  1. Save the config file.

Reflection for Secure IT Windows Server 7.1 or Higher

  1. Launch the Reflection for Secure IT Windows Server console and click the Configuration tab.
  2. In the left pane, navigate to Authentication > Public Key > Certificates.
  3. In the PKI server field, if the PKI Services Manager is installed on the same Windows server, accept the default settings.

If PKI Services Manager is installed on a different server, enter the IP address or host name (for example, winpkiserv1); and in the Port field, specify port 18081.

  1. If the PKI Services Manager is installed on the same Windows server, you can browse to the key file. By default, the public key is called pki_key.pub. Its default location is:

On Windows 2008: C:\Users\All Users\Attachmate\ReflectionPKI\config

On Windows 2003: C:\Documents and Settings\All Users\Application Data\Attachmate\ReflectionPKI\config.

If PKI Service Manager is installed on a different system, obtain a copy of the pki_key.pub from the PKI Service Manager and store it on the Reflection for Secure IT Windows Server.

  1. Click the Verify connection button to confirm that you can establish a connection to the PKI server.
  2. Click the Save button or click File > Save to save the PKI settings.
  3. Click Action > Restart Server.

About Trusted Root CA Certificates

A certificate issued by a Certification Authority (CA) to itself is called a Trusted Root certificate; it is the anchor point for a chain of trust. When one entity uses a certificate to authenticate itself, the other entity must verify the trust relationship between the first entity's certificate and the Trusted Root CA that is at the beginning of the chain of trust.

For example, if a user is presenting a certificate to authenticate themselves to the server, the server needs to verify two properties:

  1. User has the private key for the public key contained in the certificate and can correctly sign an authentication message.
  2. The signatures of any intermediate CA certificates are valid all the way to the Trusted Root CA.

This second validation requires that the Trusted Root certificate for the user's certificate resides in the Trusted Root store on the server and that any intermediate CA certificates can be obtained.

Make a Secure Connection with Certificate Authentication

To make a secure connection with certificate authentication using the SSH UNIX client, simply log in to your host using the <account-id>@<host> command.

Additional Information

Legacy KB ID

This article was originally published as Attachmate Technical Note 2449.