Using Teleport as an Upstream SSH Proxy for Network Appliances That Cannot Run the Teleport Agent

[pnrao1983]

Overview

This guide covers a validated architecture for proxying SSH access to network appliances — firewalls, routers, switches — that cannot run the Teleport agent and do not support SSH CA trust. FortiGate running FortiOS is the primary example, but the pattern applies to any SSH-capable appliance with a locked-down OS.

Teleport version tested: 18.9.1 (self-hosted, EKS)
Target OS tested: Amazon Linux 2023 with OpenSSH 8.7 (simulating FortiOS constraints)

---

Why Standard Teleport Enrollment Fails on Network Appliances

Teleport has two standard paths for enrolling SSH nodes:

Agent mode — Install the Teleport binary on the target. The agent registers with the cluster and handles cert-based auth directly.

Agentless OpenSSH mode — No binary needed. Configure TrustedUserCAKeys in sshd to trust Teleport's CA, then Teleport proxies connections using short-lived certs.

Both paths are blocked on FortiOS and most other network appliance operating systems:

• FortiOS will not run third-party binaries or daemons (rules out agent mode)
• FortiOS has no TrustedUserCAKeys equivalent. SSH public keys must be configured per admin account directly on the device (rules out agentless mode)

Fortinet TAC confirmed this. Reference:

• https://docs.fortinet.com/document/fortigate/7.6.6/administration-guide/813125/public-key-ssh-access
• https://docs.fortinet.com/document/fortigate/7.6.6/administration-guide/766272/remote-authentication-for-administrators

---

The Solution: SSH ProxyJump with Agent Forwarding

Teleport acts as the identity-aware upstream proxy. The user's SSH agent (carrying a service account keypair) is forwarded through the Teleport proxy to the target device.

User → tsh ssh -A → Teleport Proxy (session recorded here) → Target device (public key auth)

What you get from Teleport:

• SSO authentication (Okta, Entra, GitHub, etc.) with short-lived certs
• RBAC enforcing who can reach which devices
• Full session recording at the Proxy layer
• JIT access request workflow
• Audit log entries for every session

What the target device needs:

• SSH daemon running
• A restricted service account with the service keypair in authorized_keys
• Source IP restrictions to the Teleport proxy IP (recommended)

This requires self-hosted Teleport — Cloud does not support proxy recording mode in this configuration.

---

Setup Guide

Step 1: Generate a dedicated SSH keypair

On the machine where you run tsh:

ssh-keygen -t ed25519 -f ~/.ssh/network-device-key -C "teleport-network-access" -N ""

Step 2: Create a restricted service account on the target device

For a standard Linux target simulating the constraint:

useradd -m netadmin
mkdir -p /home/netadmin/.ssh
chmod 700 /home/netadmin/.ssh
cat ~/.ssh/network-device-key.pub > /home/netadmin/.ssh/authorized_keys
chmod 600 /home/netadmin/.ssh/authorized_keys
chown -R netadmin:netadmin /home/netadmin/.ssh

For FortiGate, configure a restricted admin account under config system admin and set the public key directly on the account. Apply least-privilege admin profile and limit SSH access to the Teleport proxy source IP.

Step 3: Register the target as an OpenSSH node in Teleport

Create the node resource with tctl. Note that sub_kind: openssh must be at the YAML top level, not inside spec — if placed inside spec it is silently ignored:

kind: node
version: v2
sub_kind: openssh
metadata:
  name: fortigate-fw-01
  labels:
    env: prod
    type: network-appliance
    site: datacenter-1
spec:
  addr: "DEVICE_IP:22"
  hostname: fortigate-fw-01

tctl create -f fortigate-fw-01.yaml

Step 4: Generate a host certificate for the target

This allows Teleport's proxy to verify the target's identity:

tctl auth sign \
  --host=DEVICE_IP,fortigate-fw-01 \
  --format=openssh \
  --out=fortigate-host-cert

Copy the generated files to the target and add to sshd_config:

HostKey /etc/ssh/fortigate-host-cert
HostCertificate /etc/ssh/fortigate-host-cert-cert.pub
TrustedUserCAKeys /etc/ssh/teleport_user_ca.pub

Critical: TrustedUserCAKeys file format

On hardened distros (Amazon Linux 2023, RHEL 8+, and likely others), the TrustedUserCAKeys file must contain only the raw public key — no cert-authority prefix, no trailing options. The standard tctl auth export output includes both and will cause an invalid format error.

Export the CA correctly:

# This produces the correct format for TrustedUserCAKeys
tctl auth export --type=openssh | awk '{print $2, $3}' > /etc/ssh/teleport_user_ca.pub

The file should contain only:

ssh-ed25519 AAAA...

Also verify the fingerprint of the exported key matches what sshd reports in debug logs. If your cluster has multiple user CAs (e.g. after a rotation), tctl auth export --type=openssh and tctl auth export --type=user may return different keys. Check with:

tctl auth export --type=openssh | ssh-keygen -l -f -
tctl auth export --type=user | ssh-keygen -l -f -

Compare against the CA ED25519 SHA256:... fingerprint shown in sshd debug output to confirm you have the right one.

Restart sshd after updating the config.

Step 5: Create the Teleport role

kind: role
version: v7
metadata:
  name: network-device-access
spec:
  options:
    forward_agent: true
    record_session:
      default: proxy
  allow:
    logins:
      - netadmin
    node_labels:
      type: network-appliance

tctl create -f network-device-access.yaml

Assign the role to the users or access lists that need device access.

Step 6: Load the service key and connect

ssh-add ~/.ssh/network-device-key
tsh login --proxy=YOUR_CLUSTER
tsh ssh -A netadmin@fortigate-fw-01

Step 7: Verify session recording

tsh recordings ls

The session should appear with the device hostname and the connecting user.

---

Key Gotchas

sub_kind placement — sub_kind: openssh must be at the YAML root level alongside kind, version, and metadata. If placed inside spec, tctl create succeeds without error but the field is silently ignored, causing access denied on connection.

TrustedUserCAKeys format — The cert-authority prefix and clustername= options that tctl auth export appends are for authorized_keys files, not TrustedUserCAKeys. OpenSSH 8.7+ on hardened distros rejects the options with invalid format. Strip them with awk '{print $2, $3}'.

Multiple user CAs — A cluster that has undergone CA rotation may have more than one user CA. tctl auth export --type=openssh returns the active signing CA for the agentless path, which may differ from --type=user. Always fingerprint and compare against the sshd debug output.

TeleportOpenSSHServerV2 CRD — If you use the Teleport Kubernetes operator, the TeleportOpenSSHServerV2 CRD may not be installed depending on your cluster version. Use tctl create directly as shown above.

proxy recording mode — record_session: default: proxy is intentional and required. The proxy terminates and re-encrypts the session because the target cannot participate in Teleport's cert-based trust chain. This is expected behavior for this architecture.

---

Applicability

This pattern works for any SSH-capable device that does not support CA-based trust:

• Palo Alto PAN-OS
• Cisco IOS / NX-OS
• Juniper Junos
• Arista EOS
• Any appliance with a locked-down SSH daemon

The Teleport configuration is identical in all cases. The only variable is how each vendor's OS handles service account SSH public key configuration.

---

References

• Teleport agentless OpenSSH manual install: https://goteleport.com/docs/enroll-resources/server-access/openssh/openssh-manual-install/
• Fortinet public key SSH access: https://docs.fortinet.com/document/fortigate/7.6.6/administration-guide/813125/public-key-ssh-access
• Fortinet remote authentication for administrators: https://docs.fortinet.com/document/fortigate/7.6.6/administration-guide/766272/remote-authentication-for-administrators