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

idea: stateless remotemoe #7

Open
fasmide opened this issue Dec 19, 2021 · 1 comment
Open

idea: stateless remotemoe #7

fasmide opened this issue Dec 19, 2021 · 1 comment

Comments

@fasmide
Copy link
Owner

fasmide commented Dec 19, 2021

I think it would be cool if remotemoe had no configuration state other than what its clients supply to it. Having run remote.moe (the service) for some time now, I've realized that its datastore needs some maintenance - it's filled with abandoned hostnames users added for testing - I would much rather it didn't store anything about its users.

At the moment, to activate a custom hostname, remotemoe assumes the first user to ask for a particular hostname is the one who should own it from now on. Unless removed, other users cannot use it without acquiring the associated ssh keypair.

This information is stored forever at the moment: it would be uncool if it were possible for others to steal each other's hostnames, especially since remotemoe may have asked Let's encrypt for valid SSL certificates. So another solution is needed if remotemoe is to magically provide the same security over hostnames while not storing any data locally.

I think this is achrivable by dropping support for <custom-host>.remotemoe and force users to bring their own domains, which should have their DNS configured with CNAMES to <their-public-key-hash>.remotemoe. remotemoe could lookup this information to verify if a user should be allowed to use a particular hostname.

Untitled (1)

@fasmide
Copy link
Owner Author

fasmide commented Dec 19, 2021

More thought needs to go into the removal of <custom-host>.remotemoe hostnames - they provide users with an easy way to get started and should somehow still be available in some form or another.

Maybe remotemoe should advise against using them - or perhaps the user could provide something that proves ownership over the subdomain

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant