Let's Talk About Keys

To make your NoPorts installation smoother and easier to understand, take a moment to watch this short video explaining NoPorts cryptographic keys.

Getting Started Overview

Step 1. Sign up for NoPorts

You'll need to head over to to sign up for a NoPorts subscription or free trial.

Steps 2 and 3. Install NoPorts

We offer a range of installation options to suit your needs. Choose from our quick-start guides, which let you try NoPorts with our test connection, or see our detailed, step-by-step instructions to help you set up your own machines.

Step 4. Use NoPorts

NoPorts has endless use cases. We've provided a list of the most common ones:

We recommend reviewing the before beginning your installation.

Proactive Security

NoPorts shifts the security paradigm from “ports are open, I need to close them” to “ports are closed, I need to open them (securely).” Ports are closed and secure by default, allowing you to manage only the things you actively use.

Communication between devices is always peer-to-peer and end-to-end encrypted. Encryption keys are cut and stored securely on the device and controlled by the device owner.

Available via both command line and as a desktop application, NoPorts is already being used in the field to replace VPNs and firewalls, enable zero-trust remote access, improve cloud security, and apply Atsign’s preemptive security approach to a wide range of industries and use cases.

Getting Started Overview

Sign up for a NoPorts subscription or free trial

Head over to to sign up for a subscription or free trial.

Quick Start for macOS and Windows Only

Follow these guides to try NoPorts using the desktop application. You can establish a remote connection to our test connection page or set up a connection to your own remote machine.

Install via CLI for macOS, Linux and Windows

Follow these detailed guides to install NoPorts via the command line and use it for establishing remote connections to your devices.

Select your operating system and remote device to see specific installation instructions.

Other Installation Options

Use NoPorts

Start by exploring the available use cases, such as , , , , , and . We also provide in-depth usage information here.

Need Help?

Overview

NoPorts offers flexible installation methods. While shell scripts streamline the setup process, this guide provides step-by-step instructions for those who prefer complete control over each stage of the installation.

Overview

Keeping NoPorts up to date ensures optimal performance, security, and compatibility with new features. The guides below detail the upgrade process for both the client and the daemon.

Additional Options

-k, --key-file, --keyFile

Specify the .atKeys file for the -a, --atsign atSign if it's not stored in ~/.atsign/keys

-s, --[no-]sshpublickey

When set, will update authorized_keys to include public key sent by manager.

-h, --hide

Hides the device from advertising its information to the manager atSign. Even with this enabled, sshnpd will still respond to ping requests from the manager. (This takes priority over the [now deprecated] -u / --un-hide flag).

-v, --[no-]verbose

More logging

--ssh-client

What to use for outbound ssh connections.

[openssh (default), dart]

--root-domain

atDirectory domain

(Defaults to "root.atsign.org")

--device-group

The name of this device's group. When delegated authorization is being used then the group name is sent to the authorizer service as well as the device name, this daemon's atSign, and the client atSign which is requesting a connection

(Defaults to "__none__")

--local-sshd-port

Port on which sshd is listening locally on localhost

(Defaults to "22")

-S, --sshpublickey-permissions

When --sshpublickey is enabled, will include the specified permissions in the public key entry in authorized_keys

(Defaults to "")

--ephemeral-permissions

The permissions which will be added to the authorized_keys file for the ephemeral public keys which are generated when a client is connecting via forward ssh e.g. PermitOpen="host-1:3389",PermitOpen="localhost:80"

(Defaults to "")

--ssh-algorithm

Use RSA 4096 keys rather than the default ED25519 keys

[ssh-ed25519 (default), ssh-rsa]

--storage-path

Directory for local storage.

(Defaults to $HOME/.atsign/storage/$atSign/.npd/$deviceName/)

--permit-open,--po

Comma separated-list of host:port to which the daemon will permit a connection from an authorized client. Hosts may be dns names or ip addresses.

(Defaults to "localhost:22,localhost:3389")

Here you'll find instructions for custom operating systems or device installs.

The Guiding Principle

At its heart, NoPorts has one guiding principle behind it:

No ports should ever be open where there is any data of value.

What NoPorts Offers

Simply put, NoPorts improves network security while simplifying its management.

How It's Achieved

With NoPorts the paradigm shifts from "things are open, I need to close them" to "things are closed, I need to open them securely". (i.e. closed & secure by default)

Why This Matters

NoPorts allows you to stop the impossible task of actively managing everything, instead you only need to manage the things you actually use.

The first time you activate, this set of keys that gets generated is a set of management keys. These keys have full permissions to your atServer, the personalized service which powers your atSign.

We recommend cutting the management keys on the client for a few reasons:

1. It's extremely important that you don't lose these keys:

   1. They are less likely to get lost on your client machine than on your device.

   2. If a device is stolen you still have your management keys to recover from the theft.

2. For each device we can issue it's own set of cryptographic keys which has a few perks:

   1. This allows us to limit the permissions of those keys to the bare minimum required for NoPorts.

   2. If a device gets compromised, we can safely revoke the set of cryptographic keys associated with that device, without affecting the other devices using the same atSign.

While these are frequently asked questions, if you are responsible for installing NoPorts for your organization, these guides are worth reading for better understanding.

SSH uses keys to authenticate as well as having a fallback of using passwords, but using keys is easier and more secure than "mypassword!". If you already are a seasoned user of SSH then you might have keys already, but if not, then on the client machine you can create a key pair using ssh-keygen.

Example ssh-keygen command to create SSH Key Pair

ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519

NoPorts has endless use cases. We've compiled a list of the most frequently used ones:

Upgrade sshnp

Upgrading to the latest version of sshnp follows the same process as installation, as the installer automatically replaces existing binaries with the new ones.

To upgrade, follow the installation guide up to Step 3, then return to this page to verify the upgrade.

Verify the Upgrade

To check the current version of sshnp installed on your machine simply execute the binary:

Troubleshooting the Upgrade

If you continue to get an old version number, it's likely that there's an old binary which wasn't replaced on the machine. Try the following to debug your binary location:

This page describes using the policy service

Policy Service Status

The Policy Service must remain running at all times to listen for incoming requests from daemons querying the policy server.

Policy Roles

In the context of the Policy Service, a role defines a set of access permissions that determine which atSigns can interact with specific devices or groups of devices through NoPorts.

When creating a role you will need to enter the following information:

After a role is created and saved, the atSigns listed in the User atSigns section will be able to connect to the designated ports and interact with the specified devices using the assigned device atSigns.

If using device groups, be sure the specify the device group name when running the NoPorts Daemon on your device. For example:

When starting a VM on OCI first click the Show advanced options button having selected the usual options above that.

Then (in the Management tab) select Paste cloud-init script

And paste your customised script into the Cloud-init script box:

#!/bin/bash
# Modify these lines to set the installation specific variables
ATCLIENT="@democlient"
ATDEVICE="@demodevice"
DEVNAME="cloudvm1"
OTP="739128"
USER="opc"
# The rest of the script shouldn't be changed
export HOME="/home/${USER}"
export SUDO_USER="${USER}"
mkdir -p /run/atsign
cd /run/atsign
VERSION=$(wget -q -O- "https://api.github.com/repos/atsign-foundation/noports/releases/latest" | grep -Po '"tag_name": "v\K.*?(?=")')
wget https://github.com/atsign-foundation/noports/releases/download/v${VERSION}/universal.sh
sh universal.sh -t device -c ${ATCLIENT} -d ${ATDEVICE} -n ${DEVNAME}
/usr/local/bin/at_activate enroll -a ${ATDEVICE} -s ${OTP} -p noports -k /home/${USER}/.atsign/keys/${ATDEVICE}_key.atKeys -d ${DEVNAME} -n "sshnp:rw,sshrvd:rw"
chown -R ${USER}:${USER} /home/${USER}/.atsign

The VM is now ready for Create

After a few minutes the APKAM key can be approved:

If the VM isn't quite ready you'll see:

Waiting a little longer and retrying should produce a successful approval:

The VM is now ready for connection with the NoPorts client.

Command Line

The command should look like:

npt -f @<client> -t @<device> -d <device name> -r @<relay> -p 22 -l 2222

Example:

Now you can connect to localhost:2222 in your favorite SFTP client.

To learn more about NPT

Desktop Application

When using the NoPorts desktop application, your connection profile should look something like this:

Step 1. Run the installer

cd sshnp

Step 2. Set up the installer

You are on your own for setting up the background service to start sshnpd. See our other options if you need help setting this up.

Step 3. All Done!

You can now proceed to , or if you've already done that, check out our .

Step 1 to Step 4

These initial steps set up the machine initiating the connection.

Step 5 to Step 7

After setting up the machine you're connecting from, you'll configure the machine you're connecting to.

Step 8 and Step 9

With both machines now configured, the final steps bring us back to the machine initiating the connection.

Learn how to install it at Policy Service Installation.

The NoPorts Policy Service is currently in alpha status. Schedule a call with one of our engineers to become an alpha tester.

The NoPorts desktop application streamlines remote connection management by providing a structured interface for configuring remote connections.

The NoPorts Desktop application is available for download on both Windows and MacOS.

Overview

Installation

Select the operating system running on the machine you're connecting to for installation instructions.

Connecting from macOS

Step 1 to Step 4

These initial steps set up the machine initiating the connection.

Step 5 and Step 6

Additional Options

-k, --key-file

Specify the .atKeys

In the Azure Portal select Virtual machines and hit the + Create button.

Choose your preferred options for each sub-page of the Create a virtual machine process.

On the Advanced sub-page there's a Custom data and cloud init section where your customised script can be pasted:

It should look like this:

Once that's complete the VM is ready for Review + create

Command Line

The command should look like:

Example:

Auto SSH key upload

Command Line

The command should look like:

Navigate to Compute Engine > VM instances and hit the + CREATE INSTANCE button as usual, then select Name, Region, Machine configuration etc.

Expand Advanced options at the bottom of the page:

Then scroll down and expand Management:

In the Automation section paste in your customised startup script like:

NB this script is creating a new user noports

NoPorts integrates seamlessly with Linux and macOS SSH configurations, allowing secure outbound connections via OpenSSH config.

For Windows, NoPorts works with PuTTY, enabling efficient management of multiple SSH sessions without exposed ports.

Device Name Format

The device name has the following constraints.

• May contain only the following characters:

Command Line

The command should look like:

Example:

The NoPorts daemon can be installed on a Linux cloud virtual machine (VM) using a cloud-init script of the form:

Some clouds, such as Azure and Oracle Cloud will take the script pretty much as presented above. Other clouds, including AWS and GCP need alternate formatting or additional customisation.

In all cases the variables in the first section of the script should be changed to match the atSigns being used, the desired device name, the Linux username and the one time password (OTP) or semi-permanent passcode (SPP) being used. e.g.:

Once the VM is started (which will generally take a few minutes) the NoPorts daemon will be waiting for an APKAM key in order to start up. That key can be approved using at_activate

When launching an instance on EC2 choose settings as usual for the instance type etc.

A security group with no external ports open can be created or reused.

Expand the Advanced details section at the bottom of the Launch an Instance page:

Scroll down to the User data - optional box and paste in your customised YAML e.g.:

Which will end up looking something like this:

The VM config should now be ready for Launch instance

Overview

Installation

Select the operating system running on the machine you're connecting to for installation instructions.

The following sequence diagram covers the "Happy path" for the startup of a NoPorts session. When a step fails with an error, then the client halts the process, all existing connections automatically timeout and shutdown after a short period of time.

Command Line

The command should look like:

Example:

Now you can connect to localhost:33899 in your favorite RDP client.

Use Cases

If you have a specific use case, we may already cover the steps you need to take. Check out these guides.

Command Line

Here, we demonstrate how to use the NoPorts Tunnel to bridge a web server on a remote machine to localhost:80 so we can access the web server locally.

Overview

Installation

Select the operating system running on the machine you're connecting to

This guide provides instructions for connecting from the NoPorts desktop application, to a machine running macOS .

Step 6 and Step 7

Complete these steps on the machine you are connecting to (MacOS)

Step 8 to Step 11

With both machines now configured, the final steps bring us back to the machine initiating the connection.

Step 1 to Step 4

These initial steps set up the machine initiating the connection.

Step 5 to Step 7

After setting up the machine you're connecting from, you'll configure the machine you're connecting to.

Step 8 and Step 9

With both machines now configured, the final steps bring us back to the machine initiating the connection.

Overview

NoPorts needs to be installed on both the machine you are going to connect to (device) and the machine you are going to connect from (client). NoPorts uses atSigns as addresses and you will need two, one for the client and one for the device.

Example client atSign

Example device atSign

Activate your atSigns

Activate the client atSign

(1) Run the at_activate command for the client atSign

(2) Enter the One Time Password (OTP) & Check your SPAM/PROMOTIONS folders

at_activate will pause and wait for the input of a one time pin (OTP) before you can continue. You should receive this pin to the contact information associated with the registration of your NoPorts address (i.e. email or text message).

Once you receive the message, enter the pin into the application and press enter to continue. The application should proceed to create the cryptographic keys and store them in the ~/.atsign/keys/ directory with a filename that includes the atSign.

Activate the device atSign

1) Run the at_activate command for the device atSign

2) Enter the One Time Password (OTP) & Check your SPAM/PROMOTIONS folders

Again, at_activate will pause and wait for the input of a one time pin (OTP) before you can continue. You should receive this pin to the contact information associated with the registration of your NoPorts address (i.e. email or text message).

Once you receive the message, enter the pin into the application and press enter to continue. The application should proceed to create the cryptographic keys and store them in the ~/.atsign/keys/ directory with a filename that includes the atSign.

Step 1 to Step 4

These initial steps set up the machine initiating the connection.

Step 5 and Step 6

After setting up the machine you're connecting from, you'll configure the machine you're connecting to.

Step 7 and Step 8

With both machines now configured, the final steps bring us back to the machine initiating the connection.

Want to use your atSign on a different machine?

You can:

A. Generate a new set of cryptographic keys (Recommended)

B. Copy the cryptographic keys from the machine where it's been activated in the past (Not recommended)

Option A) Generate a new set of cryptographic keys (Recommended)

To generate a new set of cryptographic keys, there are three main steps. They occur from two different machines, so pay careful attention to which machine you perform each step on.

"Old machine" is the machine that has the original set of cryptographic keys that were generated. "New machine" is the device you want the new set of cryptographic keys on. These new keys will have restricted permissions that only work with NoPorts, and cannot be used for generating other keys.

1. [Old machine] Generate a Passcode

2. [New machine] Enroll the new key pair (send a request for keys from the new machine)

3. [Old machine] Approve the request

For detailed instructions, follow this guide:

Option B) Copy the cryptographic keys from the machine where it's been activated in the past (Not recommended)

• The atSign keys file will be located at ~/.atsign/keys/ directory with a filename that will include the atSign. Copy this file from your other machine to the same location on the machine that you are installing SSH No Ports on, using scp or similar.

Why don't we recommend this approach?

When you use method A, it creates a new set of cryptographic keys. These keys can be disabled individually, which means if a device's keys are compromised, you can disable those keys without affecting your other devices.

This guide is intended for people connecting from a machine running Windows or macOS.

Step 1: Sign up for a NoPorts free trial

TL;DR

Quick Start

Overview

This guide covers the basics to understanding the parameters of npt and invoking npt.

The NoPorts Tunnel, or npt for short, provides an end to end encrypted TCP Tunnel without the need for inbound listening ports on either of your machines.

What is NoPorts? NoPorts is a zero trust security tool that uses Atsign's atPlatform to initiate connections without opening ports on either of your devices. It creates a privacy-first environment, and completely removes network attack surfaces. NoPorts is already being used in the field to do things like , and enable .

How does this technology work? In the simplest explanation, NoPorts utilizes the atPlatform and atSigns to create an encrypted connection between devices over TCP/IP. An intriguing part of this technology is that TCP ports are not open on the endpoints, and the connection is completely invisible to prying eyes with no entry-point for cybersecurity attacks. Any device or application sitting behind NoPorts has no open ports, no static IP address required, and cannot be digitally hacked! This a huge leap forward in cybersecurity as there are no other solutions that can provide this level of system security. Pretty awesome right? We think so too! To further our understanding of how zero trust security is established via NoPorts, let’s briefly discuss the function of an atSign. Then, we can explore the connectivity process with easy to follow diagrams. An atSign is a resolvable address assigned to a device, person, an entire organization, or anything you like. For example, @alice could be an atSign for a person named Alice. An atSign is used to securely exchange information without any chance of surveillance, impersonation, or theft.

Now, let’s look at a diagram of a completed atSign/NoPorts connection between two devices.

In the diagram, you can see two devices connected with atSigns (@PointA and @PointB). The connection is established without having any open external ports on the client or remote machine and any TCP application can be setup to utilize a NoPorts connection. Because all ports are closed, the atSign encrypted tunnel is set up with outbound requests only which are sent to an atServer.

Step 1 to Step 4

These initial steps set up the machine initiating the connection.

This guide provides instructions for connecting from the NoPorts desktop application, to a machine running Windows.

Step 6 to Step 8

Complete these steps on the machine you are connecting to (Windows)

Step 9 to Step 12

With both machines now configured, the final steps bring us back to the machine initiating the connection.

TL;DR

Overview

This guide covers the basics to understanding the parameters of and invoking sshnp.

The four main parameters

-f, --from

This argument is the client address, a.k.a. the from address, since we are connecting from the client. This argument is mandatory, in the form of an atSign. For example:

-t, --to

This argument is the device address, a.k.a. the to address, since we are connecting to the device. This argument is mandatory, in the form of an atSign. For example:

-d, --device

This argument is the device name, which works in tandem with --to to allow multiple devices to run sshnpd under a single device name. By default, this value is "default", so unless you named your sshnpd device the same thing, you will need to include this parameter. For example:

-h, --host

This argument is the address of the socket rendezvous used to establish the session connection. Atsign currently provides coverage in 3 regions, use whichever is closest to you:

Americas

Europe

Asia-Pacific

SSH Authentication

In addition to the four main parameters, it is important to ensure that the appropriate SSH authentication keys are in place.

Pre-existing keys in place

If you already have an SSH public key installed on the device, use -i to specify it. For example:

Automated SSH public key management

If you don't have an SSH public key installed on the device, and -s is enabled for the device, then sshnp can extract the SSH public key from the SSH private key, and send it to the daemon for you. This will automatically authorize your SSH private key. For example:

Manual SSH public key management

If you don't have any SSH public keys in place, you must install them yourself. Copy the SSH public key to ~/.ssh/authorized_keys on the remote device. For example:

Then use the associated private key, as mentioned under :

Putting it all together

An example of a complete command might look like this:

*Note if the username on the remote machine is different than your local machine you will have to also use the -u flag and the -U flag with the remote username. For example, if the remote username is bocbc. If you used the -u flag when running the sshnpd daemon then you can safely omit the -U flag.

Additional Configuration

The rest of the configuration for sshnp is contained in a separate guide:

Want to use RDP, SFTP or etc?

The NoPorts Tunnel (NPT) can carry a wide variety of TCP based protocols such as , , and .

This guide explains how to install and run the NoPorts Policy Service via the command line, and how to use it within the NoPorts desktop application. We recommend running the Policy Server in a Linux environment (virtual machine) for easier management.

Prerequisites

Before you begin the installation, please ensure the following steps are complete:

1. Subscription: You’ve signed up for a NoPorts subscription or free trial.

2. Installation & Activation: NoPorts is installed and atSigns are activated on at least two machines, one to connect from and one to connect to. .

3. NoPorts Desktop App : If you didn’t use the NoPorts desktop app during installation, you can download it here:

Step 1 and Step 2

Step 3 and Step 4

Step 5

Step 6

Step 7

Step 8

You're now ready to use the Policy Service. You can find instructions in the NoPorts desktop application .

Upgrade the sshnpd binary

Upgrading to the latest version of sshnpd follows the same process as installation, as the installer automatically replaces existing binaries with the new ones.

To upgrade, follow the installation guide up to Step 3, then return to this page to complete the process.

Verify the Upgrade

To check the current version of sshnpd installed on your machine, simply execute the binary:

Reload the sshnpd service

After upgrading the sshnpd binary, we must restart the sshnpd service so that it runs using the new version. How you proceed is dependent upon the original installation method you used:

Systemd unit

The universal.shinstaller script will automatically restart the sshnpd.serviceunit.

Any existing config will be preserved.

Tmux session

The installer automatically restarts your tmux session, no other steps required!

Headless (cron + nohup)

Retrieve the Process ID

To safely restart the headless service, we must be slightly more careful with the headless installation. First we must grab the process id of sshnpd:

You should get a single number as output, this is the process ID of the sshnpd process.

Example:

Verify the Process ID

Before we continue, it is good practice to make sure that we have the correct ID:

Example:

As you can see, under CMD we have /home/atsign/.local/bin/sshnpd -a @atsign_device -m @atsign_client -d mydevice -suv. This is the command inside our sshnpd.sh service which used to start sshnpd. This is the correct process that we want to kill in order to restart sshnpd.

Killing the process

Now that we have retrieved and verified the process ID, we can use the kill command to kill the process:

Example:

Verify the Process has been killed

Use the same verification command from before:

Example:

As you can see, there are no entries anymore. This means process 289 has been killed, sshnpd should automatically restart under a new process ID.

Overview

This guide will help you setup NoPorts in your SSH configuration. Once set up, you will be able to ssh to machines using NoPorts the same way you would for a normal ssh host. As this is integrated with the SSH configuration, it will also work with other applications that support SSH proxying.

Usage

Once you've set up your configuration, you will be able to SSH over NoPorts just like any other host, using your own custom hostnames for devices.

For example, with a device called my_lab:

The Template

The following is a template for adding an sshnp connection to your ssh config for ease of use:

You need to replace the values surrounded with <> on lines 1 & 7 with your own values.

host is any valid hostname you would like, this is what you will use to invoke your ssh command, so make sure it's easy to remember and type.

username is the username on the remote machine you wish to login as.

The rest of the values are the normal arguments you would invoke with sshnp, see for more info.

Example

This example shows the configuration for the following equivalent sshnp command:

When you want to connect to this device, this is what you would type:

alice_device maps the the Host alice_device line.

Additional Usage Tips

1. Extending ssh config

You can add any additional ssh config to the file as you normally would, for example a TCP forwarding:

2. Extending ssh command

You can also add any additional flags to the ssh command, for example a TCP forwarding:

Template Explained

If you want to understand each line of the template, and what it does, read on.

Line 1

<host> is the "nickname" you would use to connect to, e.g. ssh <host>.

Line 2

Line 2 is mandatory due to the nature of how sshnp works, sshnp must connect over the loopback interface where the NoPorts tunnel was created.

Line 3

Tell ssh to automatically add the ssh keys to the agent when we load them (we will load them on line 6)

Line 4

Don't cache the connection to known hosts, since sshnp uses ephemeral ports, it is pointless to do so.

Line 5

Because we are using ephemeral ports, it is useful to suppress strict host key checking.

Line 6

The ssh key you would like to load and authenticate with (this is equivalent to ssh -i).

Line 7

A proxy command, which first executes sshnp to determine the ssh proxy command which will be executed, fill in the arguments on this line as you would normally.

See to learn more about filling in this line.

Lines 8 & 9

ControlMaster and ControlPath tell ssh to try to reuse existing ssh connections if you start up multiple. This means only the first connection will setup sshnp, the rest of the connections will use the tunnel that is already there!

Stable Releases

We recommend choosing a release from stable, if there's one available that's supported on your platform.

Desktop App

Our dedicated desktop app is preferred in most cases.

If your use case is primarily SSH, we recommend using sshnp from the section.

Cli Binaries

This includes all binaries for NoPorts.

Beta Releases

These releases are subject to potential instability or breaking changes as we mature the product-line.

Package repo for OpenWrt 24.10 and 23.05

We now have our own package repo for the currently supported releases of OpenWrt. Please follow this guide for installing the Atsign key and adding the packages.

Manual install using the LuCI web interface

First download the latest packages for your chosen architecture from our page.

We've created packages for aarch64_cortex-a53, arm_cortex-a7_neon-vfpv4, mips_siflower, ramips (mipsel_24k) and x86_64; but if your chosen architecture isn't there please let us know by opening an . These packages should work on older OpenWrt (and OpenWrt derivatives like GL.iNet), though note that the LuCI package uses the JavaScript framework that was introduced in OpenWrt 21.02.

With the packages ready to go, sign into the web interface for your router and go to System> Software in the menu. Click on Upload Package and Browse to the csshnpd package you downloaded. Click Open then Upload and Install. Repeat that process with the luci-app-csshnpd package.

For the new menu to appear you'll need to Log out then sign in again.

You can now go to Network>NoPorts and fill out the config tab with your device atSign, manager atSign, device name and the OTP for key generation. Click the Enabled box then hit Save & Apply.

Now go to the NoPorts Enrollment tab and follow the instructions there to generate a device key.

With the key in place navigate to System>Startup and Start the sshnpd service.

Command line installation

The page includes instructions for command line installation. These will work on OpenWrt derivatives that don't use LuCI (e.g. Teltonika) or if you just prefer working on the command line.

Those command line snippets set some variables for the RELEASE number, ARCH for system architecture and PACKAGE name then use wget to download the package from GitHub.

Packages are installed using opkg install for OpenWrt 24.10 and earlier releases that use .ipk type packages, or apk add for newer OpenWrt which uses .apk packages.

For example, to install the c1.0.14 release:

Now edit /etc/config/sshnpd to use your atSigns, device name and device atSign OTP:

Run at_enroll.sh on the device. It will ask you to approvement the enrollment on your client (where you previously activated the atSigns and generated the OTP):

On the device you should see a message saying enrollment is complete, and that the .atKeys file has been written.

Now start the sshnpd service:

And you should be ready to connect to the device:

SNAPSHOT packages

NoPorts is now upstream in SNAPSHOT builds so you can install luci-app-csshnpd from the System > Software page on LuCI. Or for a command line install run:

"Old machine" is the machine that has the original set of cryptographic keys that were generated. "New machine" is the device you want the new set of cryptographic keys on.

Step 1) Generate a passcode from your Old machine

Choose the operating system that is running on your old machine.

Step 2) Make an authorization request on your New machine

Choose the operating system that is running on your new machine.

Step 3) Approve the request on your Old machine

Choose the operating system that is running on your old machine.

This guide provides instructions for connecting from the NoPorts desktop application, to a machine running Linux.

Step 6 and Step 7

Complete these steps on the machine you are connecting to (Linux)

Step 8 to Step 11

With both machines now configured, the final steps bring us back to the machine initiating the connection.

To follow this guide, you will need to set up a NoPorts device (sshnpd)on your home network. For this, you could use a Raspberry Pi, an old PC running Linux, a virtual machine, or even a docker container—the choice is yours. You can get your NoPorts free trial account here and follow the installation guide to get started.

SSH is a hugely versatile tool for command line access, but what if you want a full IP tunnel, like a VPN?

SSH has you covered with the use of two tools: the first is a built in SOCKS proxy; the second is an open source piece of code called sshuttle. With these two tools you can use your sshnp service as your own VPN.

The amazing sshuttle

Once you have NoPorts up and running, you will be able to connect to your device from anywhere on the Internet. You will notice that you did not have to open any ports to the Internet in order to connect. There is no access to the device from the Internet and yet you can connect.

If you are happy with command line access only, great; but you might want to now use your SSH connection as a VPN and have a full IP tunnel. For this, is the perfect tool. However, if you are using Windows, then you will have to set up a local VM/Container. (If that sounds like too much, skip down to the section below on using SOCKS.)

To use sshuttle, we need to make sure that the SSH command itself can log in without any complex arguments. This requires two steps:

1. Create SSH keys: First, make sure that you have created SSH keys.

2. Place public keys on the remote device: Next, either:

   • Manual placement: Place the public keys directly on the remote device.

Once the SSH keys are in place, you can put an entry in ~/.ssh/config to let SSH know which key to use to log into localhost. For example:

The next thing to do is install sshuttle on your machine. The GitHub page details this very well for both Linux and OSX machines.

Once sshuttle is installed, let's use it!

This is a two step process:

1. Connect to the device using sshnp: Add the -x flag. This flag prints out the SSH command that you can cut and paste to log into the remote device.

2. Establish the VPN: In another terminal window, run the sshuttle command to connect to the remote device. You'll need to tweak your IP routing to use this connection as a VPN. The important part is to use the port number that the -x flag gave you in the sshuttle command.

With this example, you can see that port 63155 was used in the sshuttle command. You do not need to SSH into the machine—you can just get the port number and use sshuttle. The choice is yours.

This can get a bit tedious to do every day so feel free to script for your environment. Here is an example bash script that does just that!

SOCKS

If you are using Windows, this is likely your best option unless you are comfortable setting up a virtual machine and using sshuttle.

All you need to do is add an option to the normal sshnp command and that will set up a local SOCKS proxy: -o "-D 1080" That's it!

This will set up a local SOCKS proxy on your machine that will forward requests to the remote device. In effect, you will be at home whilst away. To use this SOCKS proxy, you need to tell your browser or your Operating System. The Firefox browser is the simple choice, and in settings you can configure it as shown below:

Once you have setup Firefox, you can browse as if you were at home! On Windows and Mac, you can configure your SOCKS proxy in directly in the OS in settings. This works, but you have to remember to remove the setting once you have disconnected from the sshnpd session.

Summary Table (Quick Reference)

❌ Issue: Timeout to srvd

Symptom You receive the following error while using NoPorts: TimeoutException: Connection timeout to srvd <atsign> service

Possible Causes

• The relay atSign (-r) is not running or doesn’t exist

• The device atSign (-t) doesn’t exist

Solution

• Double-check the relay and device atSigns for typos

• Use sshnp --list-devices to verify device availability

❌ Issue: Daemon Feature Check Timeout

Symptom TimeoutException: Daemon feature check timed out

Possible Causes

• No device is running with the specified device name (-d)

• You lack permission to connect to the device

Solution

• Confirm the device is online and registered

• Ensure your atSign has permission to access the device

❌ Issue: Keys Not Found After Install

Symptom Keys are not found after device installation

Root Cause sshnpd was installed as root, but the enrollment was also done as root. The keys were saved to /root/.atsign/keys/ instead of the correct user directory.

Solution

• Always enroll using the same user that sshnpd runs under

• Add a warning in the docs or script to prevent root-based enrollment

❌ Issue: Client SSH Error "chown failed error"

Symptom Error message: invalid daemon response: chown failed error: Operation not permitted

Root Cause Raspberry Pi may behave inconsistently with localhost vs 127.0.0.1, or file permissions are incorrect.

Solution

• Use --permit-open="127.0.0.1:22,127.0.0.1:3389,localhost:22,localhost:3389"

• Ensure ~/.ssh is owned by the correct user:

❌ Issue: Windows App Hangs on Activation

Symptom NoPorts desktop app hangs on “preparing for activation”

Root Cause Outdated CA certificates on Windows 11

Solution Follow these steps to update root certificates:

1. Run Windows Update

2. Open Command Prompt as Administrator

3. Run:

4. Verify with certmgr.msc

❌ Issue: Enrollment Authorization Failed

Symptom Failed to authorise enrollment. Client is not authorised for namespaces in the enrollment request.

Root Cause You’re using a previously enrolled key for a new enrollment.

Solution Use the correct manager keys for enrollment.

Step 1 to Step 4

These initial steps set up the machine initiating the connection.

Step 1. Run the installer

Step 1 to Step 4

These initial steps set up the machine initiating the connection.

Step 1. Run the installer

Step 1. Run the installer

Install IPFire

IPFire provides a solid Firewall and uses a base Linux OS. The installation of the OS itself is well documented at ipfire.org. X64 and Arm devices like Raspberry PI's are well supported.

Make sure to configure the network interfaces and ensure you can get to the Web Interface on

Step 1 to Step 4

These initial steps set up the machine initiating the connection.