Your browser does not allow this site to store cookies and other data. Some functionality on this site may not work without them. See Privacy Policy for details on how we would use cookies.

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
            Printing
        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.


client-serverauthentication-page-47.gif
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

===AUTO_SCHEMA_MARKUP===