Secure Shell provides mutual authentication for both the server and the user. It authenticates the Secure Shell server service of the server host. A host may run several Secure Shell server listeners on different ports. On Unix, each server can have a unique identity if desired. However, typically there is only one Secure Shell server listener. If separate policies are needed or different services need to be offered for multiple use cases on a particular host, they can be defined dynamically in the SSH Tectia Server configuration.

The server is authenticated with a digital signature based on a DSA or RSA public-key algorithm. Each server must have a public-private key pair. In implementations without support for certificates, clients refer to a local database of trusted server public keys.

Secure Shell also supports certificate authentication. Servers can authenticate themselves to the client with X.509 v3 certificates. When certificates are used, the client does not need to have a local database of trusted server public keys or server certificates. Instead, just the few trusted CA (certification authority) certificates are stored on the client, and the client trusts the servers whose certificates are signed by a trusted CA and certificate contents match the server hostname. Certificates provide scalability for authentication.

The Secure Shell server may have multiple identities (one DSA key, one RSA key, one DSA certificate, and one RSA certificate). During the key exchange in the Secure Shell connection, the Secure Shell client and server agree on which identity will be used in server authentication. SSH Tectia Client prefers certificates over keys if trusted CA certificates have been configured, and otherwise DSA keys over RSA keys.

User authentication has always been a strong asset of Secure Shell. Multiple methods have been standardized for user authentication and new methods can be implemented easily to the protocol. Secure Shell provides confidentiality for user authentication. User identity is not revealed to eavesdropping parties since the user is authenticated only after the connection has been secured.

The standard user-authentication methods are password, public-key, and host-based authentication. Of these, the public-key method offers the best security. In public-key authentication, the users upload their public key files to the server and edit a configuration file. The server thus has a database of user public keys, similar to the client having its database of server public keys.

In the user certificate authentication, the user does not need to upload any public key files to the server prior to the connection, and the server does not need to have a database of user public keys or certificates. The server validates the user certificate by using the CA certificates that the server has been configured to trust and authorizes the login based on the user certificate contents.

The highest security is achieved by using token-based certificate authentication where the certificate and the private key are stored on a cryptographic token, such as a smart card. Secure Shell provides also several other strong authentication methods, including the proprietary RSA SecurID.

For more on authentication methods, see Chapter 6.