-
Notifications
You must be signed in to change notification settings - Fork 28
Use cases
This page describes typical usage scenarios for the application.
We're assuming in the following examples, that an end user called Alice wants to make her screen available to a support staff called Bob. Alice only requires an installation of Remote Support Tool. Bob on the other side will have to make some preparations in order to make remote administration possible.
In this scenario Alice sends her desktop through an unencrypted VNC connection to Bob.
- In case that Bob sits behind a router / NAT, he has to open the VNC port (5500) in his router / NAT and has to forward incoming traffic from this port to his local machine, where the VNC client is listening.
- Bob has to start a VNC client in listening mode.
- Bob has to tell Alice his public IP address and the port number to access his VNC client.
-
Alice enters Bob's IP address and port number into her Remote Support Tool and clicks
Connect
.
- best possible performance - because there is no overhead for encryption / decryption
- VNC traffic is transferred unencrypted. This method should not be used when communicating over the internet.
- Bob has to open a port in the firewall of his router / NAT, what can be a security risk.
In this scenario Alice sends her screen through a secure connection (SSH tunnel) to Bob.
- Bob has to install a SSH daemon on his machine.
- Bob should create a separate user account, that is used for authentication via SSH on his machine. Authentication may be realized with password or public / private key.
- In case that Bob sits behind a router / NAT, he has to open the SSH port (22) in his router / NAT and has to forward incoming traffic from this port to his local machine, where the SSH daemon is listening.
- Bob has to start a VNC client in listening mode.
- Bob has to tell Alice his public IP address, the port number of his SSH daemon and the port number to access his VNC client.
-
Alice enters Bob's IP address and both port numbers into her Remote Support Tool and clicks
Connect
.
Notice:
Remote Support Tool automatically opens the SSH tunnel. The corresponding
ssh
command looks like:ssh -C -x -L 5500:localhost:5500 -p $SSH_PORT $SSH_USER@$ADDRESSwith
$SSH_PORT
as the port number of Bob's SSH daemon$SSH_USER
as the user name to authenticate at Bob's SSH daemon$ADDRESS
as Bob's public IP address / hostname
- VNC traffic is transferred encrypted.
- Bob has to open a port in the firewall of his router / NAT, what can be a security risk.
In this scenario Alice sends her screen through a secure connection (SSH tunnel) through a SSH gateway to Bob.
-
Bob has to install a SSH daemon on his machine.
-
Bob should create a separate user account, that is used for authentication via SSH on his machine. Authentication may be realized with password or public / private key.
-
Bob has to open a reverse SSH tunnel to the gateway server - e.g.
ssh -C -x -R 0.0.0.0:12345:localhost:22 $GATEWAY_USER@$GATEWAY_ADDRESS
opens port
12345
on the gateway server and forwards incoming traffic to Bob's local SSH daemon on port22
. -
Bob has to start a VNC client in listening mode.
-
Bob has to tell Alice the IP address of the SSH gateway, the port number of the SSH gateway and the port number to access his VNC client.
-
Alice enters the IP address of the SSH gateway and both port numbers into her Remote Support Tool and clicks
Connect
.
Notice:
Remote Support Tool automatically opens the SSH tunnel. The corresponding
ssh
command looks like:ssh -C -x -L 5500:localhost:5500 -p $SSH_PORT $SSH_USER@$ADDRESSwith
$SSH_PORT
as the number of the previously opened port (12345
)$SSH_USER
as the user name to authenticate at Bob's SSH daemon$ADDRESS
as public IP address / hostname of the SSH gateway
- VNC traffic is transferred encrypted.
- No port forwarding in a router / NAT is required - neither for Alice nor for Bob.
- VNC traffic is partially double encrypted. This leads to more overhead and therefore the performance is less good.