There’s no separate signing in use here except for the ssh connection, which can be trivially mitm’d in common targeted scenarios because of the lack of webpki and the lack of other preparations. SSHFP would help, but only if configured both in dns, and if the client is both configured to look for it, using secure dns, and the user understands the failure UX and doesn’t just bypass it. On DNS: DoH would help but it is only in widespread use in browsers. DoT would help but it is only in widespread use on android.

In addition to this a further scan of the code reveals it’s also using a btree index lookup for code comparison and no limitation on attempts, so it is likely that this is relatively trivial to attack with timing as well.

Trivialize mitm all you want, you say concerns of mitm are hyperbolic, I gave a practical example of a target rich environment and there are plenty more folks could come up with. SSH may have long been skirting the lack of a better host key distribution system, but this is largely a matter of luck, access and bespoke usage. These new deployments demonstrate a change on two of these factors, increasing risk substantially if this grows.

PGP keys are associated with emails and there are various fully decentralized options to discover these keys (keyservers, WKD, ...). (How) does Keypub improve on this?

As a developer, I agree. Give me a great CLI, please, not a server rendered TUI.

This gives me another thought though, a "server-rendered" CLI. A tiny shim binary that just sends argv to the server, and the server sends back stdout/stderr. Haven't seen anyone try that.

``` ).WHERE( AND( table.SSHKeys.Email.EQ(String(to_email)), table.SSHKeys.Fingerprint.EQ(String(fingerprint)), ), ) ```

If not using a `citext` column then you're going to want to normalize (ie downcase/tolower) everywhere you're doing arbitrary string comparisons, or you're going to get incorrect counts.

Also I don't see any null or "" checking taking place before querying...

I'm not going to trust that your service can give me any reasonable confidence about the identity of the ssh key or the email it's attached to.

That aside, I'm not understanding what the goal here is. I've never once needed my ssh key tied to my email address, but if I did, it's included in the public key already...

"why" doesn't work either.

When you say "OAuth", what exactly do you mean? It looks like this is really just a tool for associating email addresses with SSH keys.

This is an interesting concept, but it smells a bit like a solution in search of a problem. Perhaps it will feel more useful to me once there are two or three SSH apps that I want to access. Even then, I would suggest that prospective SSH app developers just lean on github's public SSH keys instead, as basically all developers will have a github account and this reduces your (already high, relative to webapp) startup friction.

Oauth usually implies some variability of access - ie selective permissions. Is this more a pure authn layer as opposed to authz?

You have a repo on GitHub... Have you looked at using account public keys for anything? Ie https://github.com/hpsin.keys I hear a lot about how those keys should get used to bootstrap pki systems but I've not seen it happen yet.

Sounds like a similar family of problems to [Wish](https://github.com/charmbracelet/wish) by charm.sh. They've been pushing this curious paradigm of "ssh apps", where ssh keys are used to automatically create identities for small self-hosted CLI/TUI apps.

As a useful comment for messh, it looks like you've committed the ssh_server binary file to git; you may want to add that to gitignore, as binary file handling isn't a traditional git strength. I _think_ it's better than it was a decade ago when I last investigated this, but I can see that Pro Git still recommends explicitly setting gitattributes to mark a file as binary https://git-scm.com/book/en/v2/Customizing-Git-Git-Attribute...