Feedback for Cloudflare's Zero Trust browser-based SSH client

Earlier today we launched support for a new workflow which renders an SSH client in a user’s browser. The session is connected by Argo Tunnel and protected by Cloudflare Access, but only takes a single click for an end user and requires no additional configuration. Coming soon we’ll be adding new logging and audit controls as well. You can learn more about the announcement here.

How can I get started?

How can I send feedback?
We need your feedback! We’re using this thread to collect feedback and answer questions about this new feature.


Just found the setting in the dashboard, great!

And it works quite well, except one thing: by default Cloudflare will login to my SSH as my email address username (e.g. my email address is [email protected] then I’m logged in as abc user)

Hopefully there’s a way to allow us to login as a different username :smile:

Edit: I noticed that Cloudflare will login as my email address username if I have short-lived certificates enabled :smile: so I think that make sense.

For SSH servers without short-lived certificates enabled, Cloudflare will ask for my username and password (or SSH key) to authenticate.

Some other suggestions:

  • I would like to see a “disconnect” button maybe at the bottom of the window to terminate the session rather than clicking the “x” button on the browser tab.
  • The browser tab does not automatically close if I type exit in the terminal window to terminate the session. Hopefully the SSH window can handle this.

What a cool feature, if possible for pro/business customers, I will be checking this feature tomorrow.

That wasn’t possible even before doing it via the terminal. It was always logging you in with the username of the email.

Yep, I totally forgot that I configured short-lived certificates years ago :laughing:


It would seem to me that if my SSH server is key-only, the Username/Password approach won’t work. I guess I’ll have to add my private key to 1Password so I can paste it in.

What…short-lived certificates (which I’ve never used)?


Yes, it’s going to use the first part of the email as user + a generated ssh key.


Very interesting news! Thanks for your innovation.

How would you recommend us to setup zero trust and the browser based SSH-client given the following configuration today?

  • Ubuntu 18.04 hosted in VMWare by our hosting partner.
  • Around 12 servers and currently 6 staff that need access (excluding hosting partner staff).
  • Two Windows Server but no AD.
  • subnets - prod, test, vpn.
  • There is no LDAP or similar access managment for our servers
  • We have Azure AD with MFA and Office 365 for all staff but it’s only used for Cloudflare Access to limit public access to some test environments today.
  • Our staff has VPN with personal client certificate and password to reach the server network.
  • All with server access also have their own ssh-key and all public key are copied to each individual server (that you have access too).
  • There is only one shared sysadmin account created on servers today. Different strong password per server but same username. All public keys are connected to that username.
  • Default for SSH is that both password and key is disabled.
  • For the VPN subnet only SSH login with key is enabled. So if you can to connect VPN and have a matching private key you get access. Do you know the servers password you can do sudo too. :slight_smile:
  • There is also a separate break glass account and SSH with password is allowed from a specific jump server used by our hosting provider and their on call staff - we do not control this part.

Primary Goal is to get rid of VPN completely. It is a pain to setup, manage and it seems that it is always magically broken on your computer when there is an emergency so you need SSH access.

Developers also need access to mongodb and MySQL on test subnet to get rid of VPN.

Secondary Goal would be to remove user management from each server and handle it with SSO. Not having to copy/delete public keys to all servers or creating user accounts on each server. Something we ask our hosting provider to manage for us today and it costs an hour each time…

Any tips and hints on good practices are welcome.

1 Like

Thanks for the feedback! I like the idea about closing via exit and just general exit flow cases.


Sure thing.


Noticed if you change e.g. who can use it, edit access policy in it removes this setting. Meaning “Enable browser rendering”. Have to go back to and enable it again.

1 Like

Thanks @SamRhea updated my Cloudflare Tunnel guide with browser terminal setup as well working nicely so far :slight_smile:


One thing I noticed is server’s /var/log/secure reports logins via browser as being from I guess due to the tunnel so can’t see the actual login IP from origin side

Accepted password for root from port 42978 ssh2

I don’t see why the login address would differ from a regular tunnel SSH connection. My non-Access SSH over regular terminal shows ::1 (IPv6 localhost).

I guess it’s just I don’t usually tunnel my SSH access so see the actual login IPs as does my server firewall see that login IP

I simply cannot get it to work!

I followed the guides: Defined Access policies to a subdomain and enabled browser-based rendering, set up a tunnel, made cloudflared config policies on the origin, setup CNAME DNS record to the DNS records page, and ran the tunnel and the tunnel is running successfully. I’ve also verified if the routing works by running cloudflared tunnel ingress rule command and the expected rule is being matched.

While the tunnel is running from a console, I hit the configured subdomain and was presented with a blank screen. It appears that the server is sending CSP headers that are non-compatible with the browser-based SSH setup. As this is a CNAME pointing directly to (tunnel), these are not set by my origin.

Further, having rocket loader enabled completely results in a blank page, with the following error logged on the console:

No other client-side browser extensions (eg: adblock) are interfering with any elements.

So I went ahead and disabled Rocket loader, and now the page rendered, but with the following error:

Refused to execute inline script because it violates the following Content Security Policy directive: “script-src ‘self’ ‘unsafe-eval’”. Either the ‘unsafe-inline’ keyword, a hash (‘sha256-1QGch0/bwo+wwI5GJmPTC/dkHvK8JJsBW8NMtVlLIIc=’), or a nonce (‘nonce-…’) is required to enable inline execution.

on line 15 of the client-rendered SSH code.

I’m not defining or overriding the headers/response sent, say, via workers.
There are no errors logged in the tunnel console, such as when there’s a misconfiguration, with a Ray-ID. I’ve fully followed the official guides (mentioned in the initial post).

After disabling the rocket loader, I’m getting an error that something went wrong and the engineers are notified (as opposed to a blank page, earlier)

What could be the possible issue here? CSP? as it is sill blocking some resources from being loaded…


1 Like

Thanks for the report - we’ve found the issue that causes this error and should have a fix out by EOD Monday.


UPDATE: It turns out that because I have “Bypass” set up for my home IP address, it skips the Access login phase, which is probably what triggers the SSH in terminal feature. It’d be nice if the SSH Terminal feature would be smart enough to know that it’s an SSH connection then put me in Username/Password mode. If I get rid of that Bypass rule, I have to jump through another hoop to use SSH from my local terminal. So I’ll keep the Bypass rule, and not use Browser SSH when at home.

Just by toggling my SSH Access app, it’s supposed to work? The hostname I SSH to through cloudflared is showing this in my journalctl log:

> Apr 18 07:15:08 MACHINE_HOSTNAME cloudflared[617]: 2021-04-18T14:15:08Z ERR localhost:22 is not a http service
> Apr 18 07:15:08 MACHINE_HOSTNAME cloudflared[617]: 2021-04-18T14:15:08Z ERR CF-RAY: 641e80e6ebd242cb-LAX Proxying to ingress 1 error: Not a http service

Here’s the ingress entry in config.yml:

  - hostname:
    service: ssh://localhost:22

Hi @SamRhea,

Can you confirm if a fix has been rolled out yet?
I’m still having issues, following the official guide.


Not just yet - still working on it on our side. We’ll update this thread when it’s ready. Do you have bot detection or browser insights enabled on the zone? If so, this appears to be limited to features that rely on scripts Cloudflare injects and disabling those for the time being would address the problem while we work on a more long-term fix.