Twenty Ways

There has quite a bit of buzz about the RTL-SDR project that is going on over at reddit on the rtl-sdr subreddit. Most of it has been about using the RTL2832/e4000 devices under Windows and Linux. Since I primarily use Mac OS I decided to cobble together the various hints of other people who have successfully used the devices on Mac OS and document them in a gist on github:

https://gist.github.com/2874757

Update: After some feedback on reddit for the previous gist I decided to revisit my build to that I would have a more up to date version of GNURadio. After much hacking I came up with these directions for getting GNURadio 3.6.0 working on 10.7:

https://gist.github.com/2eb4ff8e240164d0f751

After following those directions you’ll want to then install the rtl-sdr driver and then gr-osmocomm so that you’ll be able to use the RTL tuner with gnuradio.

nginx defaults to running its master process as root and all workers as nobody.

You can tell nginx to run worker processes under different credentials by setting the user directive in nginx.conf.

On OS X, you need to specify a valid group as well, since nginx will default to looking for a group that doesn’t exist. You will see “nginx – getgrnam()” in the error log when this happens. The easiest solution I found is to assign the OS X staff group:

user userid staff

It probably bears mentioning that changing the runtime credentials won’t negate the need for sudo if you run your web server on port 80, since OS X (and all Unixes) will not allow nginx to use that port unless it runs as root.

Lion’s Terminal app and its tabbed full-screen mode is a huge improvement for me. One thing that became a minor annoyance, however, is Terminal’s failure to quit when the last console session ends: Cmd-Q is still required to quit the app completely.

The workaround I chose takes advantage of existing muscle memory.  I had already configured an alias for exit, allowing me to type x to end a console session.

To solve the Terminal app problem, I repurposed x as a function in my ~/.bash_profile:
function x {
[ "$(w -h | grep "^$(whoami) *s[^ ]* *-"|wc -l)" -le 1 ] && osascript -e 'tell application "Terminal" to quit' || exit
}
The function checks for the number of active console sessions. When x is called and only one session remains, osascript is invoked to quit the Terminal app completely.

We talked about port forwarding recently. This helps you get access to single resources but it requires a lot of planning and configuration. It would be pretty awesome if SSH had a proxy feature.

Lucky for us all there is the -D option for the ssh command. This option turns the ssh connection in to a SOCKS proxy on the remote server. The potential uses for this are huge. I often use this feature to gain quick access to my whole network.

Setting it up

superbox$ ssh -D 31337 someserver

Using it

To use this you will need to configure your applications to connect through the SOCKS proxy. Firefox is pretty easy to configure. The settings for the proxy live in the Preferences under the Advanced section in the Network tab. Click the Settings… button to bring up a dialog similar to the one on the right. Set the SOCKS host to localhost and the port to the one you chose when connecting.

Now that the proxy is setup you can test out that you’re proxy is working by visiting http://whatismyipaddress.com/ to check to see if it looks like you are accessing the site from a new IP address.

In the next installment of SSH Tricks we’ll talk about using ssh config files to save time and energy.

SSH is the ultimate tool for shifting bits around networks in a secure manner. This is the first of a series of articles on SSH tips. This article is all about the basics; as the tips progress, we will get trickier.

Overview

Port forwards are a way of mapping a TCP from one side of the ssh connection to the other. They are established using the -L and -R parameters to the ssh command. These stand for local and remote port forwards. A local forward takes a port on the local machine and connects it to an IP address and port from the remote machine. As you suspect, a remote forward takes a port on the remote machine and connects is to an IP address and port from machine you are connecting from.

Examples

You could forward port 80 from an  internal web server to port 8188 on the machine you are connecting from. This is a sort of poorman’s VPN. You can gain access to resources inside your network via SSH local port forwards. After connecting to your gateway machine you would be able to access the web server at http://localhost:8188.  To actually do this the command would look like this:

superbox$ ssh -L 8188:internalweb:80 homerouter

Another common use for this is securing VNC access. Many VNC servers offer the option to only accept connections from localhost. By combining this option with a ssh local forward  you can create an encrypted VNC session. This would be done by doing:

superbox$ ssh -L 5900:localhost:5900 vncserver

Remote port forwards are much less common. Lets say you have a local web server running on your workstation and you’d like your friend to take a look at an error on a hot new web app. you’re developing. The catch is you don’t want to let them login to your machine to do a local forward to gain access to your server. In this case you could use a remote port forward like this:

superbox$ ssh -R 8188:localhost:80 untrusted-friend

Your somewhat trustworthy friend could then access your web server at http://localhost:8188.

In the next installment of this series we will reveal a way to make your SSH connection behave even more like a VPN.