Ability to create atKeys that are specific to a host (in the `-d` sense)

[cconstab]

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

My concern is that atKeys can be used currently for a particular app name space like sshnp:rw.

Describe the solution you'd like

It would be great to add for the device orac a namespace sub domain orac.sshnp:rw so those keys could only be used for a machine called orac and it could only see traffic for orac. That may also mean many many other things that are worthy of a discussion in a future arch call..

Describe alternatives you've considered

No response

Additional context

No response

[gkc]

• APKAM already supports hierarchical namespaces, so you can cut keys that have access to .foo or to .bar.foo or to .baz.bar.foo etc
• not sure how one could enforce that a particular set of AtKeys could be strictly tied to a host ... am I misunderstanding your request?

[cconstab]

In that case we may have a bug.. I created a key with access to orac.sshnp but sshnpd reports it could not write/delete a key in that namespace.

You are understanding me correctly.

Orac.atKeys only uses/can access keys in orac.sshnp

It cannot see anything fot foo.sshnp

Which means a bad actor cannot see data/aeskeys being used for another host even if they have access to the localhosts keys.

[gkc]

@murali-shris @sitaram-kalluri can one of you pick this up, I thought this had been implemented / verified via recent PRs

[cconstab]

Some logs. for the record..

cconstab@orac:~/twh$ ./at_activate enroll -s 7IVW6H  -p sshnp   -d orac_subkey2  -n "orac.sshnp:rw,orac.sshrvd:rw" -a @ssh_1 --keys ~/.atsign/keys/oracsub2

$ list
Found 11 matching enrollment records
Enrollment ID                         Status    AppName             DeviceName                            Namespaces
1625506f-8e54-4d67-ad33-fef71711d395  approved  sshnp               orac_subkey2                          {orac.sshnp: rw, orac.sshrvd: rw}
1e0aaee5-c94c-4ee4-9937-9f2e96b6855c  approved  sshnp               orac_subkey3                          {sshnp.orac: rw, orac.sshrvd: rw}
20347bcf-925b-438a-8124-13c70df5e0c5  approved  sshnp               orac_subkey1                          {orac.sshnp: rw, orac.sshrvd: rw}
22e532ef-6448-4245-b9ce-b810860f84ed  revoked   sshnp               orac_twh                              {twh_tools: rw}
275af4e2-c965-43b4-9591-08142ee0acbf  approved  sshnp               orac_demokey                          {sshnp: rw, sshrvd: rw}
3e258bff-1253-431c-8e92-0047bfefd200  approved  sshnp               orac_ssh_3                            {sshnp: rw, sshrvd: rw}
672e0d46-2e86-443e-8b79-be9d0078fca9  approved  sshnp               orac_ssh_2                            {sshnp: rw, sshrvd: rw}
707a70e6-ff19-4a46-82c1-9c7cde186039  denied    sshnp               orac_ssh_1                            {sshnp: rw, sshrvd: rw}
87298ce5-31c4-4b9b-b8b5-643c8f7bd0fe  revoked   twh_tools           twh_orac-kim                          {twh_tools: rw}
d32770e7-9d0f-4e41-a92d-0dfe37cad6a8  approved  sshnp               orac_subkey                           {orac.sshnp: rw, orac.sshrvd: rw}
d8bd3021-0700-4604-b9e5-dc1adea74778  approved  twh_tools           twh_orac                              {twh_tools: rw}
$

and yet

cconstab@orac:~/twh$ sshnpd -a @ssh_1 -m @cconstab -d orac -k ~/.atsign/keys/oracsub2.atKeys --hide
[WARN] -u, --un-hide is deprecated, since it is now on by default. Use --hide if you want to disable device information sharing.
Exception: UnAuthorized client in request : Connection with enrollment ID 1625506f-8e54-4d67-ad33-fef71711d395 is not authorized to delete key: @cconstab:username.orac.sshnp@ssh_1
Exception: UnAuthorized client in request : Connection with enrollment ID 1625506f-8e54-4d67-ad33-fef71711d395 is not authorized to delete key: @cconstab:device_info.orac.sshnp@ssh_1
SHOUT|2024-08-21 14:41:46.759972| sshnpd |connection lost
SHOUT|2024-08-21 14:42:01.798367| sshnpd |connection available

[sitaram-kalluri]

@murali-shris @sitaram-kalluri can one of you pick this up, I thought this had been implemented / verified via recent PRs

@gkc : Sure Gary, Since i am already working on the at_onboarding_cli bug related to atKeys, i will pick this up.

[gkc]

Re-opening until the PR has been released to canary and @cconstab has verified

[sitaram-kalluri]

@cconstab : The changes are released into canary with version: c3.0.50.