SSH No Ports uses Atsign’s end-to-end encrypted control plane to initiate SSH connections without opening ports on either of your devices.
Atsign’s Core Technology (a.k.a. Control Plane)
Atsign’s patent pending core technology is engineered to deliver the following benefits:
- Addressability
Atsign’s core technology uses identifiers which replace the need to manage IP addresses. If you remember the atSign (Atsign’s version of an address), you can look up the IP address and port in the atDirectory which manages this information for you. - Reachability
Atsign’s core technology provides each device with its own microservice which makes it reachable from anywhere on the Internet. - No open ports (no network attack surface) on the device
Connections are always made from the device to the microservice, meaning that no ports ever need to be opened on devices using this technology. - End-to-end encrypted
Information is automatically encrypted on the edge devices before it is sent over Atsign’s control plane. - Zero Trust
Atsign’s technology is designed so that cryptographic keys are only stored on the edge device. No third party or intermediary ever possesses the decryption keys which are required to access the information. You don’t need to trust any of the microservices, because they never see information in the clear.
In other words, sending information using Atsign’s control plane requires no open ports and is fully edge-to-edge encrypted, all without needing to know the IP address of the device!
How SSH No Ports uses Atsign’s Control Plane
- First the client generates a new SSH key pair to use for the session.
- Alice must then select a socket rendezvous (SR) to use for relaying the SSH connection. For low latency, it’s recommended that you pick the SR closest to you.
- Once Alice has selected an SR, her client (@alice) will automatically use Atsign’s control plane to request two ports from the chosen SR. The SR will issue @alice two connection ports by providing either a FQDN or an IP address, as well as the port number for each.
- Now @alice will use Atsign’s control plane to send the SSH private key and one of the connection port’s information to @linux_mc.
- @linux_mc will automatically do an SSH client connection to the SR using the provided information.
- @alice will simultaneously use sshrv to connect its localhost port 22 to the SR using the second connection port.
- The SR connects both ports that it issued to @alice. See socket_connector for more information on the service that enables this.
- A reverse SSH tunnel from @linux_mc is created over the connected tunnel through the SR to @alice. It forwards @linux_mc’s localhost port 22 to some arbitrary port on @alice’s localhost (this port can be specified with -l).
- @alice connects to her localhost on the arbitrary port which allows her to reach port 22 of @linux_mc. She now has SSH access to @linux_mc!
SSH No Ports
General FAQs
- How is SSH No Ports different from Tailscale and ngrok?
SSH No Ports does not require any open (listening) ports, so there are no network attack surfaces. Other SSH tools require an open port, usually port 22, leaving them open to network attacks.
With ngrok, unlimited connections can be made. With our socket rendezvous, connections beyond the first are essentially ignored. The service will not act on information received from new connections, nor share information with those connections. The rendezvous service leaves those connections in “limbo”. - Is the socket rendezvous (SR) necessary?
If you’d like to get access to your remote device with no open (listening) ports on either end, the SR is required. If you are comfortable with an open port on the client device, then you do not need the SR. - If a bad actor takes down the socket rendezvous (SR), does the tool fail?
In the unlikely event that a bad actor takes down the SR, the tool will indeed fail; both devices are secured. Fortunately, we run multiple SRs, so if one is down or unavailable, you can easily switch to another. - Since the device and the client need to connect out to the socket rendezvous (SR), do I need to open ports on my firewall for them to connect out to the SR?
You do not need to open any inbound ports to connect out to the SR. However, the outbound traffic to the SR server does need to be open. - Who pays the ingress & egress costs to the socket rendezvous (SR)?
These costs are included in the SSH No Ports subscription. - Why is additional encryption needed when SSH provides its own encryption?
Additional encryption protects the request and rendezvous information (on the SR) that is sent from the client device to the remote device’s atServer and ultimately to the client. Without encryption, this information could be intercepted and a bad actor could meet the client device at the socket rendezvous. - Is SSH No Ports a reverse SSH tunnel?
SSH No Ports is similar to a reverse tunnel in that it has the remote device start an outbound SSH session. What makes SSH No Ports better than a reverse SSH tunnel is that you don’t need access to the device to initiate it. This means you don’t need to leave open ports when not in use (i.e. no network attack surfaces). - The TCP layer is not taken out in your architecture. Does your protocol run over and above it?
Yes. SSH No Ports uses the atProtocol which runs on TCP. In order for SSH No Ports to reach the device, the device must have an IP address. However, it does not need to be a static IP address, and SSH No Ports doesn't even need to know what the IP address is. So, even though it runs over TCP/IP, it does away with all the pain of finding and managing IP addresses. - So, you can SSH without any open ports... what about RDP?
You can use SSH No Ports (as it is) to RDP right now! While it is still not its own "RDP No Ports" product, you can run an SSH No Ports session in the background and append the -L SSH flag using the -o sshnp flag to forward the local RDP port 3389 on your desktop to a local port on your client. Here's a quick video explainer for more details.
.svg){kind=logo}
