Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Open-sourcing OpenPubkey SSH (OPKSSH): integrating single sign-on with SSH

blog.cloudflare.com

Post reply on HN
Print view View original

91–100 of 156 posts

Re: Open-sourcing OpenPubkey SSH (OPKSSH): integrating single sign-on with SSH

#91

Post by mschuster91 »

gfody wrote: post #17
zokier wrote: post #10

I don't love this. > Unfortunately, while ID Tokens do include identity claims like name, organization, and email address, they do not include the user’s public key. This prevents them from being used to directly secure protocols like SSH This seems like dubious statement. SSH authentication does not need to be key based. I understand the practicality of their approach, but I would have preferred this to be proper fi…

ssh -k is too enterprise for ̶t̶e̶c̶h̶b̶r̶o̶ ̶s̶t̶a̶r̶t̶u̶p̶s̶ small companies that don't want to setup a kerberos realm

The problem is, even for large companies, Kerberos can be quite the pain. It's fine for fixed position desktop computers physically located on site or at a remote site with a hardware VPN tunnel - that was what it was built for.

But that is rarely the case any more. People use their own devices (BYOD) that aren't integrated into AD at all, they're using them outside of the office which means there is no VPN available at boot time to deal with token issuance, and the modern "zero trust" crap that uses weird packet filtering black magic instead of proper tun/tap virtual ethernet devices often doesn't play too nice with archaic authentication tools.

On top of that, implementing support for Kerberos in a Dockerized world is just asking for pain.

Re: Open-sourcing OpenPubkey SSH (OPKSSH): integrating single sign-on with SSH

#92

Post by c45y »

_cenw wrote: post #42
EthanHeilman wrote: post #16

Earlier quoted context omitted.

> This seems like dubious statement. SSH authentication does not need to be key based. Let's say you just use an ID Token as a bearer token to authenticate to SSH. The SSH server now has the secret you used to authenticate with. Doesn't this introduce replay attacks where the SSH server can replay your ID Token to log into other SSH servers? Whereas if your ID Token functions like a "certificate" issued by your IDP b…

This is the purpose of the not so well known audience claim. Though I'd still prefer to authenticate to something like Vault's SSH engine and get a very short lived SSH certificate instead. No new software to install on your servers, just the CA key.

CA key also allows those servers to avoid reaching out to some central location to validate which I've found to be a nice side bonus for disaster recovery type scenarios.

Re: Open-sourcing OpenPubkey SSH (OPKSSH): integrating single sign-on with SSH

#93

Post by c45y »

EthanHeilman wrote: post #28
samcat116 wrote: post #21

I can't tell the benefits of this vs running an SSH CA that supports OIDC. In that scenario, the server just needs to trust the CAs key, rather than running some sort of verifier.

The benefits of this is that you don't have the attack surface of an SSH CA. If you do this with an SSH CA that supports OIDC, if either the IDP or the SSH CA are compromised then security is lost. With OpenPubkey and by extension opkssh, your IDP is functioning like the SSH CA by signing the public key that you make the SSH connection with. Thus, you have one fewer trusted party and you don't have maintain and secur…

You can have multiple trusted CAs which I've found to make rotation a non issue with tooling like Ansible etc.

New CA is minted, public key is added to the accepted list, client signing start using the new CA and you remove the old after a short while.

If missing servers is a common problem it sounds like there are some other fundamental problems outside just authenticated user sessions.

Re: Open-sourcing OpenPubkey SSH (OPKSSH): integrating single sign-on with SSH

#94

Post by lq9AJ8yrfs »

p_l wrote: post #72
rcarmo wrote: post #45

Earlier quoted context omitted.

That is one of the things that OIDC sorta almost never really managed to pull off consistently.

One time I actually implemented that on OIDC... by having the OIDC login page do a kerberos login :D this meant that at most you had a short flash on screen for web apps... which is a bit like OIDC/SAML login on windows domains (but I did it with keycloak back then)

Authentik supports this [1] too, kinda. It seems you can set it up to register you based on a bona fide kerberos auth, and logs you in (maybe? would have to check) with kerberos but seems to keep a parallel synchronized authenticator in its own database for OIDC and "modern" auth. Doesn't seem to embed kerberos-isms as "claims" in OIDC either. Might be awesome if it did? Or terrible, depending on how you look at it.

[1] https://docs.goauthentik.io/docs/users-sources/sources/proto...

Re: Open-sourcing OpenPubkey SSH (OPKSSH): integrating single sign-on with SSH

#95

Post by XorNot »

lxgr wrote: post #54
dcow wrote: post #38

Earlier quoted context omitted.

Doesn’t this require the server to consult the IDP on every log in, though, to make sure the id token is valid? One of the staples of ssh from a UX standpoint is that it’s peer to peer.

I suppose you could do something based on IDP-signed tokens, e.g. "valid for authentication to service x until "?

Kerberos tickets have timeouts on them already, it's a matter of configuration how long you wait.

The thing is most enterprises want "user disabled" to be instant.

Which of course leads to SSH keys all over the place anyway.

Re: Open-sourcing OpenPubkey SSH (OPKSSH): integrating single sign-on with SSH

#96

Post by EthanHeilman »

c45y wrote: post #93
EthanHeilman wrote: post #28

Earlier quoted context omitted.

The benefits of this is that you don't have the attack surface of an SSH CA. If you do this with an SSH CA that supports OIDC, if either the IDP or the SSH CA are compromised then security is lost. With OpenPubkey and by extension opkssh, your IDP is functioning like the SSH CA by signing the public key that you make the SSH connection with. Thus, you have one fewer trusted party and you don't have maintain and secur…

You can have multiple trusted CAs which I've found to make rotation a non issue with tooling like Ansible etc. New CA is minted, public key is added to the accepted list, client signing start using the new CA and you remove the old after a short while. If missing servers is a common problem it sounds like there are some other fundamental problems outside just authenticated user sessions.

That's smart! You could probably automate that using a cron job pulling the latest CA public keys so servers automatically rotates CA public keys every few days.

> If missing servers is a common problem it sounds like there are some other fundamental problems outside just authenticated user sessions.

On one hand yes, on the other hand that is just the current reality in large enterprises. Consider this quote from Tatu Ylonen's (Inventor of SSH) recent paper [0]

“In many organizations – even very security-conscious organizations – there are many times more obsolete authorized keys than they have employees. Worse, authorized keys generally grant command-line shell access, which in itself is often considered privileged. We have found that in many organizations about 10% of the authorized keys grant root or administrator access. SSH keys never expire.”

If authorized keys get missed, servers are going to get missed.

opkssh was partially inspired by the challenges presented in this paper.

[0]: Challenges in Managing SSH Keys – and a Call for Solutions https://ylonen.org/papers/ssh-key-challenges.pdf

Re: Open-sourcing OpenPubkey SSH (OPKSSH): integrating single sign-on with SSH

#97

Post by EthanHeilman »

jrozner wrote: post #89
EthanHeilman wrote: post #16

Earlier quoted context omitted.

> This seems like dubious statement. SSH authentication does not need to be key based. Let's say you just use an ID Token as a bearer token to authenticate to SSH. The SSH server now has the secret you used to authenticate with. Doesn't this introduce replay attacks where the SSH server can replay your ID Token to log into other SSH servers? Whereas if your ID Token functions like a "certificate" issued by your IDP b…

I think it's interesting they're choosing to use certificates this way. If they're already using certs, why not just leverage sshca auth? Also, at the end of the day, it's still effectively a bearer token. I founded a company called Based Security last year in this space. We're looking for design partners currently. We host a CA for you (or you can host yourself if you want) and use ssh certificates and bind the user…

> Why not just leverage sshca auth?

Because that has two trusted parties: the IDP and the SSH CA. OPKSSH has just one trusted party: the IDP.

> This ensures that the user is both in possession of the physical device and that the credential can't be stolen without stealing the device, unlike the bearer token examples here. Currently we're offering support for GitHub and GitLab authentication but it works out of the box with standard ssh tooling as well. It just currently requires manually handling user provisioning for standard ssh access.

That sounds valuable.

Have you looked in OpenPubkey, the cosigner protocol supports binding hardware tokens to ID Tokens? Although not as fancy as having the SSH key pair live in the hardware token but maybe we could figure out a way to get the best of both worlds.

Re: Open-sourcing OpenPubkey SSH (OPKSSH): integrating single sign-on with SSH

#99

Post by _hyn3 »

How does this compare to Userify's plain-jane SSH key technique?

That agent (Python, single-file https://github.com/userify/shim) sticks with decentralized regular keys and only centralizes the control plane, which seems to be more reliable in case your auth server goes offline - you can still login to your servers (obviously no new users or updates to existing keys). It just automates user and sudo configuration using things like adduser and /etc/sudoers.d. (It also actively kills user sessions and removes the user account when they're deleted, which is great for when you're walking someone out in case they have cron-jobs or a long-running tmux session with a revenge script.)

This project looks powerful but with a lot of heavy dependencies, which seem like an increased surface area (like Userify's Active Directory integration, but at least that's optional)

Re: Open-sourcing OpenPubkey SSH (OPKSSH): integrating single sign-on with SSH

#100

Post by ale42 »

mdaniel wrote: post #49
EthanHeilman wrote: post #47

Earlier quoted context omitted.

Excellent point, SSH agent is a feature I've wanted to build for a while now but there was higher priority features. It will probably be included in the next major release. Would you put up for submitting it as a PR?

If I were still using SSH, maybe[1] but I'm thankful that I haven't used SSH in several years. I guess I also dodged a bullet by getting out before the Vault rug pull, since that would have made my life painful 1: although I don't think I'm the target audience for trail-blazing SSH auth; am a much, much bigger fan of just using X509 CA auth using short-term certs; it's much easier to reason about IMHO

Out of curiosity, what are you using now? Or do you mean you don't need remote terminals any more because you work on other stuff?
Post reply on HN