Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

About

One of the capabilities of MyAccessID is providing reliable short-lived SSH certificates for MyAccessID users on request.

MyAccessID provides this capability through the external SSH CA service deployed by the Danish e-Infrastructure Consortium (DeIC).

These pages should provide necessary support for usage of this capability as a user of MyAccessID or the Infrastructure connected to MyAccessID.

List of pages

Description

The SSH Certificate is a signed SSH public key by a trusted Certification Authority. It will contain the SSH key and metadata about the certificate and user's identity.

SSH certificates fix many common problems of standard SSH keys, for example:

  • A user is no longer responsible for creating and managing his SSH keys by himself.
  • The key has a limited lifetime (validity).
  • The SSH certificate can contain other metadata (about the owner, limited scopes of usage, etc.)

SSH access is an essential and standard building block of all HPC environments. For MyAccessID, we have focused on security, operability, and user experience issues of this access, for example:

  • A user is responsible for creating and managing his SSH keys
  • The rekeying is hard to manage, and in the end, keys are used permanently
  • TOFU (trust on the first use) is always approved; almost nobody checks the key fingerprint of the host
  • Hostnames can’t be reused, which leads to the change of the fingerprint when this happens
  • The key distribution across the infrastructure is complex and clumsy
  • TTL of the key is not limited
  • The SSH key has very limited support for metadata (for example, identification of the owner)

To prevent these issues and, at the same time, support the needs of advanced users who require terminal access, we have integrated the Federated SSH Certification Authority. It allows users to authenticate and access via command-line environments using the same federated identity mechanism. To streamline the process, the creation and management of SSH keys are automated and abstracted from the user as much as possible.The user initiates the SSH login in their own terminal to the access node of one of the hosting sites that supports access via SSH certificates. The user does not have to have any SSH keys. Behind the scenes, the SSH login flow will start an OAuth2 Device Code flow and will present a link or a QR code to the user. The user copies the link or scans the QR code with their phone, and they are requested to prove their identity via MyAccessID.

Description

Terminal access is considered by the hosting side as an advanced access method and thus requires two-factor authentication. The user authenticates on their devices with both factors and after successful authentication, they can return to the terminal where they have logged on to the access node. What has happened is that when the user authenticates on their device, they authorize their terminal process to retrieve an access token that is bound to the user’s identity. The SSH login process received the access token and invoked the OAuth2-protected API of the SSH Certification Authority (CA). The CA API verified the identity of the user by using OAuth2 Introspection, and since the user had the appropriate rights, it issued a short-lived SSH certificate that was sent back as the API response. The SSH login flow used this SSH certificate to authenticate at the SSH service running on the remote access node. The SSH service on the access node recognized that the SSH client presented an SSH certificate that was signed by a trusted CA, verified the validity of the certificate, and then used the MyAccessID identifier of the user from the certificate and mapped the user to the appropriate local POSIX account.

Section


Column
width30%

SSH Certificate

In general, It is a public SSH key signed by a trusted Certification Authority. This authority also provides verified metadata, which can be used to identify and authorize the user in the environment. It also contains information about the validity, so the whole key expires after some time, and a new one needs to be provided. This validity can be set to a very short one, which leads to short-lived SSH certificates similar to a login session. The biggest advantage of this solution is the standard support of SSH certificates in the

...

infrastructure environment. For a standard SSH key (a), the SSH certificate will look similar to this one (b).


Column
width10%



Column
width60%

a) Image Added

b) Image Added




...

Who can use it?

The Federated SSH CA capability is provided for all users and infrastructures connected to MyAccessID.

...

They need to establish a configuration for their hosts/resources to accept valid SSH certificates from the MyAccessID SSH Certification Authority and provide access to local accounts based on the basis of mapping to the MyAccessID Identifier of a user.

...