at_libraries
at_libraries copied to clipboard
atsign-foundation
Ability to create atKeys that are specific to a host (in the `-d` sense)
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
- 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?
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.
@murali-shris @sitaram-kalluri can one of you pick this up, I thought this had been implemented / verified via recent PRs
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
@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.
@cconstab : The changes are released into canary with version: c3.0.50.