[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 : 197 points
Date : 2024-12-23 15:19 UTC (1 days 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)
| hamandcheese wrote:
| Yeah, in retrospect, I'm an idiot. I wasn't considering
| `ssh foobar.io dothething` to be equivalent to what I was
| thinking in my head even though it is exactly equivalent.
| 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.
| theamk wrote:
| Looking at their demos immediately brought back the memories of
| parsing TUI's using ad-hoc "expect" rules.
|
| I honestly don't get the point of TUIs...
|
| A real command-line interface is extremely useful - it's
| trivially scriptable, works direct or with ssh, scroll-back
| buffer logs what happened, commands stay in my shell history, I
| can copy-paste commands to a friend over chat system, or into
| shell script, and it's easy for app authors too. Its my first
| choice for my apps.
|
| If low-color fixed-width character grid is not cutting it, then
| native app or web app is a great second step, or even
| intermediate solutions, like generating HTML files from CLI
| tool and opening them in default browser. You have to invest
| some effort, but you have infinite ways to design your
| interface, and it's still in user's familiar environment.
|
| But those charm.sh TUI applications seem utterly useless and
| highly annoying. They give up all of the terminal advantages:
| my shell's history is useless, my favorite ways to edit
| commands does not apply (as they have their own editor), I
| cannot scroll back and see what the program just printed, I
| cannot script it, I cannot log it, I cannot search it, I cannot
| redo the previous action, the color scheme is not the one I've
| picked... At least with web apps I can parse html and/or hit
| underlying API directly - no such luck with TUI apps.
|
| At least the good news is that TUI apps are not getting any
| traction, and I can completely understand why.
| PhilippGille wrote:
| > At least the good news is that TUI apps are not getting any
| traction, and I can completely understand why.
|
| lazygit (54k stars on GitHub) and k9s got a lot of traction
| and are very popular:
|
| https://github.com/jesseduffield/lazygit
|
| https://github.com/derailed/k9s
| darkwater wrote:
| I totally agree with you, I prefer good autocomplete to a TUI
| for all these reasons (and more). Well, I actually prefer any
| CLI to a TUI. The most TUI thing I use in my toolkit is `top`
| (yes, the "classic" one)
| Shugyousha wrote:
| > I honestly don't get the point of TUIs...
|
| There are one or two advantages over regular GUIs, but that's
| it.
|
| The biggest is probably that they are lightweight since there
| are no GUI library dependencies (and if there are TUI ones,
| they are usually much lighter than their GUI sisters). This
| also means there are fewer (if any) dependencies to
| distribute compared to a GUI.
|
| The only other advantage I can come up with is that a TUI
| will have to be usable by keyboard only (in almost all
| cases). This is not a given for regular GUI libraries.
|
| I'm not a fan of TUIs either. I think the only one I am using
| regularly is `tig` (https://jonas.github.io/tig/). I guess
| the reason is that I don't have to remember the git revision
| list syntax that way and that `tig` allows for easy commit
| searching with `/` ...
| houzi wrote:
| TUI's have _one_ thing going for them: Copy paste anything!
| IntelliJ doesn 't let me copy any text it shows me.
|
| Also, TUI's have their place. I haven't looked much at GUI
| alternatives, but k9s is really great.
|
| Would also assume that interactive apps are simpler to
| implement if it's a TUI.
| skydhash wrote:
| The TUI apps I use regularly are:
|
| * lf (file manager) * vim * htop * moc and ncmpcpp (music) *
| emacs (which is its own world)
|
| TUI apps are great for one-time actions that needs feedback,
| especially having a list of something, filtering it, and
| applying an action on one or more items.
|
| But, I still like to have a CLI version so I can script any
| reccuring workflow.
| 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.
| benatkin wrote:
| Indeed. It also doesn't have anything like PKCE.
| 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.
| wkat4242 wrote:
| My yubikey always requires a physical touch so even if the
| agent is forwarded my keys can't be used. And I'll notice when
| it tries because I see it flashing.
| rfdonnelly wrote:
| Best to use an agent that prompts you for signing. 1Password
| and Yubikey do this. Are there others?
| 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.
| wkat4242 wrote:
| I like PGP keys for ssh auth because they can be hardware
| backed through openPGP. That makes it a great option (and
| also the actual crypto is then executed on the key itself,
| not by the gpg software)
| dcow wrote:
| You can do this with ssh keys too. And ssh keys can sign
| git commits. There's no reason these days to even install a
| pgp suite. Stop using it.
| raggi wrote:
| 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).
| dcow wrote:
| Are you serious? A MITM here cannot sign things with your
| private key. People who care can add the keypub's fingerprint
| before connecting. Adding an sshfp record is completely trivial
| too. There is no more tofu here than any other ssh connection
| and the solution is the same. And the added advantage of a PKI
| means, in a properly designed system, a threat actor can't do
| anything useful sitting on the wire. I'm not saying ssh apps
| are going to take off, just that your reaction is quite
| hyperbolic.
| filmor wrote:
| - TOFU: Trust on first use
| (https://en.m.wikipedia.org/wiki/Trust_on_first_use)
|
| - SSHFP: SSH FingerPrint record in the domain name system
| (https://en.m.wikipedia.org/wiki/SSHFP_record)
|
| - MITM: Man in the middle (https://en.m.wikipedia.org/wiki/Man-
| in-the-middle_attack)
| wkat4242 wrote:
| 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.
| pisipisipisi wrote:
| Why? What is wrong with fido?
| wkat4242 wrote:
| Several things. I can't use it for file encryption as well,
| and it's not possible to make a software key as backup (as
| far as I know) in case I lose both my yubikeys. With pgp I
| have a break glass key on an encrypted pen drive.
|
| Also, with SSH it requires a recent version which is not on
| all the boxes I need access to.
|
| It requires pin code entry for every authentication unlike
| openpgp where I enter the pin once and then I just touch it
| for every subsequent authentication. I like that because I
| use it not only for login but also for other stuff like root
| elevation.
|
| And I think agent forwarding doesn't work with it. It's not
| really something I've looked into though as it's just not
| something I can use yet for the other reasons.
|
| For now pgp is just much better for me, though I wish I could
| use it on the web as well.
| SoftTalker wrote:
| 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?
| lormayna wrote:
| Few years ago, I have worked to integrate SSH trough a major IDP
| via PAM modules. It was a bit tricky (especially for a bug in PAM
| in CentOS) but in the long run it worked fine.
| mooreds wrote:
| Why not use the device grant?
|
| It's designed for this use case (among others), is standards
| compliant, and leverages the OAuth ecosystem.
|
| RFC: https://datatracker.ietf.org/doc/html/rfc8628
|
| An example golang CLI tool that uses it:
| https://fusionauth.io/blog/building-cli-app-with-device-gran...
___________________________________________________________________
(page generated 2024-12-24 23:01 UTC)