Under The Hood

This document describes version 5.6.x Other versions use a different method of forming the connection.

Overview

There are four atSigns involved - one for each of

  • the noports daemon program (sshnpd) which runs on the device you want to ssh to

  • the noports client programs (sshnp/npt) which you run on the device you want to ssh from

  • the noports tcp rendezvous program (sshrvd)

  • if required a policy engine

The programs communicate via the atProtocol and the atClient SDKs; as a result, the payloads of the messages the programs send to each other are all end-to-end encrypted.

In brief

  • The client (sshnp/npt) creates a unique guid for the session

    • and sends a request notification to the sshrvd for a port1/port2 pair for this sessionId

  • The sshrvd

    • finds a pair of available ports

    • opens server sockets for both of them

      • Note: rvd will allow just a single client socket to connect to each server socket

        • and will bridge them together

    • sends response to the client

  • The client

    • receives the response notification from sshrvd (rv_host, rv_port_1, rv_port_2)

    • and sends a request notification to the sshnpd including the sessionId and the rv_host:rv_port_1 and a new ephemeral AES 256 key

  • The daemon (sshnpd)

    • opens a socket to the rv_host:rv_port_1 and authenticates

    • and opens a socket to its local sshd port

    • and bridges the sockets together whilst also encrypting data towards the rv_host

    • and sends a response notification to the sshnp client

  • The client

    • Listens on a specified port and on connection encrypts traffic received with the AES key and forward on to the rv_host

  • The client displays a message to the user that they may now ssh -p $local_port $username@localhost, i.e. ssh -p 58358 gary@localhost in the example above, and exits

This high-level flow is visualized in the diagrams below.

NB Requests from unauthorized client atSigns are ignored. Note that one may also completely prevent requests from any other atSigns ever even reaching the daemon by using the atProtocol's config:allow list feature.

In the personal edition of noports, a daemon may have only a single authorized client atSign.

The Team and Enterprise editions will allow for multiple authorized client atSigns, controlled not by the daemon but by a separate noports authorization controller process, with its own atSign.

Overview diagram

Policy Plane

At any point the sshnpd or the srvd software rather than using a local configuration to manage access rights, can forward those questions to another atSign. That atSign can in turn pass those queries to a policy engine and reflect the answer back to the asking atSign. In the example above @relay and/or @server could ask if @client is allowed to access the service. This allows decisions to be made at the Policy plane level and provides operational segregation of duties.

Control plane

In the following sequence diagram, atServer address lookup flows, authentication flows, key exchange flows, precise encryption mechanics and notification transmission flows are not covered in detail; those details are provided in the links provided in the "Further Details" section below.

Since the full details are provided in those other links, the client_1 -> atServer_1 -> atServer_2 -> client_2 message flows are abbreviated to @atSign_1 -> @atSign_2 in the sequence diagram. Thus, for example, sshnp (@client) encapsulates both the sshnp program and the sshnp atServer

Data plane

Once the interactions above have completed

  • the sshnpd nor the sshnp programs are no longer involved

  • there is a new sshrv process running on the device host which pipes i/o between requested server:port and $rv_host:$rv_port_1

  • there is a client process running on the client host which provides the local port forwarding tunnel

  • User may now type "ssh -p $local_port username@localhost" or use a client application like and RDP client with traffic flowing

    • client ssh program <===>

      • $client_localhost:$local_port <===> bridged by client-side ssh tunnel to

        • $rv_host:$rv_port_2 <===> bridged by sshrvd to

          • $rv_host:$rv_port_1 <===> bridged by device-side sshrv to

            • $device_host:22 <===>

              • device sshd program

Further Details

In the sections above, we referred to "authentication", "sending notifications" and "receiving notifications", and we made the statement that "the payloads of the messages the programs send to each other are all end-to-end encrypted"

Here are some links to detailed diagrams covering

PreviousHow It WorksNextSequence Diagram

Last updated