Can't get Cloudflare Access to play nicely with SSH via cloudflared/Argo tunnel

Security Access
#1

I’m exposing SSH over an Argo tunnel using a local cloudflared instance with the following ingress stanza:

ingress:
  - hostname:      ssh.example.com
     service:      ssh://localhost:22

Using the following proxycommand (in PuTTY on Win) works just fine:

cloudflared.exe access ssh --hostname %host

So invoking an SSH session connects just fine and looking at last on the host I can see the connection has been made from localhost (i.e. from the local cloudflared process) so all is well in the world and everything is working as expected.

BUT, as soon as go into the Teams Dashboard and try to apply an Access Application rule matching ssh.example.com, my client won’t connect. Doesn’t matter if the Rule is based on user, country etc.,nothing allows the proxy to connect.

Is there a special ‘Application type’ of SSH or something I need to use which I’m not seeing in my GUI? Presently I’m just creating a ‘Self-hosted application’ and maybe that’s confusing things by making the tunnel ‘webby’ instead of for SSH?

Does anyone have a working Access Policy documented I can try?

#2

Any error message? A browser pop-up should appear automatically that asks you to authenticate via Cloudflare Access.

This is correct.

Did you read this part:

#3

I’ve read as much as I can find including that article yes, but no dice. I have to say there is a little ambiguity inasmuch as it could be interpreted within some docs that the username on the backend must match the localpart of the authenticated user but I think this is only if you use cert-based authentication instead of just using cloudflared as a proxy alongside normal public-key/password authentication from the client. It doesn’t make sense in any other context but just throwing that out there as something I’ve ruled out as it’s in your link.

Per your question, I’m not actually getting a browser any more (presumably I’ve got some kind of auth cached somewhere), which is another weirdness. It’s the same if I have an Access policy in place or not though so that in and of itself isn’t my current issue (I don’t think).

Presently with an Access Policy defined, if I run the following proxy command manually:

cloudflared.exe access ssh --hostname ssh.example.com

I get the error message:

websocket: bad handshake

which seems to imply it is doing something more webby than I’d expect - when the same command is run without an Access policy defined for the ssh.example.com hostname I get the server response passed downstream from cloudflared, as expected, i.e:

SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.1

To me it looks like having that policy makes the cloudflared respond as if this is a service=https request instead of service=ssh. I’m sure I’m just doing something dumb as it looks like it should be so easy.

Do you have this setup working? If so, is it working right now? Could just be in the middle of an issue??

#4

I’m going to put this down to stupidity on my part.

I’d tried deleting individual cloudflared tokens during testing to no avail. Turns out that deleting the one for my Access org along with that for the resource in question got me working. Must be something to do with when I was authorised in relation to what I needed to access that resource at the time or something???

Anyway, all working and it is as easy as it looks… Thanks for letting me bounce some ideas off you, Eric. Much appreciated!

1 Like
#5

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.