Frequently Asked Questions
Common questions about NoPorts
How NoPorts Works
How is NoPorts different from Tailscale and Ngrok?
Everything is in your control. There are no Web Interfaces or centralized control by us, as we never want to be an attack surface for your infrastructure. NoPorts does not connect "networks," but provides on demand encrypted TCP connectivity to existing SSH daemons.
NoPorts is focused on providing end-to-end encrypted and authenticated access to a remote ssh daemon, bound to localhost.
NoPorts does not require any open (listening) ports on external interfaces, so there is no network attack surface on devices using NoPorts.
NoPorts provide relays like Ngrok, but connections are authenticated then connected. Once connected, the connection is encrypted with ephemeral (AES256) keys that the relay never has or needs.
NoPorts abstracts away the TCP/IP layer, so whilst IP address on the client or device may change, the command you use never does.
Why is additional encryption needed when SSH provides its own encryption?
Additional encryption protects the request and rendezvous information (on the relay) 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 relay This is precisely how the https://terrapin-attack.com/ works. Using NoPorts mitigates any man-in-the-middle attacks like Terrapin.
Is sshnp a reverse SSH tunnel?
sshnp is similar to a reverse tunnel in that it has the remote device start an outbound SSH session. What makes sshnp 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. there are no network attack surfaces).
The TCP layer is not taken out in your architecture. Does your protocol run over and above it?
Yes. NoPorts uses the atProtocol which runs on TCP. In order for NoPorts to reach the device, the device must have an IP address. However, it does not need to be a static IP address, and NoPorts 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.
Relay Service and Network Behavior
Is the relay necessary?
The relay ensures that connections from client and server are always outbound, removing the need for listening ports, firewall rules, and network attack surfaces on devices.
NoPorts uses TCP sockets to communicate. "Hole punching" can work sometimes, but we decided to never do that. Using the relay, you know that NoPorts will always work and is friendly to both network admins and firewall rules.
For most customers our relay service is robust and placed regionally. The relay code is open and the binaries are part of the distribution, so you can place your own relay where it makes sense for your network.
If a bad actor takes down the relay, does the tool fail?
In the unlikely event that a bad actor takes down an relay, the tool will indeed fail. Fortunately, we run multiple relays, 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 relays, do I need to open ports on my firewall for them to connect out to the relay?
You do not need to open any inbound ports to connect out to the relay. However, the outbound traffic to the relay server does need to be open. Outbound access is, in most situations, automatically allowed so things just work. If you work in a location where outbound access is also controlled, then please contact us as we have options for for your IT team.
Who pays the ingress & egress costs to the relay?
These costs are included in the NoPorts subscription.
Security and Access Control
How do I close port 22?
To close port 22, edit /etc/ssh/sshd_config remove any lines containing ListenAddress and then add ListenAddress localhost on a new line. Then restart your sshd service (this varies by operating system, a quick web search will help you figure how to do it for your device).
Additional notes for advanced users
You may also replace localhost with the ipv4 (127.0.0.1) or ipv6 (::1) loopback address. However beware! All NoPorts tech defaults to doing lookups for localhost. If your system has both configured in /etc/hosts then NoPorts may resolve to the wrong address for which sshd is configured for.
What Security Group rules are needed for CSP (Cloud Service Provider) deployments, for both data and control plane traffic?
Security groups only need to allow outbound internet access.
What npt or iptables rules are needed for non-CSP deployments, for both data and control plane traffic?
Only outbound internet access via NAT/CGNAT is required.
If the control plane is unreachable, what fallback or break-glass contingency is available?
Break-glass options include console access or, if you trust the local network, leaving sshd listening on an internal interface. We’ve designed the system to minimize lockout risks. In production use, lockouts have been extremely rare, but when they happen it’s normally inadvertent blocking of outbound TCP connections being the issue.
Why do I see man-in-the-middle warnings when connecting to my NoPorts devices?
These warnings occur because each time you SSH into a machine, you’re connecting to localhost on a random port number. If you later use the same localhost and port number to connect to a different machine, this may be interpreted as a potential security risk, triggering a man-in-the-middle warning—even if the system is not compromised.
How can I prevent these warnings?
You can address this issue with one of two approaches:
Assign a Fixed Local Port – By default, each session is assigned a random local port. To prevent mismatches, you can manually specify a static local port for each machine using the -l <port number> option.
Trust NoPorts for Keys and Adjust SSH Config – You can update your SSH configuration (~/.ssh/config) to disable strict host key checking for localhost sessions:
Why do I see extra entries in my ~/.ssh/authorized_keys file, and can I remove them?
You may notice additional entries appearing in your ~/.ssh/authorized_keys file. These entries were originally included for backward compatibility and were used for ephemeral SSH keys in reverse SSH. In most cases, they are not actively used and may persist even after a session ends.
You can safely delete these extra entries, as they do not impact functionality unless specifically needed. We will be removing them from the code soon, but in the meantime, any leftover entries can be manually cleaned up without affecting your setup.
Component Deployment and Operation
How are the NoPorts Tunnel, NoPorts daemon, and the NoPorts TCP relay service deployed?
Deployment is done using curl and tar directly from our GitHub repo. You can do this manually or using a provided bash script that does the hard work for you. Refer to the Installation documentation for detailed instructions.
How are these components started and managed?
Systemd is the default service manager. Alternatives like cron and TMUX also work, but Systemd is recommended for standard deployments.
How are these components patched or updated?
To update, re-run the installation script. You can verify the currently deployed versions using the --list-devices option with with the sshnp command.
How does SELinux affect these components?
SELinux does not affect them, as these components operate in user space. That said, they require permission to open ports on the localhost interface and establish outbound TCP connections.
During the Startup Phase, the relay and npt handshake with their respective atSign services. Does npt on the client also handshake with its atSign service once at boot, or on each SSH initiation?
The sshnpd maintains a persistent connection to its atServer. Other interactions are event-driven.
Does the bridging between ingress/egress ports within np services require the same NIC, or can it occur across different NICs?
This involves standard TCP connections, so normal connectivity rules apply. No layer 2 bridging is performed; only TCP connections are established in user space.
Scripting and Remote Command Execution
Does NoPorts support scripting and remote command execution?
Yes, NoPorts allows for scripting and remote command execution, similar to standard SSH. While the -x option in sshnp does not directly execute commands on the remote machine, you can still achieve this using the following format:
$(sshnp -f @bob -t @ssh_1 -r @rv_am -d iot_device01 -x) hostname
What are the requirements for executing remote commands via NoPorts?
For this method to work, you need a clean login, meaning SSH keys must be properly configured and in place for sshnp. Ensuring your SSH setup supports key-based authentication will allow commands to run on the remote machine.
Usage and Protocol Support
So, you can SSH without any open ports... what about RDP?
You can use NoPorts Tunnel for RDP. This guide demonstrates how.
Did we miss something?
If you have a question that needs answering, please do one of the following:
Create a new GitHub issue
Join our discord and post to our
📑｜forumchannel
Last updated