SSHepherd® vs Teleport

Both connect out.Only one lets you switch RDP off.

Teleport is a strong identity-based access platform for engineering teams, covering servers, Kubernetes, databases and Windows. It and SSHepherd overlap more than most: both dial out and both record sessions. The differences are on Windows, at the edge and in licensing.

Animation: a PowerShell window on win01 runs netstat for port 3389. With Teleport, RDP is listening on 3389 for Teleport's desktop service. With SSHepherd, nothing is listening on 3389 because RDP is switched off. Both agents connect outbound with no public inbound ports.
Where they agree

They agree on morethan most comparisons admit.

Teleport is an identity-based infrastructure access platform with short-lived certificates for people, machines and AI. Before the differences, the common ground.

Both connect outbound

Teleport agents dial back to the Proxy over reverse tunnels, so protected machines need no public inbound ports. The SSHepherd agent also dials out.

Both record sessions

Teleport records SSH and Windows desktop sessions in every edition. SSHepherd records SSH and RDP sessions with live view and replay.

Both are identity first

Teleport issues short-lived certificates bound to identity. SSHepherd admits authorised identities from your SAML, OIDC or Active Directory provider.

Where they differ

Side by side,line by line.

Taken from each vendor's own documentation, checked . Numbers link to the source. The edge on each row says which product its documentation favours, and it goes to Teleport where Teleport is stronger.

CapabilitySSHepherd®Teleport
Listening on the protected serverEdge: SSHepherdNothing listeningNone. sshd, RDP and TCP/IP application services can be switched off, so nothing on the server waits for an inbound connection. 1RDP stays openAgents need no public inbound ports. Windows hosts keep RDP (typically 3389) open to Teleport's desktop service, and Teleport recommends replacing sshd with its own agent for SSH. 234
A scan from inside your networkEdge: SSHepherdNothing to findNo open, listening ports, even while an SSHepherd session is active. 15RDP and DB ports reachableDepends on the resource: Windows desktops keep RDP listening for the desktop service, and databases and other services keep their normal ports behind Teleport. 32
What accepts connectionsEvenYour own C3 serverYour SSHepherd C3 server, which you host on Kubernetes (on-premise or cloud). The agent and the user's Control App both connect out to it over TLS. 16Teleport ProxyThe Teleport Proxy Service, the one cluster component addressable from the public internet (port 443 with TLS routing). 2
Session recordingEdge: TeleportSSH and RDPSSH and RDP sessions are recorded, with live view and replay. 7SSH, RDP, Kubernetes, DBsYes, in every edition: full SSH sessions, Windows desktop screen and mouse (no keystrokes), kubectl exec and database queries. 89
Ending a live sessionEdge: SSHepherdImmediateYes. An administrator watching a live session can terminate it immediately. 7Enterprise edition onlyYes in Teleport Enterprise: locks terminate matching active sessions, and moderators can end a session. Not in the Community edition. 109
What it coversEdge: TeleportSSH, RDP, TCP appsSSH, RDP and TCP/IP applications, on Windows and Linux hosts. 6Servers, K8s, DBs, appsLinux and Windows servers, Kubernetes, databases and internal applications, for human and machine identities. 11
  • Clear strength
  • With conditions
  • Not documented, or still exposed
  • No winner
The difference that matters

Off the internet is good.Off entirely is better.

Teleport keeps the server off the public internet. SSHepherd also takes the service off the network the server sits on, which is where an attacker who has already got in starts looking.

Teleport
UserTeleport ProxyDesktop serviceWindows, RDP 3389 open
Teleport's desktop service reaches Windows hosts over RDP, which stays open to it.
SSHepherd®
AdminYour C3 serverAgent dials outServer, RDP off
Both ends connect out to the C3. A scan of the server, from outside or inside, finds nothing listening.
How a session reaches a protected server with Teleport and with SSHepherd, from each vendor's documentation.
Which fits

Different jobs.Sometimes both.

Choose Teleport if

  • Your engineering teams live in Kubernetes, cloud databases and CI pipelines, and you want one identity layer across all of it.
  • Machine and workload identity matters as much as human access.

Choose SSHepherd® if

  • A large part of your estate is Windows and RDP, and you want RDP switched off on the host rather than open to a desktop service.
  • You want live session termination without moving to an Enterprise edition, with recording and the kill switch in the same product.
  • You would rather not run an internet-facing proxy for the cluster: SSHepherd's C3 server is yours to place where you choose.

Both are infrastructure access products, so most teams choose one. If you run both, the natural split is Teleport for Kubernetes and cloud-native engineering, SSHepherd for Windows and legacy servers.

Questions

Common questions.

Does Teleport need open ports on my servers?

Not to the public internet: Teleport agents dial back to the Proxy over reverse tunnels. Windows hosts do keep RDP open to Teleport's desktop service, and the Teleport Proxy itself listens on the internet, typically on port 443.

Does Teleport record sessions and have a kill switch?

It records SSH and Windows desktop sessions in every edition. Ending a live session with locks or moderated sessions is a Teleport Enterprise feature.

What is the main difference from SSHepherd?

SSHepherd lets you switch the SSH, RDP and application services off on the server, so nothing listens there, inside or outside your network, and includes live session termination in the product.

Where does SSHepherd run?

You host the SSHepherd C3 server on Kubernetes, on-premise or in the cloud. Agents on your Windows and Linux servers and the user's Control App both connect out to it.

Sources

  1. Full Armor: SSHepherd FAQ
  2. Teleport Docs: Networking
  3. Teleport Docs: Desktop access, getting started
  4. Teleport Docs: Agentless OpenSSH
  5. Full Armor: Make your network traffic invisible to hackers
  6. Full Armor: System requirements
  7. Full Armor: Monitoring sessions
  8. Teleport Docs: Session recording
  9. Teleport Docs: Feature matrix
  10. Teleport Docs: Session and identity locking
  11. Teleport: Zero Trust Access
  12. US Patent 11,153,340 B1: Elimination of listen ports on a publicly accessible computer

Checked against each vendor's public documentation on 6 October 2026. Products change: if anything here is out of date, email [email protected] and we will correct it. This page compares documented capabilities, not price or performance. Teleport and Teleport are trademarks of their owner; Auris is not affiliated with Teleport. SSHepherd® is developed by Full Armor Corporation and distributed in Southeast Asia by Auris.

More comparisons: SSHepherd vs Zscaler ZPA · SSHepherd vs Cloudflare · SSHepherd vs Twingate

Book a demo

See it onyour own servers.

Already running Teleport? Tell us what you protect with it and which servers your administrators reach. We will show where SSHepherd fits alongside it, and reply within one business day.

We use these details only to reply to your request, usually within one business day.