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

111–120 of 156 posts

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

#111

Post by EthanHeilman »

godelski wrote: post #105
EthanHeilman wrote: post #80

Earlier quoted context omitted.

I work on opkssh and I agree with everything you have just said. The value of opkssh makes sense in an environment in which already have OpenID Connect as the foundation for identity in your system. OpenPubkey[0], the protocol opkssh is built on, supports cosigners, which parallel identity attestations. OpenPubkey is currently is designed to use cosigners purely for security, i.e., to remove the IDP as a single point…

Thanks for the response! And glad to hear I'm not just going crazy here hahaha. I'm glad to hear that the protocol supports cosigners. (Next part is definitely described poorly) Is there going to be expansion so that there are "super authorities"? I'm thinking something like how tailscale's taillock works. So there are authorities that can allow access but super-authorities that allow for the most sensitive operation…

Super authorities are a neat idea. It would be nice to have something like 2of2 permissions where two parties have to both ok a change for policy to accept it.

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

#112

Post by atonse »

tptacek wrote: post #83
EthanHeilman wrote: post #81

Earlier quoted context omitted.

Is audit logs and access control the main features that would convince you to use Teleport vs something like opkssh? How important is the VPN functionality that lets you get packets to private IPs?

I like that it's written in a memory-safe language too, but the killer feature is definitely the audit logs. We keep all this stuff behind WireGuard, which is what I would recommend everybody do.

We use Tailscale for our WireGuard, which further integrates with SSO. So it’s a double whammy.

But Tailscale ssh has the identity stuff built in too.

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

#113

Post by [deleted] »

c45y wrote: post #92
_cenw wrote: post #42

Earlier quoted context omitted.

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.

[deleted]

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

#114

Post by p_l »

lq9AJ8yrfs wrote: post #94
p_l wrote: post #72

Earlier quoted context omitted.

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

MIT Kerberos can authenticate using OIDC created token, but in my case I essentially authenticated to Keycloak with HTTP Negotiate with Kerberos, then based on data from LDAP (that was also used by Kerberos) I generated appropriate OIDC token.

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

#116

Post by TacticalCoder »

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…

[dead]

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

#117

Post by linkregister »

fc417fc802 wrote: post #109
EthanHeilman wrote: post #107

Earlier quoted context omitted.

All the major OpenID Provider want you to use a browser so that users aren't exposing their raw credentials like passwords to an application. We did have an experimental version of this working in a terminal for integration tests a long time ago, but Google views that as malicious behavior and tries to prevent you from doing that. It turns into an arms race with the IdPs. The good news is you only have to login throu…

The browser is also an application. Of course I somehow doubt ELinks will be working with the Google auth page anytime soon. It seems that the goal is to minimize the number of applications into which users view entering their credentials as "normal". The obvious missing piece then is some standardized FOSS project to handle CLI login. Of course that is also unlikely to go over well since what the centralized provide…

I wrote a proprietary variation of this project for a large organization and used a similar approach to the author. The primary reason I used the browser for authentication was to take advantage of FIDO U2F (Yubikeys). Openssh does support U2F authentication, but it requires the user to sign a public key with the hardware device, forcing the organization to again store users' public keys.

The users disliked the redirects to and from the MFA provider just to log in and receive a signed SSH certificate, but there was no practical way to perform logins in the terminal without creating a whole new protocol and expanding the timeline of the project.

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

#118

Post by EthanHeilman »

jrozner wrote: post #102
EthanHeilman wrote: post #97

Earlier quoted context omitted.

> 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 bo…

I can understand the concern about having a second trusted party but think that the value of utilizing the standard ssh ca auth flow is worth the potential risk. If you require keys in attested hardware and verify that before issuing certs, the actual attack becomes very difficult. You need to compromise the actual hardware or compromise the CA in a pretty substantial way to issue certs to untrusted private keys. The…

That documentation refers to a much older and closed source version of opkssh.

> It seems like to use OpenPubKey you also need a fairly modern version of OpenSSH.

On versions of OpenSSH older than 8.1 (2019), you may run into issues if you have a huge ID Token. That shouldn't be a problem for standard sized ID Tokens, some enterprise OIDC solutions put the phone book in an ID Token and we have to care about that.

> It also requires that the user authenticating have sudo access on the machine, which doesn't sound great.

The user authenticating does not need sudo access. You only need sudo access to install it. You need sudo to install most software in on servers.

> It's not clear to me whether it's possible for the existing authorized_keys file to co-exist or whether that's just to stop access using existing keys

opkssh works just fine in parallel to authorized_keys. We are using AuthorizedKeyCommand config option in sshd_config, so opkssh functions like an additional authorized_keys file. My recommendation is that you use authorized_keys as a breakglass mechanism.

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

#119

Post by linkregister »

EthanHeilman wrote: post #47
mdaniel wrote: post #23

Earlier quoted context omitted.

I'm surprised it defaults to writing out key material into the filesystem[1] when SSH Agent has existed for quite a while. This use case seems especially relevant to sticking them in the agent given that (IIUC) these are short-lived certs anyway, so if your agent bounced you'd just get a fresh one without drama I do see https://github.com/openpubkey/opkssh/issues/6#issuecomment-2... > so I'm glad it's conceptually on…

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?

That sounds like an interesting feature to write. Is there an open issue for it?

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

#120

Post by mdaniel »

ale42 wrote: post #100
mdaniel wrote: post #49

Earlier quoted context omitted.

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?

All SSM, all the way. I even gravely considered using their IAM Anywhere capabilities to jump onto Azure or GCP instances, before that project was overcome by events

I'm cheating you a little bit, though, because for the most part once a VM gets kubelet on it, I'm off to the races. Only in very, very, very bad circumstances does getting on the actual Node help me

I also recently have started using https://docs.aws.amazon.com/systems-manager/latest/userguide...> to even get sequestered cluster access via $(aws ssm start-session --document-name AWS-StartPortForwardingSessionToRemoteHost) although the "bootstrapping" problem of finding the instance-id to feed into --target is a pain. I wish they offered https://docs.aws.amazon.com/systems-manager/latest/userguide... in the spirit of "yeah, yeah, just pick one" versus making me run $(aws ec2 describe-instances --filter | head -n1) type thing

Post reply on HN