Your browser does not allow storing cookies. We recommend enabling them.

SSH Tectia 
PreviousNextUp[Contents] [Index]

    About This Document >>
    Installing SSH Tectia Server (M) >>
    Using SSH Tectia Server (M) >>
    Troubleshooting SSH Tectia Server (M) >>
    Configuration >>
    Authentication >>
        Server Authentication with Public Keys >>
        Server Authentication with Certificates >>
        User Authentication with Passwords
        User Authentication with Public Keys >>
        User Authentication with Certificates
            Client Configuration
            Server Configuration
        Host-Based User Authentication >>
        User Authentication with Keyboard-Interactive >>
        User Authentication with GSSAPI >>
    Application Tunneling >>
    Sample Files >>
    Man Pages
    Log Messages >>

User Authentication with Certificates

Also certificate authentication is performed via the public-key authentication method. Instead of the client sending just a public key, it sends a certificate containing a public key.

In brief, certificate authentication works in the following way:

  • The client sends the user certificate (which includes the user's public key) to the server. The packet also contains random data unique to the session and signed by the user's private key.
  • The server uses the CA certificate to check that the user's certificate is valid.
  • The server uses the user certificate to check from its mapping file(s) whether login is allowed or not.
  • Finally, if connection is allowed, the server verifies that the user has a valid private key by checking the signature in the initial packet.

Compared to traditional public-key authentication, this method is more secure because the system checks that the user certificate was issued by a trusted CA. In addition, certificate authentication is more convenient because no local database of user public keys is required on the server.

It is also easy to deny a user's access to the system by revoking his or her certificate. The status of a certificate can be checked either by using the Online Certificate Status Protocol (OCSP) or certificate revocation lists (CRLs), which can be published either in an LDAP or HTTP repository.

OCSP is used if the certificate contains a valid Authority Info Access extension. Correspondingly, CRLs are 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 be also defined in the sshd2_config file (see below).

Client Configuration

Server Configuration

PreviousNextUp[Contents] [Index]

[ Contact Information | Support | Feedback | SSH Home Page | SSH Products ]

Copyright © 2005 SSH Communications Security Corp.
This software is protected by international copyright laws. All rights reserved.
Copyright Notice


Highlights from the SSH.COM blog:

  • Cryptomining with the SSH protocol: what big enterprises need to know about it

    Cryptomining malware is primarily thought of as targeting desktops and laptops and is used to hijack system resources to mine cryptocurrency.
    Read more
  • SLAM the door shut on traditional privileged access management

    Did you know that something as trivial-sounding as granting access for your developers or third parties to a product development environment can throw a gorilla-sized monkey wrench into your operations and productivity?
    Read more
  • We broke the IT security perimeter

    Everyone understands the concept of a security perimeter. You only gain access if you are identified and authorized to do so.
    Read more