SSH Tectia client/server solution supports authenticating to a Kerberos realm with authentication agent forwarding with the private keys stored on the local host. This makes it possible to log in to a Kerberos realm from a second client/server host during a Secure Shell session.

For example, when a SSH Tectia Client user uses certificates (or a smartcard token) to connect via SSH Tectia Server to other remote servers (running any Secure Shell servers), the local Connection Broker can act as a key store and provide the user's keys to a third-party application such a MIT Kerberos for authentication.

When SSH Tectia Server and sshg3 are used on the second host, the key provider socket is set up by default, as long as authentication agent forwarding is allowed by both Connection Broker and SSH Tectia Server.

Example of the required configuration in the pkcs11 module in the krb5.conf of MIT Kerberos on the second host:

[realms]
 DOMAIN.COM = {
  kdc = ad.domain.com:88
  kpasswd_server = ad.domain.com:464
  pkinit_kdc_hostname = ad.domain.com
  pkinit_identities = PKCS11:/opt/tectia/lib/sshack.so
  pkinit_anchors = FILE:/etc/krb5/ca.crt
  pkinit_win2k = true
  pkinit_eku_checking = kpServerAuth
  pkinit_cert_match = <SAN>.*@DOMAIN.COM
  forwardable = true
  forward = true
 }

Connection Broker configuration on the second host should include:

<default-settings>
  <authentication-methods>
    <auth-gssapi />
    <auth-publickey />
    <auth-keyboard-interactive />
    <auth-password />
  </authentication-methods>
  <forwards>
    <forward type="agent" state="on" />
  </forwards>
</default-settings >

/opt/tectia/lib/sshack.so implements a set of PKCS#11 functionality to support signing, which is not restricted to usage in Kerberos.

If the connection is made via other tools than SSH Tectia Client, the environment variable SSH_AA_SOCK on the local host needs to be configured with the path to the Connection Broker agent socket (by default, /tmp/ssh-<user>/ssh-broker-aa).