Investigate and further develop SSH support for a federated world

To allow easy access to SSH based services DeiC has made a SSH Certificate Authority proof-of-concept that issues short-lived SSH certificates based on a federated login. The system requires no specific client - or service side installed programs and makes it possible for the user to use all standard ssh services - as long at the certificate is valid. Depending on the configuration of the participating services the CA allows the user to use the same username/uid across all services. Optionally it can be combined with systemd-userdb services to allow for fully automated user management. The CA can also optionally issue host certificates so the users do not have to trust the servers on first use (TOFU).

We want to further explore the possibilities for such a system:

- Is it really possible to do it without "xtra" client- or server side programs?
- Is it possible to do it the other way around - use a ssh session for web login?
- Is it possible to use a certificate as an "assertion" - optionally do auto user creation

Upon further interactions with the incubator team alternative solutions were discussed, for example SURF's pam weblogin (https://github.com/surfscz/pam-weblogin) or KIT's OIDC agent (https://indigo-dc.gitbook.io/oidc-agent/).

Initial goal of the activity is to hold a workshop to gather requirements and showcase and discuss existing solutions.

Solving the above problems requires a lot of work, especially when dealing with a great number of researchers, or servers. Manually collecting SSH public keys from authorized users, making sure they belong to the user, and also figuring out when the user is no longer allowed to access the service is (quite) difficult.

See https://smallstep.comblog/use-ssh-certificates/ .

Federated SSO, on the other hand, scores well on the above criteria (User experience, scaling up, security) but is usually limited to the web.

A potential risk is that there is not enough interest in the community for a federated SSH solution.

The activity has no impact 

As part of this activity, the following actions will be done:

• Host a series of workshops to investigate the use case and available solutions in the community
• Document the workshop results and create a whitepaper that describes the problem and lists possible solutions
• Publish the white-taper and present the lessons learned to the community

The information gathered was compiled into a white paper, which was shared with the community as an opportunity for further collaboration. A user group is to be established to deal with this subject long-term.

In collaboration with interested parties a White paper on federated SSH solutions was created that was later published at GitHub.