velociped wrote:
Working from attempt #3, a question followed by a comment…
Let me see if I am following you on this. You are attempting to reroute SSH through HTTP on your remote/home/server end on port 50100. You are then initiating an HTTP tunnel from the client/work end from 12345, locally, to 50100 on the remote/home/server end. Finally, you are creating a tunnel from port 4000, locally, to port 3689 on the remote/home/server machine. Am I understanding this correctly?
Yes. An HTTP tunnel through which I shove an SSH tunnel.
This seems unduly complicated to me. Forgive my ignorance of the HTTP proxy, but why not simply create the HTTP tunnel directly between the client/work end and the ssh port on your remote/home/server? (e.g. htc -P myproxy -F 12345 my.ip:22. Then it simply becomes a matter of routing all of the other requests through the SSH tunnel.
Unfortunately it’s not quite so simple. From what I understand, httptunnel requires both a client (htc) and server (hts) process to function. This is because it adds an additional HTTP header to every packet, and as such, needs a server process to strip the headers before pushing them out of the tunnel. Because of this, the tunneling cannot simply forward to the SSH server.
I want to clarify why I even bothered building an additional SSH tunnel. From my first attempt it seemed as if httptunnel could not multiplex multiple connections through the tunnel. I thought perhaps using SSH as the sole connection and relying on the SSH tunnel to multiplex the connections would work.
Next, it is not necessary to create a bogus DAAP port locally. In fact, it may be counter productive. Unless you have other DAAP shares on the local subnet, simply reroute that port to the remote/home/server. (e.g. ssh -l [email protected] -N -f -L 3689:my.ip:3689 — assuming the machine at the remote/home/server is the same as that running mt-daapd. If using NAT, you will want to substitute the internal address for the server in port forwarding parameter (e.g. -L 3689:internal.address:3689).
I failed to mention that I did try with port 3689 too. When it first failed, I tried 4000, thinking that ssh may short circuit port forwards of “3689:localhost:3689” since there are situations where that would be meaningless.
Your recent post also neglected to mention your handling of the mDNS beacon. You will need to republish the remote/home/server beacon to the client/work subnet. This is accomplished by issuing a command such as mdns -R 127.0.0.1 squeal “shareName” _daap._tcp. 3689 & on the client/work local end (or using one of the GUI utilities mentioned in the document wiki. In fact, you should basically be able follow the directions in that document verbatim once the SSH connection is initiated through the HTTP tunnel.
I appreciate your diligence in ensuring that I followed the correct steps, but I’m almost positive that I carried this out correctly. I’m using the mdnsresponder (based on Howl) available through the Debian repository, which has a config file where all of the published services live. I followed the examples listed there and, in attempt one, this was good enough to get my iTunes computer to see the forwarded mt-daapd server AND get the DB. So I’m nearly positive that this part of the procedure is working. I’ll give it another shot tomorrow at work and report back with my success.
Herman