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

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