RPort Technology Explained
What happens behind the scenes
RPort is based on a client-server principle. There is a central server. The clients connect to this server. This ensures that the server can always reach its clients, even if they change their IP address or are behind a NAT.
Clients establish their connection via HTTP. The use of HTTP proxies is supported. Within the HTTP connection, an SSH connection is established from the client to the server. Thus, the entire communication is encrypted. Proxies must allow HTTP CONNECT. Consequently, encryption happens at the application level and not at the transport level.
The client must know the fingerprint of the server before the connection is established. If the fingerprint does not match the server, the client refuses the connection. This prevents a possible man-in-the-middle attack.
The statically compiled client has all SSH libraries on board. It does not access SSH program files in the operating system.
Don't get confused. The above describes how communication is encrypted via SSH. The tunnels are not limited to use SSH for remote access only. Any protocol can be used. See below.
RPort uses the SSH library GoSSH from Google. Only SSH2 is used with the standard ciphers
aes128-ctr, aes192-ctr, aes256-ctr and [email protected]. Authentication is not done with keys, but with username+password+fingerprint. The users determines the password strength.
Once the SSH connection tunnelled through HTTP is established, the client and server establish a so-called control channel based on web sockets. Through this channel, the server can send commands to the client. Whether and how the client passes commands to the operating system or a shell can be specified in great detail in the client configuration. For example, the user can only allow a service to be restarted or updates to be applied. Under Unix, this requires additional Sudo rules. The client has its own unprivileged user and does not run with root privileges.
If the user wants to access a TCP or UDP port of a client, for example port 22 for SSH or 3389 for the remote desktop, the server instructs the client to establish a reverse tunnel. This also happens via SSH through HTTP. This makes local ports of the clients available on the server. The ports forwarded in this way are protected by default with an access control list. Only the user who initiated the tunnel can use it. ACLs can be adjusted or disabled per tunnel. This allows services such as a web server to be shared on the Internet when systems are located behind NAT routers.
Tunnels are not limited to localhost. Any client can forward a remote TCP port to the server. This provides access to browser-based configurations of printers, NAS devices, routers, or switches.
Tunnels are not bound to a specific protocol on application level. RPort forwards raw TCP or UDP packets. On creation of a tunnel, you can optionally specify a protocol such as SSH or RDP etc. This information is just for convince to remind you, what the tunnel was created for. Once a tunnel is created, you can pass any application traffic through it.
The RPort server is controlled via REST API. Since each client gets its own REST endpoint, the clients also become controllable via REST. This makes numerous automation use cases possible.
RPort also comes with a modern web interface. This allows the customer to conveniently manage their entire infrastructure.
Last modified 12d ago