Author Archives: Matt

Ridiculously Easy SOCKS Proxy with ssh

Posted on by
Reply

Sometimes, ssh tunneling a port is insufficient. It’s fantastic if you want to remotely access some system, but suppose you want more of an ad-hoc VPN/proxy, to allow you to, say, browse the web through a remote system?

I thought about setting up squid on a remote system, but that would be a bit of work. Plus, I’d have to take care to lock it down so I wasn’t accidentally running an open proxy, which is all sorts of bad. I could also do OpenVPN, but that’s an even bigger headache to set up.

As it turns out, ssh includes native support for establishing a SOCKS proxy, too. Your local ssh client will stand up a SOCKS proxy on localhost, on a port you specify, and forward traffic through ssh to the remote system. You can then simply point your web browser at your local SOCKS server, and viola!

From the ssh manpage, it’s astonishingly easy:

     -D [bind_address:]port
             Specifies a local ``dynamic'' application-level port forwarding.  This works by
             allocating 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 supported, 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.

Add -N to stand up the tunnel but not give you a command prompt, and optionally -C to enable compression. (Typically only useful on slower connections.)

Putting it in action, it looks something like this:

mawagner ~ $ ssh -CND 8000 bos.n1zyy.com

It will continue to run in the foreground without any output. That’s all it takes—you’ve now got a SOCKS server running.

Now, configure your browser to use it. In Firefox, in the Preferences menu, Advanced › Network › Connection › Settings lets you set up a SOCKS proxy. Just fill in the SOCKS proxy line, with “localhost” for the hostname (not the remote server—ssh is listening on localhost and forwarding connections there for you) and whatever port you specified on the command line (8000 in my example).

Chrome seems to want this as command-line flags. On the Mac, it took this ridiculous command to launch:

$ /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --proxy-server="socks5://localhost:8000"

Take note that the SOCKS proxy will handle the actual connections, but DNS requests will still take place locally. If you’re trying to hide your traffic from an oppressive regime, this could be bad. It’ll also be bad if you’re trying to connect to something over a great distance and they’re using geo-DNS to steer you to the right place. But when your home ISP just sucks and you want to bypass their overloaded connection to Youtube, this is just the trick.

IPMI trick: Set the boot device

Posted on by
6

I’ve long known that you can use IPMI (on compatible systems) for some nice lights-out management, like power control or reading system information that you’d see in the BIOS. But one thing that has always annoyed me is having to get a remote console on the box and wait for just the right second to press the right key to bring up the screen where I can change boot order.

Lo and behold, this is an IPMI feature! It’s implemented at least on some IBM servers I’m working with:

mawagner ~ $ ipmitool -H 172.16.10.1 -U USERID chassis bootdev
Password:
bootdev <device> [clear-cmos=yes|no]
bootdev <device> [options=help,...]
none : Do not change boot device order
pxe : Force PXE boot
disk : Force boot from default Hard-drive
safe : Force boot from default Hard-drive, request Safe Mode
diag : Force boot from Diagnostic Partition
cdrom : Force boot from CD/DVD
bios : Force boot into BIOS Setup
floppy: Force boot from Floppy/primary removable media

mawagner ~ $ ipmitool -H 172.16.10.1 -U USERID chassis bootdev cdrom
Password:
Set Boot Device to cdrom

It appears that this will override settings on the next boot, but not make a persistent change. (You can, however, set the ‘persistent’ option.) Using bootdev none options=help lists out the available options, some of which are pretty interesting.

ssh tunneling for fun and profit

Posted on by
1

ssh is one of those things that’s useful for way more than meets the eye. Here’s a handy feature to add to your bag of tricks — you can tunnel traffic from your machine to a remote machine through another server running an ssh server.

Where this is often useful is in setups where you want to access a system on a private LAN, but it’s behind a firewall or bastion host (running ssh). You could connect if you were on the LAN on the other side, but you’re not.

It looks something like this:

The magical command here is something like this:

ssh -NfL 8080:192.168.1.2:80 root@virtlab-cloud-04

That would map localhost:8080 (on the machine where you’re running this command — i.e., your computer, or “You” in the diagram) to 192.168.1.2’s port 80 — but it connects to 192.168.1.2’s port 80 _through_ a host named “virtlab-cloud-04”, which you’ve ssh’ed into as root. (You do not need to be root for this to work.)

So, maybe you’re on your laptop at an airport hotspot, and 192.168.1.2 is the IP of a home system. You can map a port on it to your laptop by ssh’ing through your Linux box listening over ssh at home.

At a previous employer, I used this to manage our SAN via its (awful) web-based UI on our production network. The SAN was obviously not reachable over the Internet, but I could map its web UI to localhost:8080 on my desktop through a bastion host we had.

Introducing Tuskar

Posted on by
Reply

I’ve been working on a new project we’re starting in the OpenStack community, Tuskar, a set of tools to help with deploying and managing large OpenStack installations.

We started with an internal, unadvertised prototype, the conclusion of which is demonstrated here:

I’m excited to note that we’re now in Stackforge, so everything is now open.

Tuskar is the back-end project, with tuskar-ui (where I’m spending most of my time) being the Django interface on top of it. We also have python-tuskarclient as a client library for Tuskar.

Come join us!