I have a domain
potato.com that has different services running on
xyz.potato.com where xyz is the name of service. Each service runs on a droplet in digital ocean.
I want to use cf access to give only authorized people SSH access to the backend servers.
There are two interfaces for configuring this. One is the Access Tab in
dash.cloudflare.com but if I understand correctly, It’s missing a lot of settings(I can’t really configure a Access Group there) and another is in
Which interface am I supposed to use to configure this?
Preferably, I want to use
ssh.<service>.instadapp.io domain as the facilitator for SSH but I am very open to other ideas as well.
Then, There is a lot of confusion in how to configure it. There is,
- Short lived certificates, https://developers.cloudflare.com/access/ssh/short-live-cert-server/
- SSH Connections, https://developers.cloudflare.com/access/ssh/ssh-guide/
They both seem to be doing the same thing so, What approach should I take? What is the preferred way of doing this?
Is there a way to access all my services at
ssh.<service>.cloudflare.com? Is there any more simpler documentation on how to configure this? We have a internal VPN configured with wireguard, It’s a pretty terrible setup and we are trying to move away from it.
I also tried Spectrum but all our servers listen on port 4556 for SSH and there doesn’t seem to be a way to configure port in spectrum. Plus, This will expose all the actual IP addresses of our backend servers/droplets since you have to configure spectrum on a subdomain which then opens them up to a lot of unwanted ssh traffic, Not that that’s a huge problem. I just prefer cf access approach where users have to authorize with the CF access portal before they are allowed in compared to Spectrum. But then, I am no expert and I will be happy to hear from everyone else on how it should be done.
Hi! Sam from Cloudflare here.
You can use either interface, but we recommend
dash.teams.cloudflare.com where new features are being added and we’re addressing some confusion.
Short-lived certificates are an optional additional feature that you can add to securing SSH with Cloudflare Access. You do not need to use it to use the SSH in Access flow.
You will need to run
cloudflared on each machine that you want to secure with Access, and assign each a unique hostname, but you can build an Access policy that wildcards those machines. You can also use the SSH flow as a bastion host model if preferred.
Hi All and @SamRhea,
Can anyone help with below concerns re: Ubuntu 20.04 server and SSH via Access with short lived certificate that is working but:
server still prompts for password. If I turn off password authentication the login is rejected with error “Permission denied (publickey)”
SSH via Access is described as using Argo tunnel however executing “cloudflared tunnel list” on the server states no tunnels configured?
cloudflared is described as protecting the server IP but if I turn off the hardware firewall rules that allow only cloudflare IP ranges I’m able to ssh in using the server IP?
No inbound rules necessary since cloudflared already creates an outbound tunnel connection to Cloudflare edge network, and the tunnel connection is persistent.
You can just block incoming SSH (port 22) connection from the Internet.
Many thanks @erictung
My issue with public key authentication seems to be down to Authorized Principal:
auth.log error - Certificate invalid: name is not a listed principal
I followed the Access - SSH doc and have a working connection through cloudflare, however, the server still prompts for a password. My understanding is that this workflow creates a legacy tunnel. I certainly had to use --legacy flag to install cloudflared as a service, otherwise it was prompting for tunnel details. I’m trying to use a short lived certificate for SSH. Both token and cert update on my client machine for each connection attempt.
Server auth.log error reported - Certificate invalid: name is not a listed principal
Ubuntu 20.04 man page talks about sshd_config needing an authorized principals file when using ca auth:
Specifies a file that lists principal names that are accepted for certificate
authentication. When using certificates signed by a key listed in
TrustedUserCAKeys, this file lists names, one of which must appear in the
certificate for it to be accepted for authentication.
My last thought is that the authentication email part before the hash is carried through to the cert by cloudfare and it is this that I should list in that file. The Access - SSH workflow doc doesnt mention needing to configure this though
Hi @SamRhea @erictung
Configuring an AuthorizedPrincipalsFile with usernames - one per line - has sorted it.
Firewall as configured seems fine. References in the docs to the tunnel seems to refer to legacy version that does not appear in “cloudflared tunnel list” output.
Thank you both for responding.