You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Current »

About

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.

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).


a)

b)



Who can use it?

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

Infrastructures

Infrastructures can set up their environment to support users' access from MyAccessID using provided SSH certificates.

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 mapping to the MyAccessID Identifier of a user.

Users

Any user registered in MyAccessID can request a short-lived SSH certificate using one of the available supported CLIs or by any third-party tool able to support  OIDC device-code flow.


  • No labels