[Tracker] Team / Enterprise noports

[cconstab]

Tasks

- [ ] https://github.com/atsign-foundation/sshnoports/issues/552
- [ ] https://github.com/atsign-foundation/sshnoports/issues/553
- [x] Internal review
- [ ] https://github.com/atsign-foundation/noports/issues/855
- [ ] Implement 'ownership' concept (ACME corp has delegated management of $devices to Some Tech Services Corp)
- [ ] Get market feedback

Initial problem statement from cconstab

Is your feature request related to a problem? Please describe.

Currently sshnpd only specifies as single manager atSign, which is fine for the original use case but as we head to teams and enterprises using sshnp we have to allow/control multiple atsigns to get access.

Describe the solution you'd like

The existing code in trunk now allows -u which allows X number of accounts to login on demand from a manager atSign but to specifiy which atSigns I would like to have two options.

1. Provide at the sshnpd multiple atSigns at the -m option
2. As this is not scalable in a Enterprise (or us) I would like to see an -m @ atSign option. This would allow the atSign to respond with true/false to allowing the requesting atSign access to the sshd on the host running sshnpd. Being able to specify X number of atSigns would create resiliency and hierarchy (I think).

This approach does work right now and if the sshnpd is running as a username with no shell provides access to any username on the host to log in, which is neat but we need more...

Example logging in as testone on the device iot_device01 and not the username that is running the sshnpd

cconstab@tarial sshnoports % $(./sshnp -f @cconstab -t @ssh_1 -d iot_device01  -h 192.168.1.76 -s testone_rsa.pub -u testone)
Welcome to Ubuntu 22.04.2 LTS (GNU/Linux 5.15.0-76-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

  System information as of Sun Jul 30 08:11:12 PM UTC 2023

  System load:  0.0615234375       Processes:              112
  Usage of /:   42.6% of 31.32GB   Users logged in:        2
  Memory usage: 22%                IPv4 address for ens18: 192.168.1.64
  Swap usage:   4%

Last login: Sun Jul 30 20:08:43 2023 from 127.0.0.1
testone@iotdevice01:~$ 

To allow access to a machine using this method you would just need to ask for the atSign of the user, the username and the public key. This seems very much like an enterprise ready or cloud ready solution.

Describe alternatives you've considered

None but open to any better ideas.. Lets discuss at an arch call

[gkc]

The primary difference in my mind between the individual (home, one-person company) and enterprise use case is

• for individuals
  • they are the owners of the devices
  • and they are also the people who need access to them
• for enterprises
  • the people who need access to the devices will not be the owners of the devices
  • the set of people who should have access to any given device will change frequently (joiners, leavers, on-shift, off-shift, break glass access for @alice because major incident in progress, etc etc)
  • the enterprise itself may not be the owner of the devices but just the current custodians / managers on behalf of the enterprise's customers

I believe the solution outlined by @cconstab works in principle

• @alice runs sshnp and sends message to @sshnpd_atSign saying "I want to ssh to device abc_12345 as user ubuntu"
• sshnpd running as @sshnpd_atSign and knowing a "controller" atSign e.g. @big_tech_services_corp_34567
  • receives the request from @alice
  • sends message to @big_tech_services_corp_34567 asking "should @alice be allowed to ssh to device abc_12345 as user ubuntu?"
  • acts on response appropriately

There are lots of other things to do outside of the changes to sshnpd and sshnp

• build an sshcontrol program which would handle the requests from sshnpd
  • build tooling which enterprises can customize to manage the rules that the sshcontrol program applies
  • need to think about how to manage the secrets that an sshcontrol program will require
  • for example the atKeys for the "controller" atSign, which no human should have access to
  • we could (should?) provide an example of a CICD pipeline for deployment and management of an sshcontrol program
• we almost certainly need the concept of an "owner" atSign - for example let's say ACME corp owns a bunch of devices and has outsourced their care and feeding to BigTechServices corp
  • let's say sshnpd knows its owner atSign @acme_corp_876
  • It could require that responses from the requests to its controller (@big_tech_services_corp_34567) include a signed attestation from @acme_corp_876 that @big_tech_services_corp_34567 is the delegated authority for access control management from (e.g.) Oct 17 2022 09:00 UTC to Dec 31 2023 23:59:59 UTC
  • Furthermore, we can imagine a hierarchy where there are multiple entities in the ownership/control chain, and the attestation is signed by all of the entities in the chain
• We should consider how to prevent denial of service attacks by explicitly setting 'allow' lists on the sshnpd atSigns so that if @garycasey runs sshnp and tries to connect to device abc_12345 then the message is never even sent to the @sshnpd_atSign
• Is there a way we can make the sshnpd itself tamper-proof?
  • e.g. let's say @bob currently has access to a device. How do we stop@bob from reconfiguring sshnpd on the device so that @evil_ken also has access?

... and much more, but as I said I believe this works in principle

[cpswan]

Capturing thoughts from arch call on SSH key management....

A few approaches we've seen:

• Privileged access management (& break glass) tools (like Cyberark)
• Integrated with Smartcards
• Short lived ephemeral keys issued based on authN/authZ against internal directory (e.g. Netflix - some part open sourced)

[gkc]

Next steps: iterate through spikes and reviews until we get a design shape we are happy with. Time-boxing to 5SP for this sprint.

[gkc]

No progress during PR72; moving to PR73

[gkc]

• Minimum demoable product implementation spike complete but not merged. The daemon and authorizer core are in the gkc/feat/teams-enterprise-mdp branch of the sshnoports repo
• For now, the demo integration with PagerDuty is here in my private snippets repo: https://github.com/atsign-company/gary-snippets/blob/main/sshnpa_pd_demo/bin/sshnpa_pd_demo.dart