Semantics cn cloud the issue. Every PC with RDP is a server, and the support dude has the client. The tcp client sends the first packet SYN, and if there is a listening socket, that replies with the second, reply packet SYN ACK. An ssh tunnel listens on one end of the ssh session host pair on some specified port, as a server, and forwards connections to the opposite end host to a new client socket connected to the host and port specified. So, ssh is the obvious tool, as long as one end is visible to each end. If you ssh localhost, the two middle hosts can be the same host.

Suppose on host A you "ssh -L 3389:C:3389 B", forwarding A:3389 to new client connections on B (high port) to port 3389 C, which is the target PC to be serviced port 3389. When your tech points his RDP client host D to A:3389, it will really be talking to the target PC RDP service. The RDP client D connects a socket on D:high-port to A:3389, A sends via ssh client app inside ssh connection to sshd server on B, which makes a new socket, connects it to C:3389, and everyone shuffles data flow both ways.

Security rules sometimes prevernt -L, but sometimes -R is legal, where the listening server part of the tunnel is on the sshd server end, and the new client sockets originate on the ssh client app.

Often, the problem is really simpler, and all that is not needed. A firewall E in the middle may able to see both C and D even though they cannot see each other, like if C is on the internet and D is on a 10. unroutable address. Using NAT or tcpRelay, it can listen for D and connect to C.

Now, if you want a dynamic service where many PCs can be the target, something like a web service could set up the forwarder or tunnel to the indicated host. For security, it is nice if there is a timeout and some filtering of incoming connections, so only D can temporarily get that connection to C:3389.