LogoLogo
  • NoPorts Documentation
  • Getting Started
  • Installation
    • Quick Start from macOS or Windows
    • Connecting from macOS
      • macOS to macOS
      • macOS to Linux
      • macOS to Windows
    • Connecting from Linux
      • Linux to macOS
      • Linux to Linux
      • Linux to Windows
    • Connecting from Windows
      • Windows to macOS
      • Windows to Linux
      • Windows to Windows
    • Cloud Installation Guides
      • Automated Installation on Amazon Web Services (AWS)
      • Automated Installation on Google Cloud Platform (GCP)
      • Automated Installation on Microsoft Azure
      • Automated Installation on Oracle Cloud Infrastructure (OCI)
    • OpenWrt Installation Guide
    • Manual Installation Guides
      • Device Installation
        • Tmux session
        • Standalone Binaries
        • Systemd Unit
        • Headless
      • Client Installation
    • Custom OS/Device Installs
      • IPFire
    • Installs at Scale
    • Upgrading NoPorts Software
      • NoPorts Client Upgrade
      • NoPorts Daemon Upgrade
    • Available Releases
  • Use Cases
    • SSH
    • SFTP
    • RDP
    • Web Server
    • SMB
    • Be your own VPN
  • Usage
    • npt Usage
    • sshnp Usage
      • Client Additional Configuration
    • sshnpd configuration
      • Daemon Additional Configuration
  • Integrations
    • OpenSSH Config
    • PuTTY config
  • Resources
    • How to activate an atSign
    • Reuse your client atSign on another machine
      • Generate a new set of cryptographic keys
    • How to name a device
    • How to generate SSH keys
    • Why activate the device atSign on the client?
  • Product Information
    • The NoPorts Philosophy
    • NoPorts Desktop Application
    • NoPorts Policy Service
    • Frequently Asked Questions
    • How It Works
    • Under The Hood
    • Sequence Diagram
  • Related Pages
    • Main Site
    • GitHub
Powered by GitBook
On this page
  • TL;DR
  • Overview
  • The three main parameters
  • 1. -a, --atsign
  • 2a. -m, --manager, --managers
  • 2b. -p, --policy-manager
  • 3. -d, --device
  • Putting it all together
  • Running the daemon as a service
  • Additional Configuration
  • Modifying your device's systemd unit
Edit on GitHub
Export as PDF
  1. Usage

sshnpd configuration

PreviousClient Additional ConfigurationNextDaemon Additional Configuration

Last updated 12 days ago

TL;DR

sshnpd -m @<_client> -a @<_device> -d <name> 

Replace the <??> with your specific atSign details

Overview

sshnpd is the daemon that runs on a device to facilitate access using NoPorts.

The three main parameters

These mainly mirror the parameters from , but there's one fewer as the socket rendezvous is only ever set by the client.

1. -a, --atsign

This argument is the device address, a.k.a. the to address, since this is the address that the device is associated with. This argument is mandatory, in the form of an atSign. For example:

sshnpd ... -a @alice_device ...

2a. -m, --manager, --managers

This is the address of the client(s) that will be allowed to connect to the device. For example:

sshnpd ... -m @alice_client ...

2b. -p, --policy-manager

As an alternative to defining a list of managers a policy manager can be used, and the policy defined on that manager will describe which clients are allowed to connect. For example:

sshnpd ... -p @alice_policy ...

3. -d, --device

The device name. This is used to associate multiple devices with the same atSign. By default the value is default so unless you want that as the device name you will need to include this parameter. For example:

sshnpd ... -d my_device ...

Putting it all together

An example of a complete command might look like this:

sshnpd -a @alice_device -m @alice_client -d my_server

Running the daemon as a service

The daemon should normally be run as a service so that it starts up automatically and can be restarted if it should fail.

Additional Configuration

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

Modifying your device's systemd unit

If you installed sshnpd through the universal installer, then you can modify the /etc/systemd/system/sshnpd.service.d/override.conf file to take advantage of the configurations and options listed above to tailor sshnpd to your needs.

Lots of configuration can be done to sshnpd by editing this file, such as changing the user that sshnpd runs as, changing the atSigns, enabling/disabling verbose logging, and more.

Sample override.conffile:

# MANDATORY: User to run the daemon as
User=bob

# MANDATORY: Manager (client) or policy manager address (atSign)
Environment=manager_atsign="@alice"

# MANDATORY: Device address (atSign)
Environment=device_atsign="@bob"

# OPTIONAL: Delegated access policy management
Environment=delegate_policy=""

# Device name
Environment=device_name="atsign"

# Comment if you don't want the daemon to update authorized_keys to include
# public keys sent by authorized manager atSigns
Environment=s="-s"

# Comment to disable verbose logging
Environment=v="-v"

# Any additional command line arguments for sshnpd
Environment=additional_args=""

Adding additional arguments is as simple as modifying the Environment=additional_args=""string found inside of override.conf .

The example adds the --permit-open to the string of additional args which enables clients to access ports 22, 3389, and 2221 on localhost.

# Any additional command line arguments for sshnpd
Environment=additional_args="--permit-open \"localhost:22,localhost:3389,localhost:2221\""

Don't forget to update sshnpd by executing (may require sudo):

systemctl daemon-reload
systemctl restart sshnpd.service

Most mainstream Linux distributions use to manage services, and we provide a systemd unit file that's configured by the universal installer. That file can be edited after installation to customize or add additional options. For distributions such as OpenWrt we provide config and init files that can be customized with a text editor or configured through the web admin interface.

sshnp
systemd
Daemon Additional Configuration