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

SSH Tectia 
PreviousNextUp[Contents] [Index]

    About This Document>>
    Installing SSH Tectia Client >>
    Getting Started >>
    Configuring SSH Tectia Client >>
        Defining Profile Settings >>
        Defining Global Settings >>
            Defining the Appearance
            Selecting the Font
            Defining Messages
            Authenticating Users
            Managing Keys
            Managing Custom Keys
            Managing Certificates
            Using SSH Accession Lite
            Managing PKCS #11 Providers
            Authenticating Servers
            Managing Host Keys
            Managing CA Certificates
            Defining LDAP Servers
            Defining Advanced File Transfer Options
            Defining File Transfer Mode
            Defining Proxy Settings
            Defining Security Settings
        Editing the Configuration Files >>
        Using Command-Line Options
        Customizing the User Interface>>
    Connecting to a Remote Host Computer>>
    Transferring Files>>
    Tunneling Applications>>
    GUI Reference>>
    Troubleshooting >>
    Command-Line Tools >>

Authenticating Servers

There are two different methods that can be used to authenticate the server (remote host computer) you are connecting to: public-key authentication and certificate authentication.

Figure : The Server Authentication page of the Settings dialog

Security of the First Connection

When public-key authentication is used to authenticate the server, the first connection is very important. The client asks the user to save the host key to the local database. The fingerprint of the public key should be verified before you save it to the local database and proceed with the connection. If you do not verify the authenticity of the fingerprint, you risk the possibility of a man-in-the-middle attack. For future connections, the local copy of the server's public key will be used in server authentication.

Certificate authentication is more secure than the traditional public-key authentication, as the system verifies that the server certificate has been issued by a trusted certification authority (CA) and that the certificate has not been revoked. When certificate authentication is used, a man-in-the-middle attack is no longer a threat during key exchange, as the system verifies that the server certificate has been issued by a trusted certification authority (CA).

If the server certificate itself does not contain a valid authority information access or a CRL distribution point extension, an LDAP server has to be configured on the client-side to obtain a certificate revocation list (CRL).

PreviousNextUp[Contents] [Index]

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

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




What to read next:

  • Reduce Secure Shell risk. Get to know the NIST 7966.

    The NISTIR 7966 guideline from the Computer Security Division of NIST is a direct call to action for organizations regardless of industry and is a mandate for the US Federal government.
    Download now
  • ISACA Practitioner Guide for SSH

    With contributions from practitioners, specialists and SSH.COM experts, the ISACA “SSH: Practitioner Considerations” guide is vital best practice from the compliance and audit community.
    Download now