I think it's just something people do because "everyone else" is doing it. Lots of familiarity around email. "it's just not done" as they say.
People regularly lose their ssh keypair and also don’t generate a token. I think using email as a form of recovery is totally fine and regardless when you have to pay for the service you’re going to give up your email (and other personal info) via payment processor
And kudos on your service, I'll keep it mind next time I'm picking a provider.
But, my original comment is strictly about email. Even if you asked for a government-id and credit-card payment, I won't object. Just please, no email!
How would you normally recover an account? Email? So, if my email is compromised, everything gets compromised? That's not sane at all. You should normally have MFA, and if you can recover your MFA/2FA with email, it's just an over-engineered inconvenience. The way it's done right, the MFA recovery code servers as a general account recovery code as well. You save that somewhere safe and offline.
In this case, they use ssh public keys, so there is no need for all that, just add a spare public key to authorized_keys, and keep it's private key offline and safe, ideally in an HSM.
This is a service for technical people, so all that works, for general consumer service, you give them a choice. Either they choose to use a recovery key, a recovery email/phone...or recovery via payment. Let them pay $1 for recovery, proving they control the original method of payment (KYC not crypto). But if nothing else, users should be able to choose recovery code instead of email. It's more secure, because you're not relying on a 3rd party service to also be secure. I don't like them much, but recovery questions have also been used, but if you think about it, those are not that different from recovery codes, they're just more guessable.
Recovery codes aren't one string, they're usually multiple, so if users chose, they can split up their storage. For added reliability, you can require validation of recovery codes periodically, after a successful sign-in.
The nice thing about recovery codes is being able to store them securely in a password manager alongside any other entries for the service.
The downside is they're easy to leak (or lose), so the added factors in requiring access to email (also with its own 2FA) are lost in a system like this, if whatever you're managing is mission critical. I wouldn't want to make that kind of bet, personally.
I get it, that's why I advocate letting users choose. Especially with a technical audience, treating them like they can't be trusted to make mission critical choices is not good.
Lost me at "verify email" though. Why get so creative, yet limit yourself to archaic "email". Why do *YOU* the provider need me to have an email or a phone?
Look, mullvad can provide vpn services without email or all that nonsense. If you want people who will use ssh to order things, these are the same people that would get your service because you're not asking for dumb things like email. It's the first thing you ask of potential users, and it's an obstacle preventing them from giving you their money!
You can issue users a recovery/access key and/or let them user their ssh public key and trust they know how to manage that on their own. If you have messages for them, display that when they login. This sort of stuff differentiates your service, ssh does too, but it's cosmetic and gimmicky. I would prefer a rest-api over ssh anyways, but ssh is cool too.