Different methods can be used to authenticate users in Tectia. These authentication methods can be used separately or combined, depending on the level of functionality and security you want.
The Secure Shell server defines what methods are allowed in user authentication, and the Secure Shell client defines the order in which they will be tried.
By default, the Tectia Client/Server solution uses these user authentication methods:
Public-key and certificate authentication are combined into the public-key authentication method.
The most commonly used user authentication methods are password, public-key, and host-based authentication. 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.
When certificates are used in user 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.
Tectia Server for IBM z/OS can also use X.509 certificates and RSA keys managed by the z/OS System Authorization Facility (SAF) in user public-key authentication. Tectia Server for IBM z/OS includes two implementations of certificate authentication:
keys and X.509 certificates in files and software cryptography; this is the same implementation that is available in the Tectia products on all platforms.
keys and certificates managed by the z/OS System Authorization Facility (SAF) and cryptographic operations handled by the z/OS Integrated Cryptographic Service Facility (ICSF).
The SAF validation may be complemented with the Tectia certificate validator and the Tectia implementation may use trusted keys stored in SAF.
If only SAF validation is used, the certificate validity period and revocation status are not checked. Securitywise, this equals normal public-key authentication, with keys stored securely in SAF. Note also that if SAF is used purely as a key store, the certificates have to be distributed to each host separately and the scalability advantage of PKI is lost.
Keyboard-interactive is not an authentication method in itself, but more like a common interface to various other authentication methods that are based on keyboard input. Password authentication, RSA SecurID, PAM (Pluggable Authentication Module), and RADIUS are examples of authentication methods that can be used over keyboard-interactive.
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 supports also several other strong authentication methods, including the proprietary RSA SecurID.