This is neat, and more people should be doing things like this. For what it's worth, we use (and like) Teleport, which does certificate-based SSH authentication; an SSO auth gets you a short-lived certificate. It also has the benefits of access control and (most importantly) audit logs; a generic reliable audit log for SSH sessions is a powerful tool to have for compliance stuff, since it transitively gives you an au…
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?
This is neat, and more people should be doing things like this. For what it's worth, we use (and like) Teleport, which does certificate-based SSH authentication; an SSO auth gets you a short-lived certificate. It also has the benefits of access control and (most importantly) audit logs; a generic reliable audit log for SSH sessions is a powerful tool to have for compliance stuff, since it transitively gives you an au…
The open source version supports only GitHub SSO, is that your provider?
This is neat, and more people should be doing things like this. For what it's worth, we use (and like) Teleport, which does certificate-based SSH authentication; an SSO auth gets you a short-lived certificate. It also has the benefits of access control and (most importantly) audit logs; a generic reliable audit log for SSH sessions is a powerful tool to have for compliance stuff, since it transitively gives you an au…
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.
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 "?
Yeah, I don't like this approach either. There was a lot of plumbing added to sshd to support pluggable auth methods, and having used a few of them (including TOTP, for instance), I am not really a fan of "extending" publickey. (Am also not really a fan of having to eventually use a browser for authenticating a terminal session, but that's another problem.)
not just a browser - but coupled with the javascript-as-an-operatingsystem which first assumes you are a bot, but then you prove to it that you are not. lol
They reject the proofs now: they just show the spinner spinning indefinitely now. CloudFlare is broken and it has widespread so much that it looks like a cancer.
> (Am also not really a fan of having to eventually use a browser for authenticating a terminal session, but that's another problem.) That sounds awful, I hope this is not the direction we are heading towards.
It happens when there's a cloudflared instance. It is quite annoying
That is insane to me. It really requires a browser for a terminal session? No alternatives? Why does it require a browser?
Yeah, I don't like this approach either. There was a lot of plumbing added to sshd to support pluggable auth methods, and having used a few of them (including TOTP, for instance), I am not really a fan of "extending" publickey. (Am also not really a fan of having to eventually use a browser for authenticating a terminal session, but that's another problem.)
> (Am also not really a fan of having to eventually use a browser for authenticating a terminal session, but that's another problem.) That sounds awful, I hope this is not the direction we are heading towards.
You can actually have a fully command-line driven Single Sign-On workflow, even anchored in hardware (TouchID, FIDO tokens, etc.)
It's not a common way to do it, but it's definitely a possibility.
> (Am also not really a fan of having to eventually use a browser for authenticating a terminal session, but that's another problem.) That sounds awful, I hope this is not the direction we are heading towards.
You can actually have a fully command-line driven Single Sign-On workflow, even anchored in hardware (TouchID, FIDO tokens, etc.) It's not a common way to do it, but it's definitely a possibility.
Like Yubikeys? I've always wanted to get one. My workflow does not require a browser though, thankfully.
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…
> 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 identity (oidc to the IdP) to a physical device (yubikey, secure enclave, tpm, etc.) 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.
I'd love to see the central repository to be breached and tons of computers get new users instantly. I mean, the idea is nice. There's an alternative implementation being used already in some parts of the world, but their own OIDC provider of their choice. Decentralization is the key here . I can neither confirm nor deny the pun is intended.
If you lose your root CA certificate you sure are done for too. Is it better than passwords? 100% - is it perfect? It does not have to be for a lot of use cases.
Or you can use a local installation with even less risk.