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

Compare with Current View Page History

« Previous Version 3 Next »

Participants

Proposers
NameOrganisation

Mads Freek, Mikkel Hald

Deic
GN4-3 project team


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


Stakeholders
Name

Organisation

Role 
Markus HardtKITStakeholder
Tangui Coulouarn DeicStakeholder

Activity overview

Description

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

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.

Risks

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


Sustainability

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

Results

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

Meetings

Date

Activity

Owner

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

Documents


No files shared here yet.



  • No labels