Teleport Agentless SSH Tunneling: A Practical Alternative to Bastion Hosts

Problem: Managing SSH access across many environments

Teams often need to reach servers, Kubernetes clusters, and cloud VMs from different locations. Traditional solutions require a bastion host or VPN, which adds complexity and a single point of failure. The useful takeaway is that Teleport’s agentless SSH tunneling lets you open secure sessions without installing any client software on the target machines.

How Teleport’s SSH session tunneling works

Teleport establishes an ephemeral key exchange for each connection and authenticates the user via a challenge‑response flow that uses short‑lived certificates. The target host never runs a persistent SSH daemon; instead, the session is carried through a TLS‑protected tunnel that terminates at a Teleport node. When the session ends, no process remains on the target, reducing the attack surface compared to classic VPN or bastion designs.

• Ephemeral keys: a new Diffie‑Hellman exchange is performed for every session, preventing key reuse.
• Out‑of‑band auth: the user proves identity with a short‑lived certificate, not with static passwords or SSH keys stored on the host.
• Zero‑trust model: the tunnel is encrypted end‑to‑end, and the target host only sees the Teleport proxy, not the user’s credentials.

Agentless mode: no binaries on the target

In agentless mode Teleport replaces the SSH daemon on the target with a lightweight proxy that speaks the Teleport protocol over WebSocket Secure (WSS) on port 443. This lets the client connect through any firewall that permits outbound HTTPS traffic, even if the target has no SSH server installed. The trade‑off is that strict egress rules may block the required port, and misconfigured TLS certificate pinning can lock out legitimate sessions.

To make agentless mode work, the environment must allow outbound connections to port 443 (or another HTTPS port if a custom endpoint is used). If your network blocks non‑standard ports, you may need to set up a bridging proxy that forwards WSS traffic through an allowed port.

Version‑sensitive connector configuration

Teleport v16+ unified SSH, Kubernetes, and cloud connectors under a single identity service, simplifying token rotation and reducing the number of separate configuration files. Earlier versions (v15 and before) required distinct connector setups and separate token renewal workflows, which could lead to stale tokens or mismatched authentication methods.

When using Kubernetes, the connector version must match the Teleport server version. Using a v15 connector with a v16 server, for example, may cause authorization errors because the token format changed in the newer release.

Worked example: connecting to a Kubernetes pod via agentless SSH

Assume you have a Teleport cluster running v16, a Kubernetes node labeled k8s-node-1, and a pod named web‑frontend-01. The user admin has a role that includes the ssh_service and kubernetes permissions.

1. Run the diagnostic command to verify that the agentless SSH path is healthy:

   teleport doctor --mode=ssh

   The output should indicate "SSH tunnel OK" and show the certificate validity for the node.
2. Open an interactive shell to the pod using the agentless SSH command (placeholders in angle brackets):

   teleport ssh --user= --node= -- pod= bash

   If the node is reachable and the pod exists, you will see a shell prompt inside the container.
3. Execute a quick check inside the pod to confirm connectivity:

   kubectl exec -it web-frontend-01 -- df -h

   The command should return disk usage information without any "connection refused" errors.

Required permissions: the Teleport role must grant ssh_service and kubernetes capabilities. The user must also be able to authenticate via the Teleport identity provider (e.g., SSO, OIDC). Risks include session failure if outbound port 443 is blocked or if the node’s TLS certificate has expired.

Trade‑off and limitation

The primary limitation of agentless SSH is the need for outbound HTTPS connectivity. Environments with egress restrictions—such as air‑gapped networks or corporate firewalls that only allow specific ports—may experience session drops unless a bridging proxy is configured. Additionally, TLS certificate pinning misconfigurations can cause legitimate users to be denied access; rotation procedures must align with the Teleport version’s certificate authority policy.

Actionable closing

To safely adopt Teleport’s agentless SSH tunneling:

1. Confirm your Teleport server version (run teleport --version) and compare it against the official feature matrix to ensure SSH tunneling and agentless mode are enabled.
2. Run teleport doctor --mode=ssh on a management workstation to validate connectivity, certificate validity, and agentless mode status.
3. Verify that outbound traffic to port 443 is allowed; if not, set up a WSS bridge on an allowed port.
4. Test the connection on a non‑critical host first, then roll it out to production workloads.
5. Monitor Teleport logs for any "certificate pinning" or "tunnel termination" errors, and adjust the TLS configuration as needed.

By following these steps, you can replace a traditional bastion host with a zero‑trust, agentless SSH solution that works across operating systems, Kubernetes clusters, and cloud environments, while keeping the operational surface minimal.