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

SSH Tectia

GSSAPI Authentication

GSSAPI (Generic Security Service Application Programming Interface) is a function interface that provides security services for applications in a mechanism-independent way. This allows different security mechanisms to be used via one standardized API. GSSAPI is often linked with Kerberos that is the most common mechanism of GSSAPI. For the Kerberos authentication to work through GSSAPI the client and server must already be configured to be able to use Kerberos (i.e. be able to gain tickets).

Kerberos is the only supported GSSAPI method in the current version.

Kerberos/GSSAPI is not used to initially log on to a network. The user must have logged on to the network, and the user must possess existing logon credentials that can be accessed through GSSAPI. GSSAPI is about transferring existing credentials (also called tokens) from the client to the server.

Kerberos/GSSAPI itself does not transfer anything over the network—that is the responsibility of the application. GSSAPI provides opaque credential data for the application to be sent to a peer. In Secure Shell, the credential data is passed securely over the SecSh transport layer, just like in any SecSh authentication method.

The authentication method starts with the client sending the server a list of GSSAPI mechanisms that the client supports. The server selects the first mechanism from the list that it supports. Currently the only supported method is Kerberos. Once the mechanism has been negotiated, token exchange begins. Token exchange may involve several packet exchanges between the client and the server, depending on the mechanism. All the exchanged token data comes from GSSAPI; SecSh does not understand it but only relays it. In the end, the token has been transferred to the server to be used for user authentication. The server uses the token to request the identity of the user from GSSAPI.

The GSSAPI authentication method does not ask anything from the user. If something fails during GSSAPI exchange, the reason for the failure can be seen in the client debug log.




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