ssh-ecurity — Part 7: Remote possibilities...
Music has always figured prominently in my life. About eight years ago, I discovered an internet radio station called Aural Moon. Aural Moon has a vast and ever-expanding library of progressive rock music; the music that defined my youth and which has always been a factor in my life. Most of my friendships, even the one that culminated in marriage, were defined by this music. I listened to Aural Moon for a year or two and then, one day, I finally signed myself up and logged into the associated web site. I discovered a great community there and I made even more music-defined friendships. A couple of years later, I found myself hosting the Aural Moon web site, and handling its daily chores and duties to keep this great music on-the-net. It's an altruistic labor of love for both the music and its community.The station's streaming server is located remotely quite some distance — 1000 miles — from the web server. Both systems communicate with each other over the internet. The music that is being streamed can be requested from the web site through some crafty scripting and web forms, and these selections traverse the vast expanse between these two machines via the internet and SQL queries. No DJing is necessary; even though there are a few shows controlled by select hosts.
The streaming server runs a very popular broadcasting software package which has its own object orientated scripting language for controlling aspects of the broadcast programming. This scripting language has an "escape" to SQL Query mode too to really augment its capabilities. I've also been using ssh local tunneling to access the MySQL database on both the streaming server and the associated web server.
Like I said earlier, the content of the daily programming is controlled by the listeners. They login to the web site and, with the aid of some scripting and SQL queries, they can lookup and request the music they'd like to hear. When there are no requests to play, the software makes random selections from the huge volume of tracks on the music library — over 40,000 tracks at the time of this blog.
However, not all of the music played is programmed by requests or random software selection. There are several shows in which hosts (DJs) are responsible for the content that is played. Several of these shows consist of the host simply uploading a playlist of tracks and some pre-recorded voice-over tracks. The scripting language of the streaming server software has been setup to program queueing of these playlists at the appropriate scheduled time-slot.
One show that is carried each week is a live show broadcast on an FM channel in the Philadelphia and southern New Jersey area. Aural Moon simulcasts this show over the internet. The show is broadcast from the source (the FM radio station studio) to Aural Moon using a Shoutcast server. The Aural Moon streaming server has been programmed to automatically connect to this Shoutcast feed at the appropriate time-slot to relay the show to Aural Moon listeners. Shoutcast uses port 8000. In the programmed rules, which are set into motion at the appropriate time slot, is the URL: http://theFMradioDomain.com:8000. The station software automatically connects to this Shoutcast feed from the FM radio station and, in turn, it relays it to Aural Moon listeners. A fully automated system.
This same show host was recently going to broadcast live from one of the most prestigious progressive rock festivals in the world. It's currently in its 11th year. Aural Moon was to broadcast this live from the same festival. I was, naturally, the one to see to it that this all went off without a hitch. The biggest obstacle was how to get the show to the Aural Moon streaming server. Hardware and software were no issue. I could lend my MacBookPro to the task for the transmission and the MacBookPro is configured with Nicecast — a Shoutcast like application for Mac OS X. Now the only issue was internet access to get the broadcast to the Aural Moon server. I thought about using my Sprint EVDO which I did test and it was capable of sustained 128k bps MP3 but that wouldn't be sufficient to also allow me to keep tabs on the station and monitor its relay of the show too.
Fortunately, the host hotel for this festival had high-speed internet access and even permitted me to connect directly to the hub in their communication closet. At least, I didn't have to suffer the hotel-wireless. However, I was still required to use the hotel's guest authentication web page and agree to its 10 gazillion word terms and conditions statement — you know, the one nobody ever reads but agrees to to access the internet — to get outside access. OK, now I had internet access but there was still one hitch. This network was DHCP and there was no way to get the powers that be to map port 8000 back to my DHCP served address. What to do?
Fortunately, yet another ssh feature was available — remote tunneling. Like local tunneling, an application communicates using a port on the localhost. The problem here is that I am not the one connecting to a remote service; it is the remote streaming server that needs to connect to me! Remote tunneling provides just that! In fact, you can think of it as local tunneling, since you now know and understand that implicitly, but on the remote side. That's really not that far from the fact.
With ssh remote tunneling, you tell the remote server to create the association to localhost:port-number and tunnel that to your local machine's local port number. So, in order to transmit this live broadcast, all I had to do was ssh into the remote server and establish a remote tunnel to localhost:8000 associated with my local client's (the MacPookPro) port 8000 which was tied to the Nicecast transmission. I changed the definition in the remote server's description file to http://localhost:8000 and setup the scripting to launch this at the appropriate time. The MacBookPro sat there transmitting everything coming off the board completely content that nobody was connected to listen. When the appropriate time rolled around, the streaming server's script connected to localhost:8000 and everything coming from the board was tunneled to the streaming server relay and, subsequently, to the Aural Moon listeners. Simply amazing!
So, what is the syntax for such a tunneling operation? Again, it's simple and fairly universal. The remote tunnel is indicated with the switch
-R and the argument to this switch is remote-port:remote-host:local-port. Let's see what this looked like in terms of setting up the remote broadcast.
macosx% ssh -R 8000:localhost:8000 username@auralmoon
username@auralmoon's password:
macosx% netstat -an -p tcp | grep 8000
TCP 127.0.0.1:8000 0.0.0.0:0 LISTENING
macosx%
There you can see that a LISTENING port on port 8000 has been established on the remote system. This port is now ready to service the automated, scripted connection to http://localhost:8000 when the time is right. The server which will respond to this LISTENING port is actually the Nicecast process on the local MacBookPro.
This technique works and it works well. In fact, Aural Moon recently celebrated 10 years on-the-air. A 24-hour broadcast, all the way from the southern tip of England, used this remote tunneling to carry 10th Anniversary programming. I'm certain that if you think about this, you too can find some splendid uses for remote tunneling too.
Frontpage
