How do you "untrust" a single person's key under this scheme? You would have to visit all of the machines and remove them from the authorized keys file.
Not really, with an SSH CA you’re trusting the CA and not installing individual keys into authorized_keys files.
Anything signed by the SSH CA will work for logins.
To deal with the “untrust” issue it’s normal for operations with an SSH CA to rely on (very) short-lived certificates, meaning often issued and valid for < 24 hours (it’s configurable, I’ve seen this be as short as 30 minutes).
Smallstep wrote a summary here which is pretty good —
> To deal with the “untrust” issue it’s normal for operations with an SSH CA to rely on (very) short-lived certificates, meaning often issued and valid for < 24 hours (it’s configurable, I’ve seen this be as short as 30 minutes).
So you want a way to get rid of long-lived SSH certificates, instead authenticating users with your corporate single-sign-on system then issuing them a temporary credential?
And presumably you've got some audit logs, so you know who connected to what, when and why. Perhaps a familiar command line tool, that makes temporary credential rotation easy for users? Perhaps some paperwork to hand to your SOC2 compliance auditors?
I mean, this is sounding a lot like tailscale ssh, teleport, and suchlike...
Tailscale doesn't need special handling for SSH. You can run your plain old sshd just fine.
Tailscale comes with an additional SSH server, which runs in parallel with your other SSH server. It does use Wireguard keys directly, so effectively you don't need to manage keys.
Additionally, this SSH server is implemented in userspace, so it won't (can't) interfere with anything else on your system (like your other sshd).
The 'tailscale ssh' command is an optional wrapper around the system 'ssh'
command that's useful in some cases. Tailscale SSH does not require its use;
most users running the Tailscale SSH server will prefer to just use the normal
'ssh' command or their normal SSH client.
The 'tailscale ssh' wrapper adds a few things:
* It resolves the destination server name in its arguments using MagicDNS,
even if --accept-dns=false.
* It works in userspace-networking mode, by supplying a ProxyCommand to the
system 'ssh' command that connects via a pipe through tailscaled.
* It automatically checks the destination server's SSH host key against the
node's SSH host key as advertised via the Tailscale coordination server.
It is about using SSO and tagging to auth the users.
So for example you could have instances tagged with {users} that cannot ssh to certain boxes, but other users tagged with {admin} that can. All these users can be part of your tailnet.
Tailscale gives you authorized connectivity between hosts, and DNS; won't it be sufficient to run plain sshd?
(If wireguard-key-level auth were sufficient, even rlogin or netcat would be enough, because the transport is encrypted already.)