-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ability to create atKeys that are specific to a host (in the -d
sense)
#636
Comments
|
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..
and yet
|
@gkc : Sure Gary, Since i am already working on the at_onboarding_cli bug related to atKeys, i will pick this up. |
Re-opening until the PR has been released to canary and @cconstab has verified |
@cconstab : The changes are released into canary with version: c3.0.50. |
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 domainorac.sshnp:rw
so those keys could only be used for a machine called orac and it could only see traffic fororac
.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
The text was updated successfully, but these errors were encountered: