I can't shake the feeling that Tailscale's SSH authentication mechanism is at the wrong layer of the stack. It appears to work by looking at the (source, dest) IP address pair and mapping that to a Tailscale identity. But this may mean that any user or anyone who can initiate TCP connections from an authenticated user's IP can authenticate to the destination over Tailscale SSH.
If Tailscale's client was a userspace construct bound to a specific user SSH program, maybe fine. But Tailscale's client is a regular VPN client. What happens if you connect to the Tailscale VPN, open a malicious but sandboxed app of some sort, and that app connects to the target on TCP port 22.
For all that it's a seriously unfinished product, Cloudflare's SSH offering seems better thought out. Perhaps Tailscale should find a way to issue a short-lived certificate and use that in addition?
(It looks like regular sshd could almost be convinced to handle this. If the SSH_CONNECTION environment variable were passed to the AuthorizedPrincipalsCommand helper or if the source and destination were available as '%' tokens, then AuthorizedPrincipalsCommand could do the Tailscale tuple lookup and use it as a second factor in addition to a short-lived certificate (or regular SSH key or whatever). I bet openssh would accept a patch for this.)
I feel like there should be a lightweight way to use SSH certificates, so you could use it independently or on top of Tailscale.
Like a server (CA), client and daemon on your machines that should be reachable via SSH that handles short lived certs and authentication of clients. But I'm not aware of anything like that.
I have used Teleport before but it seemed not that great for machines not publicly reachable, because then all the traffic goes through a proxy.
Smallstep and cloudflared do this. Sadly, both of them seem to use essentially identical client-side hacks. Smallstep is a small company that I wouldn’t trust with the keys to the kingdom, and Cloudflare seems to treat their SSH product as something thrown over the fence with nothing resembling support.
Gravitational’s Teleport seems pretty good, but it’s heavyweight and doesn’t have any pricing appropriate for small businesses.
Think about this a bit. Contemplate what happens if you use sftp, vscode remoting, or anything else nontrivial. Hint: “cloudflared access ssh-gen” is not actually any sort of proxy, and the ssh -tt command is a kludge that should, if openssh were more on the ball about inherited file descriptors, should not work at all.
The right way to to this is to use Match … exec. Or to ask openssh to add an option for a command to execute before reading IdentityFile. Or to ask for an IdentityFileCommand option. Or to use a custom ssh agent.
A step-up prompt or notification wouldn't be a bad idea to approve ssh connections before they are established -- This is the same issue with ssh agents. I think there's an ACL setting in tailscale where you check ssh connections with a re-auth. it's time-based with a minimum of 1 minute though.
Tailscale SSH's check mode (https://tailscale.com/kb/1193/tailscale-ssh/#configure-tails...) is meant to address the issue of "rogue process starts an SSH connection". For truly sensitive applications, you can set the check period to be "1s" to always require it.
Hmm. If the problem is that Tailscale SSH doesn’t strongly associate the person authenticating with the connection being authenticated, asking the person to reauthenticate seems like a pretty weak solution.
Unless I'm misunderstanding something, the check solution creates that strong association. Logging in gives you a link you have to go to and auth, authing let's your session connect. Disconnect, and you have to do this again.
No check mode reuses the auth of the tailscale client, check mode authenticates the ssh connection itself
And then that tailscale client is authorized to log in over ssh for however long the check lasts, and anyone else who can initiate a TCP session over the link can also get in.
If Tailscale's client was a userspace construct bound to a specific user SSH program, maybe fine. But Tailscale's client is a regular VPN client. What happens if you connect to the Tailscale VPN, open a malicious but sandboxed app of some sort, and that app connects to the target on TCP port 22.
For all that it's a seriously unfinished product, Cloudflare's SSH offering seems better thought out. Perhaps Tailscale should find a way to issue a short-lived certificate and use that in addition?
(It looks like regular sshd could almost be convinced to handle this. If the SSH_CONNECTION environment variable were passed to the AuthorizedPrincipalsCommand helper or if the source and destination were available as '%' tokens, then AuthorizedPrincipalsCommand could do the Tailscale tuple lookup and use it as a second factor in addition to a short-lived certificate (or regular SSH key or whatever). I bet openssh would accept a patch for this.)