Show HN: Keypub.sh – OAuth for the terminal using SSH keys

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...

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.

``` ).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...

No SSHFP record, TOFU clients. This is not secure.

I wish people would stop trying to use SSH for things like this. PKI has features that are missing here and those features matter.

This is unsafe.

"but raggi, mitm before tofu is a really unrealistic scenario"

ok, well, consider that some large percentage of gas stations in the US have hardware installed to skim your credit cards. those same folks are perfectly well motivated to drop a wifi dns mitm in conference buildings (trivial). new tech conference, handful of credit cards as people gossip about exactly these kinds of things in the hallway track. the roi on these installs would be pretty high, because tech folks tend to have a high credit balance. so yeah, "totally unrealistic" (this is more about terminal.shop, but same principle here as soon as someone uses it for actual value).

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.

Care should always be taken when using an SSH client to connect to untrusted hosts. Make sure you’re not actually forwarding your SSH agent to the remote host, or they’ll be able to hijack your keys. Consider also that any output is processed by your terminal, and there have been a number of serious security bugs in terminal escape sequence handling in a variety of terminal emulators in the past.

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?

OAuth means a specific technical thing, and this is not that thing.

I'm not sure I understand what this is useful for. I have dozens of ssh keys I use for various services. Do I register all of them?

I really wish I could have the opposite. To authenticate with my SSH key (openpgp on yubikey) on the web.

I'm not really happy with the Fido options.

"about" didn't work for me but "help" did.

I agree with other commenters that the “oauth” keyword in title is misleading. I assumed this was compliant with oauth spec.

It’s an interesting service, but I doubt I would use this for anything serious beyond toy apps.

There was an article in October mentioning CF acquiring a company that dabbled in this space though. [1]

It’s more for managing authN/Z for internal infra (k8s, servers,) but via existing IdP (with MFA). Underlying tech is “openpubkey”. [2]. I can see this adapted towards authN for CLI apps.

Wanted to test this on my homelab infra but life has gotten in the way.

[1] https://news.ycombinator.com/item?id=41923429

[2] https://github.com/openpubkey/openpubkey

Nice job! Have you thought about implementing 2fa? I know platform.sh supports 2fa via ssh.

Looks interesting but your tls cert isn’t valid on your site

Just a reminder for everyone that by default SSH leaks all of the below public keys (if they exist) + all public keys in your ssh-agent to every server you connect to.

    ~/.ssh/id_ecdsa.pub
    ~/.ssh/id_ecdsa_sk.pub
    ~/.ssh/id_ed25519.pub
    ~/.ssh/id_ed25519_sk.pub
    ~/.ssh/id_xmss.pub
    ~/.ssh/id_dsa.pub

I love that you are approaching this space. SSH keys are an under-valued identity credential. Most big companies i've worked at have a clumsy sync & storage system that I think you could sell to.

I'd encourage the next version using a more distributed approach (instead of a centralized credential DB & email token). A gpg signature or CA (using openssl) are alternative trust models that would provide trust without the DB

> Lightweight alternative to OAuth for CLI applications - just use SSH keys that users already have

I'd love to see more support for this application. I've contributed a number of oauth-based CLI apps and the user onboarding step (3-legged init) is atrocious.