fasmide
commented
2 years ago 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
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.