rportd.conffile and how to install the server with custom ports right from the beginning.
🧨 Caution You must enter a valid email address that will be used for the two-factor authentication. The email is stored only in your local database. The FQDN of the server must exist on your local DNS or at least enter it to
/etc/hostsbefore you start the installation.
💁 Insider tip Use
--email <EMAIL>to use two-factor authentication with mobile apps like Google or Mircosoft authenticator.
💁 Insider tip The default http(s) ports 80 and 443 are used. If you create the DNS record and the port forwarding before you start the installation, Let's encrypt certificates are automatically generated.
[server] address = "<IP>:<PORT>"in the
rportd.conf. The rport clients aka agents will connect to the server on this port. We suggest using port 80 because corporate networks usually do not block outgoing traffic on port 80. Plain HTTP is used, no certificates are needed. The encryption happens on application level and client and server handle it autonomously based on the SSH protocol over HTTP. You are welcome to use any other port, if firewalls allow outgoing connections over this port or if you plan to run the server and all clients on the same intranet. 🔅Use the server installer with
--client-port <INT>to install your rport server on a different port than 80.
[server] url = "http://<HOST>:<PORT>". This is an optional setting, only used to generate the pairing script for fast and easy client installation. The
[server] urlmight differ from
[server] addressif port forwarding is used. The server might listen on
192.168.1.1:8080, but your clients will connect to the public DNS of your router, where a port forwarding is active. So
[server] urlmight be
http://rportserver.dyndns.org:8080, for example. By default, the server builds the client connection url with the FQDN and the client connection port. You must use this option if your remote systems are located outside your intranet (blue area) but you access the UI only from inside (yellow area) using an internal hostname. 🔅You can overwrite it with
[api] address = "<IP>:<PORT>"in the
rportd.conf. This is the port used for HTTPS connections to the dashboard, to connect the rportcli and to send API requests to. We strongly recommend using HTTPs. By using the default port 443 you achieve maximum accessibility from external networks. Using a different port than 443 is possible. Read the note about the SSL certificates. Even if you plan to access the user interface and the API only from inside your local intranet, do not turn off TLS/HTTPs. The rport server might have full root access to all clients. Sniffing your credentials over an unencrypted connection inside a local network is trivial. Credentials might give full access to all clients. 🔅 With
--api-port <INT>you can instruct the server installer to use a different port than 443. The server installer will always enable HTTPS. Switching off encryption is not possible.
[server] used_ports = ['20000-30000']in the
rportd.conf. These are the ports dynamically opened for the tunnels. This is where you connect your SSH, RDP, VNC, etc. clients to, to get access to the remote systems of the encrypted tunnel. The port range determines the maximum concurrently running tunnels. On a small setup, ten thousand might be too much. Please don't hesitate to use just a dozen. You can extend later. 🔅Use the sever installer with
--port-range <START>-<END>- e.g.
--port-range 5000-5010to install the rport sever using just these ports.
portd.conf. If you run the client connection port internally on 80, but you map it to the external port 8080, client connections will fail, unless you change the port manually in the client configuration file.
/etc/rport/ssl/ca/export. All users must import this root CA into their operating system and optionally directly into Firefox.
http://<RPORT-SERVER-IP>:<PORT>/rport-ca.crt. The installer created a symbolic link, so the certificate is reachable via the built-in web server.