The special handling of \\TSCLIENT\<sharename>, as well as RDPCLIP which forwards newly captured clipboard content in both directions, are closest to the tunneling you are describing. The RDP protocol does seem provide the bits and pieces that would let you write a tunneller, but long ago I threw a few days at the problem and got nowhere.
late update: ...
I figured out that it has not really anything to do with ssh, but with IP tables on the server (where sshd runs):
# iptables -S | grep 22
-A ufw-user-input -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -m recent --update --seconds 30 --hitcount 6 --name DEFAULT --mask 255.255.255.255 --rsource -j ufw-user-limit
For me this was a permissions issue on the .ssh/authorized_keys file for the user connecting. Saw this when I changed the logging to:
To correct the permissions on the .ssh/authorized_keys file; right click properties -> Advanced button (bottom right) -> Change owner (at top) to the users account. Restart the ...