[Contents] [Index]

About This Document>>     Introduction to SSH Secure Shell >>     Configuring SSH Secure Shell >>     Authentication >>         Server Authentication>>             Public-Key Authentication             Certificate Authentication         User Authentication>>         Keyboard-Interactive Authentication >>     Log Messages >>     Using SSH Secure Shell >>     Tool Syntax>>     Technical Specifications >>

Certificate Authentication

Certificate support is included in the commercial version of SSH Secure Shell.

Server authentication is performed using the Diffie-Hellman key exchange. This is what happens when certificates are used:

• The server sends its certificate (which includes its public key) to the client.
• As the server certificate is signed with the private key of a certification authority (CA), the client can verify the validity of the server certificate by using the CA certificate.
• The client checks that the certificate contains the fully qualified domain name of the server.
• The client verifies that the server has a valid private key by using a challenge.

When certificates are used, a man-in-the-middle attack is no longer a threat during key exchange, because the system checks that the server certificate has been issued by a trusted CA.

During authentication the system checks that the certificate has not been revoked. This can be done either by using the Online Certificate Status Protocol (OCSP) or a Certificate Revocation List (CRL), which can be published either to a Lightweight Directory Access Protocol (LDAP) or HTTP repository.

OCSP is automatically used if the certificate contains a valid authority info access extension. Correspondingly, CRLs are automatically used if the certificate contains a valid CRL distribution point extension. If LDAP is used as the CRL publishing method, the LDAP repository location can also be defined in the ssh2_config file (see below).

Server-Side Configuration

To configure the server-side functionality, perform the following tasks:

1. Enroll a certificate for the server. This can be done with the supplied ssh-certenroll2 command line utility. Note that the DNS Address parameter needs to correspond to the fully qualified domain name of the server. Example: Enrollment using ssh-certenroll2:

   $ /ssh-certenroll2 -g -p id:key -e 
   -s "C=FI,O=SSH,CN=testserver;dns=testserver.trusted.org" 
   -a "http://test-ca.trusted.org:8080/pkix/" 
   -o /etc/ssh2/hostcert_rsa /etc/ssh2/test-ca-certificate.crt
   Generated 1024 bit private key saved to file 
                                   /etc/ssh2/hostcert_rsa.prv.
   

   Remember to also define the SOCKS server (-S) or the HTTP proxy (-P), if required. For more information on the ssh-certenroll2 syntax, see Appendix ssh-certenroll2.
2. The server's private host key must be in the ssh2 format. To convert X.509 keys to ssh2 format, use the -x flag with ssh-keygen2:

   $ ssh-keygen2 -x <keyname>
   Private key imported from X.509 format
   Successfully saved private key to <keyname>_ssh2
   

   PKCS #12 keys can be converted to ssh2 format by using the -k flag with ssh-keygen2.

   Note: As the server's private key must have an empty passphrase, just press enter when you are prompted for the new passphrase.

   $ ssh-keygen2 -k <keyname>
   Password needed for PFX integrity check : 
   Integrity check ok.
   Got shrouded key.
   New passphrase for private key : 
   Again                          : 
   Successfully saved private key to <keyname>_ssh2
   Safe decrypted succesfully.
   Got certificate.
   Certificate written to file <keyname>_ssh2.crt
   

3. Define the private key and the server certificate in the sshd2_config file:

   HostkeyFile  <private key>
   HostCertificateFile <server-certificate>
   

Client-Side Configuration

To configure the client-side functionality, perform the following tasks:

1. Copy the CA certificate(s) to the client machine.You can either copy the X.509 certificate(s) as such, or you can copy a PKCS #7 package including the CA certificate(s).

   Certificates can be extracted from a PKCS #7 package by specifying the -7 flag with ssh-keygen2.

2. Define the CA certificate(s) to be used in host authentication in the ssh2_config file:

   HostCA <ca-certificate>
   

   Only one CA certificate can be defined per a HostCA keyword. The client will only accept certificates issued by the defined CA.

   You can disable the use of CRLs by using the HostCANoCrls keyword instead of HostCA:

   HostCANoCrls <ca-certificate>
   

   Note: CRL usage should only be disabled for testing purposes. Otherwise it is highly recommended to always use CRLs.

3. Also define the LDAP server(s) in the ssh2_config file.

   LDAPServers ldap://server1.domain1:port1,ldap://server2.domain2:port2,...
   

4. If necessary, define also the SOCKS server in the ssh2_config file.

   SocksServer socks://socks_server:port/network/netmask,network/netmask...
   

   The SOCKS server must be defined if CA services (OCSP,CRLs) are located behind a firewall.