FAQ
Applies to SSHepherd 2.0
About SSHepherd®
What is SSHepherd®?
SSHepherd® is patented cybersecurity software that gives secure access to RDP, SSH and TCP/IP applications while their ports are turned off, so they can’t be discovered. It also records RDP and SSH sessions for auditing and compliance, and lets you end unwanted sessions immediately.
What are the SSHepherd® components?
SSHepherd® has three components:
- The Control App and CLI (shepctl). Administrators and users run these to sign in and open secure tunnels, using their usual RDP and SSH tools, or to reach a TCP/IP application.
- The C3 server and Administrator Console. The C3 (Command-and-Control) server is where users, groups, roles, agents and tunnels are managed and where session recordings are viewed.
- The Agent. The Agent runs on each protected host. When a session is requested, it starts the session over a TLS-encrypted outbound connection, so the host needs no open inbound ports. The Agent also ends sessions immediately when an administrator terminates them.
What’s new in SSHepherd 2.0?
Tunnel definitions, Agent-to-Agent tunnels, agent isolation, custom roles, new API key types, and settings in the console, among other changes. See What’s New in 2.0.
Security
How does SSHepherd® protect against internal threats?
SSHepherd® limits the ways in, records SSH and RDP sessions, and lets administrators watch and end sessions. Access is controlled by roles and groups, so each user reaches only the hosts their groups contain, and their session activity can be monitored, recorded and ended.
How does SSHepherd® protect against external threats?
You can turn off sshd, RDP and TCP/IP application listeners, so there are no open ports or services waiting for inbound connections. There’s nothing for attackers or bots to scan, and the server looks offline. Authorized SSHepherd® users can still reach it and use SSH, RDP and their usual tools.
Does the C3 server become the new target?
It could be targeted, so protect it like any important server. Traffic to the C3 server on port 443 looks like ordinary encrypted HTTPS. The C3 server is built for light management work and for routing connections. Instead of many Linux and Windows hosts with open ports, you have one server to protect.
What happens if someone port-scans a protected server? Will they see an open SSH port while a session is running?
No. SSHepherd® doesn’t open any inbound listening ports on protected hosts, so scanners don’t see SSH or RDP, even during an active session.
Can SSHepherd® prevent lateral movement from one server to another?
SSHepherd® limits lateral movement: users reach only the agents in their groups, and only through the C3 server. Combine groups with least-privilege roles, and use agent isolation for sensitive hosts.
If SSH keys or RDP credentials are stolen, can they be used to connect to protected servers?
Not directly. Once the ports are closed, connections can be made only through SSHepherd®, by authorized users.
Can someone use the same port from another machine while a session is running?
No. Tunnels listen on the user’s own computer, on 127.0.0.1 by default, and every connection must go through SSHepherd® and be started by an authorized user.
Is there a need for SSHepherd® if my servers are behind a VPN and firewall?
VPNs and firewalls are a necessary part of perimeter security, but they aren’t always enough. Through phishing, firewall misconfigurations and vulnerabilities, or stolen credentials, attackers get past the perimeter, and many ransomware attacks and data breaches happen inside it. Removing the attack surface, controlling the way in, and auditing, monitoring, recording and ending sessions protects your most valuable systems even when an attacker is already inside.
Can’t I just move the ports so attackers don’t find them?
No. Port scanners still find open, listening ports, whatever number they use.
How much of my attack surface will SSHepherd® remove?
As much as the RDP, SSH and TCP/IP applications you protect with it.
How is SSHepherd® different from a load balancer with a WAF?
With a load balancer and WAF, the ports are still open and listening, so attackers have something to brute-force. SSHepherd® removes that attack surface. A load balancer or WAF also doesn’t record sessions or let you end risky ones.
How can SSHepherd® help with alert fatigue in my SOC?
With SSH, RDP and application ports closed, there’s nothing for brute-force attacks to target, so they no longer generate failed-access alerts to investigate.
Will this affect the alerts sent to my SIEM?
Yes. Alerts about those ports stop, because the ports are closed. You can also use isolation API keys to let your security tools isolate agents automatically.
Is SSHepherd® part of a Zero Trust approach?
Yes. Zero Trust assumes attackers are already inside your network. SSHepherd® authenticates users, verifies them, and gives them access only to the hosts they need, and it supports auditing requirements such as SOC 2 by recording session activity.
Does SSHepherd® help after a phishing attack?
Yes. An attacker who gets inside can’t find the servers SSHepherd® protects, because their ports are closed, and can reach hosts only through SSHepherd® with an authorized account.
Using SSHepherd®
Do Linux and Windows hosts on-premises and in the cloud work?
Yes. The Agent works on supported Linux and Windows hosts, on-premises and in the cloud.
Does SSHepherd® support all SSH and RDP features?
SSHepherd® starts your own ssh client and Remote Desktop client, so their features work as usual. SSHepherd® can also copy files with SCP.
Can I use SSHepherd® with my existing key management and automation tools, such as Ansible, Chef, Puppet or SaltStack?
Yes. SSHepherd® works with SSH keys, SSH tools and automation.
Does SSHepherd® support automated scripts?
Yes. Scripts call shepctl to open the tunnel or run a command. Note that shepctl returns exit code 0 even when a command fails, so scripts should check the output. See the CLI Reference.
Can SSHepherd® be used as servers are created in the cloud?
Yes. Servers can start with SSH and RDP ports closed, install the Agent unattended with an API key, and be reachable only by authorized SSHepherd® users and tools. See Installing the Agent.
Can I carry other protocols through an SSHepherd® session?
Yes. SSH port forwarding works inside an SSHepherd® SSH session, and Generic tunnels carry other TCP/IP applications. Agent-to-Agent tunnels connect hosts to each other with no user involved.
Can a tunnel stay open, or is it one-time only?
Both. A user can keep a tunnel open or close it when the session ends. Agent-to-Agent tunnels stay up permanently.
Which devices does SSHepherd® work with?
Any device running a supported Linux or Windows operating system where you can install the Agent. See System Requirements.
Which Linux distributions does SSHepherd® support?
SSHepherd® provides .deb packages for Debian and Ubuntu, and .rpm packages for Red Hat Enterprise Linux 7 to 10. See System Requirements for the supported versions. FullArmor welcomes requests for other distributions.
Sizing and deployment
How much memory and disk space do the SSHepherd® components use?
Control App 32 MB (SSH) or 60 MB (RDP) of memory; Agent 50 MB (SSH) or 1.5 GB (RDP with recording); installers 51 MB (Windows Control App), 40–50 MB (Linux Control App), 50 MB (Windows Agent) and 12–18 MB (Linux Agent).
For C3 server sizing, see System Requirements.
Where does the C3 server need to be?
On-premises or in the cloud. Agents and users must be able to reach it on TCP 443, and Windows agents on TCP 1935 for RDP recording.
Can SSHepherd® scale?
Yes. The C3 server runs on Kubernetes and can scale to support large numbers of agents. Contact FullArmor for help sizing larger environments.
Can the C3 server be highly available?
Yes. The C3 server runs on Kubernetes with several API replicas. How you make it highly available depends on your Kubernetes platform:
MicroK8s: https://microk8s.io/docs/high-availability
Kubernetes: https://kubernetes.io/docs/concepts/architecture/