RCauth.eu and MasterPortal SSH Key Portal

Introduction

The SSH Key Portal is a modified OAuth for MyProxy (OA4MP) client. Instead of using the OIDC access_token to retrieve proxy certificates, it is used to authenticate to the Master Portal sshkey endpoint, thereby providing a self-service portal for end-users for uploading their SSH public key to the Master Portal. Once the user has uploaded their public key they can use SSH key authentication to retrieve proxy certificates by ssh-ing to a special SSH server host, similar to SSH key authentication used by e.g. SVN, github, GlobusOnline etc.

The client is implemented as a tomcat servlet, running in the same tomcat container as the MasterPortal itself. For simplicity we also assume the vo-portal servlet is also enabled on the MasterPortal.

SSH Key registration flow

1. The flow starts with the user going to the portal endpoint, https://masterportal.example.org/sshkey-portal. Note, the EGI instances use https://masterportal.example.org/sshkeys instead.
2. The user now needs to login, which triggers a redirect to the RCauth.eu CA, where the user will log in via the WAYF.
3. Once logged in the user is returned to the SSH Key Portal
   • When this is the first time the user logs in, (s)he can only add a new key
   • When the user has previously added a key, it's also possible to remove or update an existing key
4. Adding a key:
   • one can either upload (click browse) or paste the content of the file in the text field. Note: paste only a single key in the text field.
   • a label can be given to the key, when not specified by the user, a default is given (ssh-key-<SEQUENCE NUMBER>).
   • optionally, one can add a description for personal use.
5. Updating/removing a key:
   • one can only change the value of a existing public key or change the description.
   • Changing the label requires removing the key and subsequently uploading it as a new key.

SSH Key usage flow

Once the user has a SSH public key uploaded via the https://masterportal.example.org/sshkey-portal (or https://masterportal.example.org/sshkeys for EGI) portal, it's necessary to make sure there is a long-lived proxy certificate (typically 11 days) in the backend credential store of the MasterPortal. The easiest is to use the https://masterportal.example.org/vo-portal for that.

So the steps are as follows:

1. About once every week, the user goes to https://masterportal.example.org/vo-portal to ensure there is a valid long-lived proxy present on the MasterPortal.
2. User adds their ssh private key to the ssh agent, using e.g.

   ssh-add -c

   or

   ssh-add -c ~/.ssh/id_rsa

3. User can now ssh to the special ssh server using the special account to retrieve a proxy certificate. Something like

   ssh proxy@ssh.example.org > /tmp/x509up_u$(id -u)

4. The user can verify that there is now a valid proxy by running

   voms-proxy-info -all

   .

Advanced options

By passing extra options on the ssh commandline, the user can adapt the returned proxy certificate or get extra information about the server or the availability of a proxy.

Valid options currently include:

help	show help text with the available options, supported VOs etc.
info	return information on the long-lived credential currently in the MasterPortal for the user.
time=<HOURS>	specify preferred lifetime in hours of returned proxy, when longer than the available proxylifetime, the maximum available is used
voms=<VO|FQAN>	return a VOMS proxy instead of a plain proxy. Can repeated multiple times

Examples

• Get info for the user:

  ssh proxy@ssh.example.org info

• Get a testvo proxy

  ssh proxy@ssh.example.org voms=testvo > /tmp/x509up_u$(id -u)

• Get a testvo proxy with also an additional subgroup & Role. Also specify the preferred lifetime to be 24 hours

  ssh proxy@ssh.example.org time=24 voms=testvo1 voms=testvo1:/testvo1/Role=member > /tmp/x509up_u$(id -u)

Source

The source of the portal can be found on github