Connect with self-managed SSH keys

If you want to manage your own SSH keys, you can use Cloudflare Tunnel to create a secure, outbound-only connection from your server to Cloudflare's global network. This requires running the cloudflared daemon on the server (or any other host machine within the private network). Users with SSH keys that are trusted by the SSH server can access the server by installing the Cloudflare WARP client on their device and enrolling in your Zero Trust organization. Users can SSH directly to the server's private hostname (for example, ssh.internal.local). You control access to the server using network-level Gateway policies instead of application-level Access policies.

Note

If you want to create more granular policies, allow Cloudflare to manage SSH keys for you, or to obtain command logs, consider using Access for Infrastructure instead.

Prerequisites

• A Cloudflare Zero Trust organization
• WARP client installed on user devices.
• Devices enrolled in your Zero Trust organization

1. Create an example SSH server

This example walks through how to set up an SSH server on a Google Cloud Platform (GCP) virtual machine (VM), but you can use any machine that supports SSH connections. If you already have an SSH server configured, you can skip to Step 2.

1.1 Create an SSH key pair

Before creating your VM instance you will need to create an SSH key pair.

1. Open a terminal and type the following command:

   ssh-keygen -t rsa -f ~/.ssh/gcp_ssh -C <username in GCP>

2. Enter your passphrase when prompted. It will need to be entered twice.

   Two files will be generated: gcp_ssh which contains the private key, and gcp_ssh.pub which contains the public key.

3. In the command line, enter:

   cat ~/.ssh/gcp_ssh.pub

4. Copy the output. This will be used when creating the VM instance in GCP.

1.2 Create a VM instance in GCP

Now that the SSH key pair has been created, you can create a VM instance.

1. In your Google Cloud Console ↗, create a new project ↗.
2. Go to Compute Engine > VM instances.
3. Select Create instance.
4. Name your VM instance, for example ssh-server.
5. Scroll down to Advanced options > Security > Manage Access.
6. Under Add manually generated SSH keys, select Add item and paste the public key that you have created.
7. Select Create.
8. Once your VM instance is running, open the dropdown next to SSH and select Open in browser window.

Note

In order to be able to establish an SSH connection, do not enable OS Login ↗ on the VM instance.

2. Connect the server to Cloudflare

This section covers how to create a new Cloudflare Tunnel for your SSH server. You can reuse the same tunnel for all services on a private network that are reachable from the cloudflared host.

1. Log in to Cloudflare One ↗ and go to Networks > Connectors > Cloudflare Tunnels.

2. Select Create a tunnel.

3. Choose Cloudflared for the connector type and select Next.

4. Enter a name for your tunnel. We suggest choosing a name that reflects the type of resources you want to connect through this tunnel (for example, enterprise-VPC-01).

5. Select Save tunnel.

6. Next, you will need to install cloudflared and run it. To do so, check that the environment under Choose an environment reflects the operating system on your machine, then copy the command in the box below and paste it into a terminal window. Run the command.

7. Once the command has finished running, your connector will appear in Cloudflare One.

   

8. Select Next.

3. Use hostname routes

Hostname routes allow you to SSH directly to ssh.internal.local without managing static IP routes. Hostname routes are especially useful when your SSH server has an unknown or ephemeral IP address, such as dynamic infrastructure provisioned by cloud providers.

How hostame routing works

When you create a hostname route in Cloudflare Tunnel:

1. Users SSH to your private hostname (for example, ssh user@ssh.internal.local).
2. Gateway resolves the hostname to an initial resolved IP from a CGNAT range.
3. Traffic routes through the WARP tunnel to Cloudflare.
4. Gateway network policies evaluate the connection.
5. Cloudflared proxies the connection to your SSH server's private IP.

If you do not have a private DNS resolver configured or would rather SSH to an IP address, skip to Step 4.

3.1 Add a hostname route

To add a hostname route to your tunnel:

1. In your tunnel configuration, go to the Hostname routes tab.

2. Enter the hostname of your SSH server (for example, ssh.internal.local).

   Hostname format restrictions

   • Character limit: Must be less than 255 characters.
   • Supported wildcards: A single wildcard (*) is allowed, and it must represent a full DNS label. Examples: *.internal.local, foo.*.internal.local
   • Unsupported wildcards: The following wildcard formats are not supported:
     • Partial wildcards such as *-dev.internal.local or dev-*.internal.local.
     • Wildcards in the middle of a label, such as foo*bar.internal.local.
     • Multiple wildcards in the hostname, such as *.*.internal.local.
   • Wildcard trimming: Leading wildcards (*) are trimmed off and an implicit dot (.) is assumed. For example, *.internal.local is saved as internal.local but will match all subdomains at the wildcard level (covers foo.internal.local but not foo.bar.internal.local).
   • Dot trimming: Leading and ending dots (.) are allowed but trimmed off.

3. Select Complete setup.

3.2 Configure DNS resolution

When Gateway receives a request for your private hostname, it must resolve the hostname to your SSH server's private IP address.

Scenario A: Use the system resolver (Default)

By default, cloudflared uses the private DNS resolver configured on its host machine (for example, in /etc/resolv.conf on Linux). If the machine running cloudflared can already resolve ssh.internal.local to its private IP using the local system resolver, no further configuration is required. You can skip to Step 3.3.

Verify local DNS resolution

To check if cloudflared can successfully resolve ssh.internal.local, run the following command from the cloudflared host:

nslookup ssh.internal.local

Server:    127.0.2.2
Address:  127.0.2.2#53

Non-authoritative answer:
Name:  ssh.internal.local
Address: 10.2.0.3

The output should contain the server's private IP address (the Internal IP of the GCP VM). If the hostname fails to resolve:

• Make sure that your private DNS resolver has a record that points ssh.internal.local to the server's private IP.
• In GCP, you may need to add a private zone to Cloud DNS ↗ so that internal.local resolves using your private DNS resolver.

Scenario B: Use a specific private DNS server (Advanced)

If you need cloudflared to use a specific internal DNS server that is different from the host's default resolver, you must explicitly connect that DNS server to Cloudflare via an IP/CIDR route. You will also need to configure a Gateway resolver policy to route queries to this specific private DNS server.

1. To create an IP/CIDR route for the DNS server:

   1. Go to Networks > Routes > CIDR.
   2. Select Add CIDR route.
   3. Enter the private IP address of your internal DNS resolver.
   4. Select the Cloudflare Tunnel that connects to the network where this DNS server resides.
   5. Select Create.

2. To create a resolver policy:

   1. Go to Traffic policies > Resolver policies.
   2. Select Create a policy.
   3. Create an expression that matches the private hostname:

      Selector	Operator	Value
      Host	in	ssh.internal.local

   4. Under Configure custom DNS resolvers, enter the private IP address of your internal DNS server.
   5. From the dropdown menu, select the - Private routing option and the virtual network assigned to the tunnel you selected in the previous step.
   6. Select Create policy.

3.3 Configure WARP clients

To connect to private hostnames, WARP clients must be configured to forward the following traffic to Cloudflare:

• Initial resolved IPs (CGNAT range: 100.64.0.0/10)
• DNS queries for your private hostname

3.3.1 Configure Split Tunnels

In your WARP device profile, configure Split Tunnels such that the initial resolved IPs route through the WARP tunnel. Refer to the steps below for your Split Tunnels mode:

Exclude IPs and domains

1. Remove the route to the IP address 100.64.0.0/10 from your Split Tunnel exclude list.

2. We recommend adding back the IPs that are not being used for Zero Trust services. For example, if you are using initial resolved IPs alongside WARP-to-WARP connectivity, add routes to exclude the following IP addresses:

   • 100.64.0.0/12
   • 100.81.0.0/16
   • 100.82.0.0/15
   • 100.84.0.0/14
   • 100.88.0.0/13
   • 100.112.0.0/12

Include IPs and domains

1. Add the required Zero Trust domains or IP addresses to your Split Tunnel include list.
2. Add routes to include the following IP addresses:
   • IPv4: 100.80.0.0/16
   • IPv6: 2606:4700:0cf1:4000::/64

3.3.2 Configure Local Domain Fallback

In Local Domain Fallback, delete the top-level domain for your private hostname. This configures WARP to send the DNS query to Cloudflare Gateway for resolution.

For example, if your SSH hostname is ssh.internal.local, remove internal.local from Local Domain Fallback.

4. (Optional) Use IP routes

4.1 Add an IP route

To connect to the SSH server using its IP address (instead of a hostname), add a CIDR route that includes the server's private IP address.

4.2 Configure WARP clients

By default, WARP excludes traffic bound for RFC 1918 space ↗, which are IP addresses typically used in private networks and not reachable from the Internet. In order for WARP to send traffic to your private network, you must configure Split Tunnels so that the IP/CIDR of your private network routes through WARP.

1. First, check whether your Split Tunnels mode is set to Exclude or Include mode.

2. Edit your Split Tunnel routes depending on the mode:

   Exclude IPs and domains

   If you are using Exclude mode:

   a. Delete the route containing your private network's IP/CIDR range. For example, if your network uses the default AWS range of 172.31.0.0/16, delete 172.16.0.0/12.

   b. Re-add IP/CIDR ranges that are not explicitly used by your private network. For the AWS example above, you would add new entries for 172.16.0.0/13, 172.24.0.0/14, 172.28.0.0/15, and 172.30.0.0/16. This ensures that only traffic to 172.31.0.0/16 routes through WARP.

   You can use the following calculator to determine which IP addresses to re-add:

   Base CIDR: Excluded CIDRs:

   Calculate

   Calculator instructions

   1. In Base CIDR, enter the RFC 1918 range that you deleted from Split Tunnels.
   2. In Excluded CIDRs, enter the IP/CIDR range used by your private network.
   3. Re-add the calculator results to your Split Tunnel Exclude mode list.

   By tightening the private IP range included in WARP, you reduce the risk of breaking a user's access to local resources.

   Include IPs and domains

   If you are using Include mode:

   1. Add the required Zero Trust domains or IP addresses to your Split Tunnel include list.
   2. Add a route to include your private network's IP/CIDR range.

5. (Optional) Create Gateway network policies

By default, all devices enrolled in your organization can SSH to the server unless you build Gateway network policies to allow or block specific users. You can create policies based on user identity, device posture, location, and other criteria.

To start logging and filtering network traffic, turn on the Gateway proxy:

Dashboard

1. Go to Traffic policies > Traffic settings.
2. In Proxy and inspection, turn on Allow Secure Web Gateway to proxy traffic.
3. Select TCP.
4. (Recommended) To proxy traffic to internal DNS resolvers, select UDP.
5. (Recommended) To proxy traffic for diagnostic tools such as ping and traceroute, select ICMP. You may also need to update your system to allow ICMP traffic through cloudflared.

Terraform (v5)

1. Add the following permission to your cloudflare_api_token ↗:

   • Zero Trust Write

2. Turn on the TCP and/or UDP proxy using the cloudflare_zero_trust_device_settings ↗ resource:

   resource "cloudflare_zero_trust_device_settings "global_warp_settings" {
     account_id            = var.cloudflare_account_id
     gateway_proxy_enabled = true
     gateway_udp_proxy_enabled = true
   }

Cloudflare will now proxy traffic from enrolled devices, except for the traffic excluded in your split tunnel settings. For more information on how Gateway forwards traffic, refer to Gateway proxy.

Example policies

The following example consists of two policies: the first allows specific users to reach your SSH server, and the second blocks all other traffic.

Policy 1: Allow authorized users

1. Go to Traffic policies > Firewall policies > Network.

2. Select Create a policy.

3. Name your policy (for example, Allow SSH to internal server).

4. Create an expression to match your SSH hostname and authorized users:

   Selector	Operator	Value
   SNI	in	ssh.internal.local
   User Email	in	admin@example.com, devops@example.com

5. In Action, select Allow.

6. Select Create policy.

Policy 2: Catch-all block

To prevent WARP users from accessing your entire private network, we recommend creating a catch-all Gateway block policy for your private IP space. You can then layer on higher priority Allow policies (in either Access or Gateway) which grant users access to specific applications or IPs.

Additional security with DNS policies

For an additional layer of protection, create a Gateway DNS policy to control DNS resolution:

1. Go to Traffic policies > Firewall Policies > DNS.

2. Select Create a policy.

3. Name your policy (for example, Allow SSH hostname resolution).

4. Create an expression:

   Selector	Operator	Value
   Host	in	ssh.internal.local
   User Email	in	admin@example.com, devops@example.com

5. In Action, select Allow.

6. Select Create policy.

SNI selector limitations

By default, SNI selectors only apply to HTTPS traffic on port 443. To inspect traffic on every port, turn on protocol detection and choose to inspect on all ports.

Additionally, SNI selectors will only apply to WARP client traffic.

6. Connect as a user

Once you have set up the tunnel route and the user device, the user can now SSH into the machine. If your SSH server requires an SSH key, the key should be included in the SSH command.

ssh -i ~/.ssh/gcp_ssh <username>@ssh.internal.local

The WARP client must be connected to your Zero Trust organization. Users will be able to connect if they match the Gateway network policies you created.

Troubleshooting

If you cannot connect, verify the following:

1. Confirm DNS resolution - From the WARP device, confirm that you can successfully resolve the private hostname:

   nslookup ssh.internal.local

   Server:    127.0.2.2
   Address:  127.0.2.2#53
   
   Non-authoritative answer:
   Name:  ssh.internal.local
   Address: 100.80.200.48

   The query should resolve using WARP's DNS proxy and return a Gateway initial resolved IP. If the query fails to resolve or returns a different IP, check your Local Domain Fallback configuration and Gateway resolver policies.

2. Check Gateway logs - Review your Gateway network logs to see if the connection is being blocked by a policy.

3. Verify tunnel status - Confirm that your tunnel is healthy and connected by checking tunnel status.

4. Test connectivity to initial resolved IP - When you connect to the SSH server using its private hostname, the device should make a connection to the initial resolved IP:

   ssh -v <username>@ssh.internal.local

   ...
   Authenticated to ssh.internal.local ([100.80.200.48]:22) using "publickey".
   ...

   Look for a line showing connection to an IP in the 100.64.0.0/10 range. If the request fails, confirm that the initial resolved IP routes through the WARP tunnel. You can also check your tunnel logs to confirm that requests are routing to the server's private IP.