Skip to content
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

Restrict public keys to tcp-aliases #231

Open
giezi opened this issue May 24, 2022 · 6 comments
Open

Restrict public keys to tcp-aliases #231

giezi opened this issue May 24, 2022 · 6 comments
Labels
enhancement New feature or request feature-request A request for a new feature

Comments

@giezi
Copy link

giezi commented May 24, 2022

Hi there

Thanks for the great project!

Just a question: Is it possible to restrict TCP aliases to specific public keys with a matching pattern option (like KEYNAME1-* is allowed to access all TCPALIAS1-* )?

Usecase: allow only specific public keys from a customer to access specific tcp-aliases (with a wildcard option)

Thanks a lot,
Reto

@antoniomika
Copy link
Owner

Hey @giezi,

Unfortunately, this is not supported by sish (yet). I've been trying to think about an ACL system and how best to manage it.

I'm trying to keep sish as stateless as possible, but have some ideas on how this might be supported in the future. Make sure to stay tuned and keep following the project!

As an aside, if you're using sish for work and are making money from it (totally and completely permissible by the project's license) consider sponsoring the project! Not mandatory by any means, just helps allow me to assign more time to the project and keep adding awesome features :)

Best,

@antoniomika antoniomika added the feature-request A request for a new feature label May 24, 2022
@giezi
Copy link
Author

giezi commented May 25, 2022

Hi @antoniomika

Many thanks for the fast feedback :)
That would be awesome - our project is at the moment in a PoC stage which doesn't require the ACL system.
Once we've completed the PoC and started moving the project further into production, I will talk to my boss regarding the sponsoring :)

Best regards
Reto

@raghunrv
Copy link

The authenticity of host '[ssi.sh]:2222 ([104.225.216.27]:2222)' can't be established.
ED25519 key fingerprint is SHA256:jJDD2ObGNkf9euI7ZVB9Qy+GhZU0FQE1+pUwlvsBVJE.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[ssi.sh]:2222,[104.225.216.27]:2222' (ED25519) to the list of known hosts.
raghu.vamshinarlagir@ssi.sh's password: 

Asking for password not sure which password and where to get it

@Kalmito
Copy link

Kalmito commented Sep 6, 2022

The authenticity of host '[ssi.sh]:2222 ([104.225.216.27]:2222)' can't be established.
ED25519 key fingerprint is SHA256:jJDD2ObGNkf9euI7ZVB9Qy+GhZU0FQE1+pUwlvsBVJE.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[ssi.sh]:2222,[104.225.216.27]:2222' (ED25519) to the list of known hosts.
raghu.vamshinarlagir@ssi.sh's password: 

Asking for password not sure which password and where to get it

I have the same problem... :(

@chmuche
Copy link

chmuche commented Sep 28, 2022

@Kalmito and @raghunrv see issues #245

I think I have the same issue as you both.

@antoniomika
Copy link
Owner

The issue the other two above had is because ssi.sh is no longer open to the public. I had to deal with a few people using it for command and control coordination and I did not want to leave that ability up any longer.

@chmuche your issue might be due to how the public keys file is parsed by sish

@antoniomika antoniomika added the enhancement New feature or request label Oct 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request feature-request A request for a new feature
Projects
None yet
Development

No branches or pull requests

5 participants