SOCKS proxy over SSH

Here goes a quick and valuable tip people don't usually know, or at least a couple of friends of mine were not aware of. The two keywords will be SOCKS and SSH.

Connecting over to a remote server, one can bypass unauthorized access blocked by usually our network firewall. The most common examples given are restricted access to Facebook, MSN or torrents. We can also have unlimited access to all kinds of contents thanks to the nice sysadmin managing the network who puts no barriers whatsoever, but we may not trust him or the network users to permit unencrypted data flowing openly. Having some way to establish an encrypted connection to a known network who we trust, or distrust less, and tunneling over it would be safer. This is where SOCKS and SSH can be much of helpful!
SOCKS is an Internet protocol that routes network packets between a client and server through a proxy server. -- via Wikipedia
I'm certain as most, if not all, of our daily applications implement themselves some way of proxying (mostly HTTP, HTTPS and SOCKS) or use the system-wide configured network proxy server. Now all we need is a remote and secure server to proxy and tunnel. This is the part where SSH enters:
Secure Shell (SSH) is a network protocol for secure data communication, remote shell services or command execution and other secure network services between two networked computers that it connects via a secure channel over an insecure network: a server and a client (running SSH server and SSH client programs, respectively). -- via Wikipedia
What this means is if we have a SSH-enabled server we can take advantage of it because typically no further configurations or tweaks are needed. Let's take a look at the SSH client manual:

-D [bind_address:]port
Specifies a local ``dynamic'' application-level port forwarding. This works by allocat-
ing a socket to listen to port on the local side, optionally bound to the specified
bind_address. Whenever a connection is made to this port, the connection is forwarded
over the secure channel, and the application protocol is then used to determine where to
connect to from the remote machine. Currently the SOCKS4 and SOCKS5 protocols are sup-
ported, and ssh will act as a SOCKS server. Only root can forward privileged ports.
Dynamic port forwardings can also be specified in the configuration file.
Got it? Great! Let's combine SSH+SOCKS:
ssh -C2qTnN -D <PORT> <USER>@<IP>
I will not provide the details of what each option features - run 'man ssh' and find by yourself. The result is a SOCKS proxy over SSH. Now let's wrap it in a bash script:

if [[ `uname` == 'Darwin' ]]; then
trap " {
echo \"Setting SOCKS proxy down...\" ; \
networksetup -setsocksfirewallproxystate ethernet off ;
networksetup -setsocksfirewallproxystate wi-fi off;
exit 1;

networksetup -setsocksfirewallproxystate ethernet on
networksetup -setsocksfirewallproxystate wi-fi on

ssh -C2qTnN -D 9999 <USER>@<IP>
Replace <USER>@<IP> by your username and IP address. This bash script, in case you are a Mac user, will automatically turn SOCKS on upon execution and turn it off when shutting down (Mac users using an OS X version prior to Lion should replace "wi-fi" by "airport"). Other Unix users (Linux, BSD, etc) should set SOCKS host as "localhost" and SOCKS port "9999" in either your system network configurations or in each application you want to tunnel over.

Apple MacBook Pro 13" battery history

One year has passed since I bought my Apple MacBook Pro 13" (mid 2010) laptop, and at that time I blogged about it. One feature I demanded was good battery capacity - the MBP 13" seemed like a great choice and I did go for it.

By middle of August I discovered coconutBattery, an application that shows the current battery capacity, its designed capacity, and current and maximum charge, as well as age of the laptop, battery load-cycles, temperature and power usage. One additional feature that popped-out right away was the ability to save the maximum battery capacity and as so since August 12, 2010 to today I've recording these statistics with a fully charged battery to later analyze how my laptop's battery health changed over time. That time has just ran out so let's take a quick look over it!

First, data extraction. A config.xsl file was created with the following content:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- Edited by XMLSpy® -->
<xsl:stylesheet version="1.0" xmlns:xsl="">

<xsl:template match="/">
<h2>My Apple MacBook Pro 13" (mid 2010) battery history</h2>
<table border="1">
<tr bgcolor="#9acd32">
<th>Current Capacity</th>
<xsl:for-each select="database/object[@type='SAVEDDATA']">
<td><xsl:value-of select="attribute[@name='date']" /></td>
<td><xsl:value-of select="attribute[@name='capacity']" /></td>
Then, I fired up my terminal and ran:
$ xsltproc --nonet config.xsl ~/Library/Application\ Support/coconutBattery/\
coconutBattery.xml | sed 's|\(.*\)% (\(.*\) mAh)|\2|' > battery.html

This generated a battery.html file with 146 records dumped to a HTML table:

(table dump sniped)

And here is a chart of it:

And finally a screenshot of my coconutBattery:

Battery load-cycles is at 58 after one year and one month and a half. Note that the age of my Mac that reads above is 15 months but the accurate age is 13 months (the former is time since manufactured).

Do you also log your battery health over time? Have these kind of data? Please share it with us!

SSH connection automation

Part of my daily routine involves accessing and managing a considered amount of remote servers through the SSH protocol. I use screen a lot to ease the job by having a couple of windows opened on each server, so avoiding multiple connections to the same server. By using screen not only helps me grouping server windows altogether in one console window/tab but also is a time saver in those days when network connection is not in its glory days allowing me to reattach it and carrying on being productive (*sighs*).

But, before connecting to all those machines, I used to repeat over and over the same setup steps:
  1. send my public key to server
  2. upload my screen configuration file
  3. create an alias (because ssh'ing manually is a truly hassle each time I want to connect!) to connect to the server and reattach or create a new screen session
  4. Change its permissions to 700 (security freak? Oh well...)

Four repetitive and forgettable operations that could all be avoided, sparing me some minutes of my precious time. But no more!

Here is a handy Bash script I wrote the other day (at last!):
# $1 = [remote_user@]remote_host
# $2 = [alias name]
if [ "$#" -lt 1 ] || [ "$#" -gt 2 ] || [ "$1" = "-h" ] || [ "$1" = "--help" ]; then
echo "Usage: $0 [user@]machine [alias]" >&2
exit 1
if [ "$#" -eq 2 ]; then
cat <<EOF
ssh $1 -t screen -x -R
) > $BIN/$2
chmod u=rwx,go= $BIN/$2
ssh-copy-id -i ~/.ssh/ $1 > /dev/null 2>&1
scp ~/.screenrc $1:~/ > /dev/null 2>&1
exit 0

Copy and paste this code to a file in your $PATH (mine is $HOME/bin/setup-machine) and give it execution permission (chmod u=rwx,go= ).
Obvious to some, though may not be to others, here is an usage example:
Macnux:~ carlos$ setup-machine -h
Usage: /Users/carlos/bin/setup-machine [user@]machine [alias]
Macnux:~ carlos$ setup-machine cgoncalves’s password: *****************
Macnux:~ carlos$ cat bin/cgoncalves
ssh -t screen -x -R
Macnux:~ carlos$ cgoncalves
[SSH connection established and attached to screen]