[HN Gopher] Show HN: Keypub.sh - OAuth for the terminal using SS...
___________________________________________________________________
Show HN: Keypub.sh - OAuth for the terminal using SSH keys
Hi HN! I built KeyPub.sh to solve the problem of user verification
for CLI applications. It's essentially OAuth for the terminal, but
using SSH keys that developers and users already have. - No
installation needed - works with existing SSH setup - Privacy-
focused: users control what email info is shared - Simple email
verification process - Free public service - Perfect for CLI app
developers who don't want to build user verification Try it with:
`$ ssh keypub.sh about` Source code:
https://github.com/skariel/keypub
Author : messh
Score : 123 points
Date : 2024-12-23 15:19 UTC (7 hours ago)
(HTM) web link (keypub.sh)
(TXT) w3m dump (keypub.sh)
| hirsin wrote:
| 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.
| Cyphus wrote:
| Ubuntu's installer supports bootstrapping ssh access with this
| method. Put in your GitHub username and it takes care of the
| rest. Works for interactive and headless installs.
| eichin wrote:
| The `ssh-import-id` package is the basic mechanism for this.
| messh wrote:
| it does have authorization with the `allow` and `deny` commands
| for granular control of who can can see what. Currently very
| simple, only for email but maybe other fields in the future
| lufte wrote:
| "about" didn't work for me but "help" did.
| aftbit wrote:
| "why" doesn't work either.
| messh wrote:
| will add them both. Initially I looked at "about" and "why"
| as suitable only for the landing page
| johntdyer wrote:
| Looks interesting but your tls cert isn't valid on your site
| jwilk wrote:
| What do you mean?
|
| https://www.ssllabs.com/ssltest/analyze.html?d=keypub.sh says
| the cert is OK.
| gwynforthewyn wrote:
| 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...
| akshayKMR wrote:
| Regarding ssh-apps, this seems super duper niche to me even for
| developers. Like, I get that many devs are terminal savvy, and
| it's cool that it's possible to serve apps like this but is it
| practical (to pick for your new product /internal app)?
| qudat wrote:
| We are pretty successful over at https://pico.sh using the
| same techniques -- and using wish
| latchkey wrote:
| As a bare metal cloud service provider, we built a little TUI
| app over ssh so that people could upload their public keys to
| us without having to use a web interface. It has worked out
| really well because it makes it possible to "upload" the
| public key without having to do anything but login.
|
| We automatically configure ssh on the servers to auth against
| our own internal api for serving up the keys. This way,
| customers can add to authorized_keys and also use our TUI for
| management as well.
| hamandcheese wrote:
| 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.
| gwynforthewyn wrote:
| That sounds very similar to the command form of ssh i.e.
| "ssh foo.example.com ls" :)
| messh wrote:
| a "server-rendered" CLI is exactly what `keypub.sh` is, and
| what many ssh apps are (some are more TUI)
| bradgessler wrote:
| I'm working on a different approach that doesn't use ssh at
| https://terminalwire.com/.
|
| It's meant for inherently server-based CLI's like Github,
| Stripe, Fly, Heroku, or any other SaaS and can be plugged
| directly into web frameworks. My thinking is that more
| companies would ship command-line interfaces if they didn't
| have to maintain APIs for them, deal with distributing
| binaries (and all the compatibility issues that come with
| that), or deal with all the configuration involved in hooking
| up SSH to their app servers.
|
| It's in beta at the moment, and I'm currently focused on
| Rails apps to get the ergonomics dialed-in. My goal is to
| make it possible for people in _any web framework_ to build
| and ship a CLI to customers in under an hour and never have
| to touch an API or worry about binary distribution for as
| long as their CLI exists.
| qudat wrote:
| At my org the biggest issue with out CLI is not the initial
| distribution, but supporting and maintaining multiple
| platforms, code signing the binaries, and making sure
| customers actually update the binaries.
| bradgessler wrote:
| Yeah, I put all of that under the umbrella of
| "distribution"--the last mile is a huge pain in the SaaS
| that SaaS CLIs shouldn't have to deal with or even think
| about.
|
| Terminalwire will handle the builds for all the different
| platforms, signing, etc. so companies can instead focus
| on shipping their unique features to customers.
|
| I'm also going to ship clients that automatically update
| to match the version of the client that's compatible with
| the server in a way that the client won't even notice.
| messh wrote:
| hi, good catch of the binary! (will fix)
|
| `Wish` and also `terminal.shop` were both great sources of
| inspiration. I hope to see many more ssh apps in the future.
| I'm already working on the next one
| ilyagr wrote:
| Another interesting set of ssh apps is https://pico.sh/ . These
| focus on networking and lightweight hosting (pastes, simple
| blog), all via ssh or rsync.
| aftbit wrote:
| 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.
| messh wrote:
| github public ssh keys are not connected to mails. and using
| the api from the terminal requires installing some tool.
|
| I hope there will be lots of apps for the the terminal, for
| e.g. cde (cloud dev env) managing, task management, project
| management, compute as a service, etc.
| hnlmorg wrote:
| > using the api from the terminal requires installing some
| tool.
|
| It really doesn't. It's just a HTTP API. So basically
| anything that can form a TLS connection will work.
|
| But the bigger problem here is that email addresses can be
| private in GitHub. Also you never know when GitHub might
| change their API.
| sneak wrote:
| OAuth means a specific technical thing, and this is not that
| thing.
| rzzzt wrote:
| "X for Y" should make you draw a metaphorical, not literal
| comparison to X - it is something like X, applied in the
| context/audience/etc. of Y. "Tinder for boats"1 is not Tinder.
|
| 1https://www.buzzfeed.com/michellerial/is-your-startup-
| idea-a...
| orblivion wrote:
| Based on current downvotes it seems that people object to
| this. And I did take this literally myself before going to
| the comments. Still, I think the metaphorical thing has value
| as a succinct explainer. Maybe a small change in wording or
| some quotation marks is the way to go?
| eichin wrote:
| Part of the issue is that "bootstrapping real oauth with
| ssh" is something people actually want, so there's some
| (unearned) disappointment in finding out that this isn't
| it.
| rzzzt wrote:
| I have no horse in this race, was just commenting from a
| generic point of view. The project's README.md says
| "Lightweight alternative to OAuth for CLI applications" in
| section "Use Cases", and there is no further mention of
| OAuth in it, maybe that's more acceptable.
| qudat wrote:
| Nice job! Have you thought about implementing 2fa? I know
| platform.sh supports 2fa via ssh.
| wutwutwat wrote:
| ``` ).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...
| messh wrote:
| there is email validation, and the public key is handled
| between the ssh client and server. If there is no valid public
| key this code would not even run. The fingerprint is prepared
| from this valid public key.
|
| Regarding having the email in the ssh pub key: maybe it is
| there, but it is no validated. Anyone could write anything
| there
| h43z wrote:
| 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
|
| Your "leaked" public keys can be used to check if a certain
| server recognizes that key.
| chasil wrote:
| Loading an alternate client, like Dropbear or PuTTY for Linux
| is one way to avoid this.
| logicziller wrote:
| Or just set `IdentityFile` with the path to the key and set
| `IdentitiesOnly` to yes for the specific host you connect to,
| and disable public key authentication by default for
| everything else.
| jclulow wrote:
| 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.
| bityard wrote:
| "Hijack your keys" is somewhat overstating it, all they can do
| with it is log into other hosts that you can log into, assuming
| key auth is the only factor. And only while you are connected
| to the original host.
|
| Terminal security bugs are not more or less serious than your
| average Chrome 0day.
| xyst wrote:
| 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
| tonymet wrote:
| > 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.
| tonymet wrote:
| 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
| bramhaag wrote:
| 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?
| messh wrote:
| Best practice:
|
| Use SSH keys for SSH connections and authentication
|
| Use PGP keys for email encryption and file signing
|
| Keep these systems separate as they're designed for different
| purposes
| nine_k wrote:
| PGP is hairy and many developers don't have it installed and
| configured. It's full of non-obvious options and
| capabilities.
|
| SSH is a common tool which most developers have installed,
| keep in a working order, use often, and reasonably
| understand.
|
| Guess which tool is easier to _piggyback_ on and achieve
| easier and faster adoption.
___________________________________________________________________
(page generated 2024-12-23 23:00 UTC)