AARC Pilot - SSH Key Portal
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
- 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.
- The user now needs to login, which triggers a redirect to the RCauth.eu CA, where the user will log in via the WAYF.
- 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
- 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.
- 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:
- 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.
- User adds their ssh private key to the ssh agent, using
ssh-add -c ~/.ssh/id_rsa
- User can now ssh to the special ssh server using the special account to retrieve a proxy certificate. Something like
ssh email@example.com > /tmp/x509up_u$(id -u)
- The user can verify that there is now a valid proxy by running
By passing extra options on the ssh commandline, the user can adapt the returned proxy certificate or get extra information. 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|
- Get info for the user:
ssh firstname.lastname@example.org info
- Get a testvo proxy
ssh email@example.com 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 firstname.lastname@example.org time=24 voms=testvo1 voms=testvo1:/testvo1/Role=member > /tmp/x509up_u$(id -u)
The source of the portal can be found on github