Mads Freek, Mikkel Hald

GN4-3 project team

Mads FreekDeicStakeholder, Developer
Mikkel HaldDeicStakeholder, Developer
Martin van EsGEANT / IncubatorDeveloper
Niels van DijkSURF / IncubatorActivity Owner
Michael SchmidtLRZ / IncubatorScrum master



Markus HardtKITStakeholder
Tangui Coulouarn DeicStakeholder

Activity overview


Investigate and further develop SSH support for a federated world

Activity goals

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

Activity Details

Technical details

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 ( or KIT's OIDC agent (

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

Business case

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.

Data protection & Privacy

The activity has no impact 

Definition of Done (DoD)

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.

Activity Results


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





30.06.221. Workshop ‘SSH in a federated world’Niels van Dijk
13.10.222. Workshop ‘SSH in a federated world’Niels van Dijk
15.12.22Incubator final demoNiels van Dijk

  • No labels