Skip to content

Overview#

We support two mechanisms to enable SSH with federated identities. Both make use of Motley Cue. This allows mapping the same federated identity to the same UNIX ID (usernames, UIDs, groups, …).

All mechanisms require a way for the user to authenticate. We assume fresh Access Tokens being available on the client machine. The mechanism how this is achieved is external to Motley Cue. External tools, such as oidc-agent, mytoken, or htgettoken work well for this.

The supported underlying mechanisms work quite differently:

SSH Certificates#

This newer approach (oinit) makes use of ssh certificates.

  1. The user first obtains an ssh-certificate from our ssh-online-ca “oinit-ca”. For this installing the oinit tool on each ssh-client machine is required, which is available for most Linux distributions in our repository.

  2. oinit-ca interfaces with Motley Cue to provision the user, and returns an ssh-certifcate, if the user is authorised.

  3. The user can then use ssh without any further authentication. Both packages are available in our repository.

  4. Serverside, this requires

Access Token as password#

This approach requires a dedicated pam-module.

  1. The user provides their OIDC access token directly to the ssh-client as password. Since tokens change often and are typically inconvenient to type, we provide two different client side helpers to improve the user experience:

    • mccli – a commandline helper to integrate Motley Cue and the ssh-client, requires installation on the client.
    • web-ssh – a web-browser based approach, which requires no installation anywhere.

  2. Via our pam module pam-ssh-oidc, the ssh-server interfaces with Motley Cue. Motley Cue validates the token, its authorisation and makes the access decision.

  3. In case of large Access Tokens (>1k), Motley Cue issues a short lived one time password which can be used instead.

Commonalities of both mechanisms#

Both approaches have a lot in common:

  • Most importantly, no ssh components are modified. Any ssh-package from any vendor should work with both approaches.
  • We support many Linux distributions, as well as clients for MacOs, Windows, and Web Browsers.
  • Both approaches do require access tokens on the client to authenticate the user. For both mechanisms a good integration with oidc-agent exists.
    While the access token based mechanism requires them on each login, the ssh-certificate based mechanism only requires valid tokens whenever an ssh-certificate expired. This expiry can be set by the admin of the ssh-server/ssh-ca, and may be significantly longer than the lifetime of access tokens.
  • Motley Cue is used in both mechanisms, to ensure that the same user will be mapped to the same UNIX account in the same way, regardless of the mechanism used.
  • Both mechanisms implement ways for removing the username from the equation.

Last change: Feb 17, 2026 19:12:17