balls

14 Aug 2017

Comprehensive list of Perl best practices


17 Oct 2015

How to sanitize crazy strings for jQuery to use as selectors

In a project I'm working on I ended up having some pretty hilariously ridiculous element id and class names that included all manner of special characters. The problem came when trying to select these via jQuery. Turns out $('#http://www.example.com/index.php?myvar1=true&myvar2=false') makes jQuery barf. Who could've guessed, yes?

The solution was simple. I have a global jquery sanitize function that takes that into account, so that whenever I'm throwing something ugly at jquery, I can just run the select like so: $('#'+jqsanitize('hilariousstring')) and it pulls the jquery object just fine! Here's the code, I'll have to edit in a brief explanation later (including why this will not cover all cases)

function jqsanitize( selector )
{
    return selector.replace( /(:|\.|\/|\[|\]|,)/g, "\\$1" );
}

01 Sep 2015

pfSense, you're beautiful but you make me look stupid

My perimeter firewall/router has been a box running pfSense for a couple of years now. It's been the most glorious, functional, and robust thing I've ever done. The awesomeness of the upgrade to this from a Linksys e2000 with DD-WRT on it cannot be overstated. However, pfSense's downside seems to be the constant ability to make me feel like an idiot.

I'm no stranger to certificates, web servers, and the like. I do it for a living. However, the simple act of "installing" a trusted SSL certificate for my pfSense web configurator all but destroyed my confidence and my router. If you, like me, are needing to install an SSL certificate for web configurator services in pfSense and you have your cert, it's private key, and the intermediate given to you by the third party certificate authority, and you can't seem to get pfSense to deliver more than the server cert, leaving the intermediate out of the chain, then let me tell you a story of what not to do.

First thing's first, I tried installing the certificate. It worked, but no trust chain. Ok. So I figure hey, I'll tack the intermediate on behind the server cert (both PEM) when I paste it into the web configurator cert field. It restarted and no dice, still no chain. So I tried, perhaps, switching the order. Do not do this, unless you want your web configurator to be broken. Like, completely broken. TCP timeout broken. Luckily, pfSense is a badass and has the last 30 configuration changes available to roll back to, so it was as easy as popping into the shell, selecting a couple changes back, reverting, and voila - my old happy web configurator with broken self-signed cert was back.

At this point, I did what any hacker would do: I ditched the GUI. I discovered that pfSense uses lighttpd for the web configurator, and the config file is /var/etc/lighty-webConfigurator.conf. So, I made a change in that file adding the 'ssl.ca-file = "/path/to/myintermediate.pem"' and went to restart the web configurator, hoping that file was edited by the GUI by some fancy sed work instead of generating the whole file. Welp, I was wrong. My change was immediately overwritten.

Not to be dismayed, I decided to go fishing. I found the .inc php file that generates the lighttpd config and delved in. I found the location where it adds the SSL config. It was now as easy as editing the change in, saving it, and restarting things. But I didn't like the fix, it meant if I replaced the package or upgraded pfSense that change would probably get overwritten, and that's no way to make a smooth fix. I thought for a long while.

Finally, out of lack of options and perhaps desperation, I tried the illogical (to me) thing: importing the intermediate certificate into pfSense's CA section in certificate management. This didn't make sense to me for several reasons: This section was for making your own CA to pump out your own certs, why else would it require your private key when importing a CA file? Also, why would the web configurator even bother to check *all* your certs and match any intermediates in the CA section magically with the ones you've loaded? None of this seemed likely or probable to me so I skipped it, despite people on IRC hinting that I could load an intermediate w/o a private key. Anyway, as I tried it, leaving the key field blank, it imported nice and perfectly. "Interesting", I thought. I didn't figure it would be able to connect that cert to my server cert in the lighttpd conf file.

I was wrong. It did. The pfSense guys had already done all the legwork and, in retrospect and in the context of the most common use case (local CA signing local certs), it actually makes sense to have the web services automatically look for trust chains in the CA database. I still think it would be more logical to load intermediates in the same UI section as the server certs, but pfSense at least supports intermediates and has a simple setup to get them working. Perhaps some documentation on that in the cert section couldn't hurt. But still, a simple process once I got over myself. I never got that green lock I was looking for, since apparently the web configurator pulls stuff in over HTTP as well so the lock stays broken, but at least I don't have the giant warning screen telling me it's not safe to use. Oh well, lesson learned.


27 Feb 2015

I still don't really like systemd

More or less for all the same reasons I didn't like systemd before, I still don't like it now. I've been running it on my arch server for nigh on 2 years now, and same with my arch desktop. Earlier this week I was on my workstation (arch) that was upgraded from an old arch instead of a new install, meaning it still has the old rc conversion scripts to systemd. Well, something something and I had to mess around with some startup services, so I went digging around in systemd. Found the auto-generated service files that more or less just ran my rc scripts. This eventually got me digging into those since the service was still controlled by them (this install is 4 years old). MAN do I miss the old init system. It's what got me into arch linux in the first place (never been a huge sysvinit fan, I liked the BSD style going on in Arch). It's a pity systemd is taking over so hard. We really could use a more modern, ready-for-new-technologies init system. But I can't help but to feel like systemd was the worst way to go about it. So much for the "no, you just need to learn it" thing. The more I learn about it the more I wish it wasn't on any of my systems. And now it's getting its toxic grip on all my redhat servers at work because of RH7 release (a place where, while decent on the desktop, it MOST DEFINITELY DOES NOT BELONG). It's fanboys still are vitriolic as ever as well, it seems.

I really do hate systemd.


8 May 2013

I don't like systemd

I don't. I wasn't part of the whole systemd war because I never really looked into systemd or cared. But Arch Linux has moved to systemd, so naturally I did too. I ran the updates, and it was kindof a mess but most big updates to Arch Linux are, so this wasn't anything too unfamiliar. I powered through it, got my system booting in Arch Linux's hybrid init-scripts-still-supported-but-using-systemd mode and didn't think anything of it. Cool, systemd must be neat, after all everyone says it is.

I then upgraded the hardware on my home server and plopped a new Arch Linux on there. It wasn't the hybrid initscripts, but a pure systemd system. Ok, so a bit of a learning curve, but I figured out how systemd works, how it runs things and in general, and I got my system up and running smoothly (so I thought).

However, throughout my travels I have discovered that systemd turns out to be a giant turd that sets out to accomplish a goal (a fairly worthwhile one, in my opinion), but accomplishes it only marginally better than the existing solution all the while causing havoc and mixing things up where it shouln't even be in the first place.

The good:

There are a couple things I really like about systemd. Namely, the idea that it holds the sockets, so if a service dumps itself, the data flow isn't interrupted, and on restart of the service, little data is lost. This is neat.

Boot speed. I will put this here as an official plus, even though I see it as a double edged sword. Use an SSD if you really want fast boots.

The bad:

The problem with systemd doesn't lie in it's management of services and the boot process. I think it does pretty well. Mind you, not BETTER ENOUGH to warrant switching up, but it's nice to have options yes? The problem lies with its hostile takeover of the rest of your linux box. Sorry, but I wanted to run GNU/Linux, not GNU/systemd/Linux. It hijacks your logging, and you now have to use journalctl, which is actually quite a pain in the ass. Sure sure, you CAN remove it and use standard logging. But I *COULD* rewrite the entire kernel if I wanted to, so WTF? WHY DICK WITH IT?!? Also, it appears they have taken udev hostage. If you want udev without systemd, sorry. That's going to be a problem.

So, to re-iterate over why systemd is junk and doesn't need to be used:

RIP in peace, Arch Linux.


24 Dec. 2012

End of the world, Christmas, and YUM update

Welp, the apocalypse came and went and I never got to slaughter any zombies or aliens, no natural disasters to speak of. It's Christmas Eve, the one we never thought we'd get to alive. Merry Christmas. As a special little merry Christmas treat, YUM decided to completely hijack one of my boxes. Here's a little backstory, how to avoid it, and what happened.

Once upon a time, I had a virtual machine in VMWare running CentOS 6.2. Because of infrastructure changes, this machine was migrated to a new VMWare cluster and VLAN. I powered the machine on to update it to 6.3 and get it back online. However, since it's VLAN had changed, it could no longer operate with it's given IP address. Overlooking this, I fired of the command "yum update".

I was not prepared for what lay in store for me.

After some time (30s) looking for a mirror, it decided to do what any good program would do. It gave me an error saying "hey, I can't reach these mirrors". Realizing it was the network problem mentioned earlier, I thought "ok, no worries I'll fix it and move on with life".

Not if YUM had anything to do with it.

I hit ctrl+c to get my prompt back. Nothing but a ^C floating out in the openness of space. I hit ctrl+c again. Ok, maybe ctrl+d. Nothing. I desperately began spamming ctrl+c. Still nothing. Changing ttys wasn't an option, as there was no way to issue that keystroke command to the virtual console. Finally after days of spamming ctrl+c, I got a message saying "Press ctrl+c again within 2 seconds to cancel operation". I did. I pressed it about 30 times in the next two seconds, but YUM didn't care. It went back to it's mockery by spamming the PYCURL error once more. It appeared I no longer had a choice. I pulled the virtual plug on it.

Moral of the story? NEVER USE YUM UPDATE WITHOUT A NETWORK CONNECTION. It will hijack your box and never let go. If you are on a physical box, perhaps the tty switch and kill -9 can help you out, but on a VM, steer clear, especially if it is a box you can't afford downtime on. I was lucky and this wasn't a problem for my specific box.


11 Oct. 2012

How to check your Tomcat version

java -cp /your/path/to/catalina.jar org.apache.catalina.util.ServerInfo

You're welcome.


30 Aug. 2012

Encryption for noobs

This is the rough draft of a writeup I did for a few of the people at my workplace who weren't particularly clear on the various methods of encryption, keys, and how they worked.



Certificates, keys, common internet crypto for noobs:

Let's start with some definitions:

Certificate: A certificate is simply a collection of information. The information included in an X.509 certificate (the most common, used for SSL over the web) is as follows:

Key: A key is just that, although in teh digital world it comes in the form of a string of bits (or letters/characters) instead of a finely cut metal strip.

Algorithm: A sequence of mathematical operations. The algorithm for finding an average is "add up all the values, divide that sum by the number of values summed".

Private key: A key you keep private.

Public key: A key you let loose into the public.

SSL: Secure socket layer. SSL is an encryption standard for the internet. It is simply a set of rules on how to use encryption for safe communication, it is not an algorithm.

TLS: Transport Layer Security. TLS is an encryption standard derived from (and sometimes backward compatible with) SSL. It has sometimes been referred to as SSL v3.1.

Encryption: A method of transforming information such that the information cannot be interpreted except by those who know the specific method to reveal it. This is why you're here.

----------------------------

Ok so I know what those words mean. Now what?

It's time to learn about basic public key cryptography.

First thing's first. Public key cryptography is assymetric, meaning information can be sent ONLY ONE DIRECTION, as opposed to symmetric crypto where both sides can encrypt/decrypt. Passwords on a .rar file are a good example of symmetric encryption. You can encrypt it with a password, send the file, and someone else can decrypt it with that same password.

How does it work?

Public key cryptography is a fairly simple process (although the math behind it is fairly intense). The general idea is as follows:

In public key cryptography, each party has two keys, a public and a private key. Since public key cryptography is assymetric, the public key locks, and the private key unlocks (encrypts/decrypts, respectively), but it doesn't work the other way around. These keys are mathematically generated in key pairs that work only with eachother, but nothing else.

So say I want to send some information to someone securely? Well, you would need the public key to "lock" the information. When they receive it they can use the private key to unlock it. This is why they are called public/private. You give out the public key freely, as it can ONLY be used to encrypt data that you alone can decrypt with your private key. Well, someone else could decrypt it with your private key too. That's why you should keep it private.

OTHER PERSON --> your pubkey --------------------> you --> your privkey --> original data

It only works this one direction. If you need to send to "OTHER PERSON", you need their public key which belongs to a different public/private pair than the on eyou gave.

But I never gave a website my public key, how is it sending me encrypted data? What sorcery is this?!?

Back in the day, your browser would have a public/private key pair and would actually give the server your public key to send data back. Since then, modern SSL/TLS uses a slightly different method. Your browser generates a password, encrypts it with the public key contained in the SSL certificate on the webserver, and sends it off. You and the web server then use that password to exchange information over a symmetrical (non public/private key based) encrypted connection.

----------------------------

SSH and key-based login

When I login to SSH am I the sender or receiver?

If you break it down logically, it goes something like this:

You have a server. You want access for some but in general access is restricted. If you have a private key and give out a public key for people to log in, this is a very bad idea. Your public key could be put up on torrent sites, spread around IRC, etc... Pretty soon everyone would be able to log into your server. However, if you take people's public keys, you can be sure that only the person that has the private key is allowed in. Now, obviously, this has the hole of an untrustworthy person spreading his private key around but no security known to man has been able to thwart good old fashioned dishonesty.

The SSH connection goes as follows:

User attempts to connect. SSH on the server replies with an encrypted "challenge" using the public keys it has. If you contain a matching private key, your SSH client is able to properly "answer" the challenge, and sshd server allows you in. Otherwise it prompts for the user password.

----------------------------

Etc...

file and file system level encryption

Typically when files (or entire hard drives) are encrypted, they use symmetrical encryption. The passphrase/key/password/whatever-you-want-to-call-it is created, and the file (or entire drive) is encrypted based off of this key. It is used to decrypt the encrypted file as well, on the fly in teh case of drives or network connections.



28 Aug. 2012

Good job SuSE, good job.




25 Jun. 2012

Monty Hall program in C

I love statistics and mathematics, and recently I was reading about the Monty Hall problem. The counter-intuitiveness of it intrigued me, and although I spent enough time learning about it that it "clicked", I still wanted to prove it with brute force on a computer. It also seemed like a decent little not-so-over-the-top-I-wont-actually-finish sized exercise for programming. So I set at it. For those who aren't familiar with the Monty Hall problem, let me explain. No, there is too much, let me sum up.

The Monty Hall Problem

The Monty Hall problem is named after a game show host whose show had 3 doors. Behind 2 doors were goats, and behind the third, a car. You obviously want to win the car (unless you are Malaysian or something, idk). The game goes like this: The contenstant chooses a door. Once they have decided, Monty Hall (who knows the locations of the prizes) chooses a door, and opens it to reveal a goat. The person is then given the opportunity to switch to the other un-closed door should they want. The probabilities involved comprise the "Monty Hall" problem.

So why is this even a thing? The reason it becomes more than a pointless game show mechanic is because of our (as humans) natural intuition, and how it does not line up with math in this particular case. If you were to think about it, you would most likely say (without having been introduced to this previously) that the odds of winning after Monty opens the door are 50/50, so switching is irrelevant statistically. It makes sense, Monty eliminates a door, so there is a car and a goat and you choose one, switching just means you choose the other half of the available doors. However, this is wrong.

You are twice as likely to win if you switch as you are if you don't. That is, 66.6% chance to win switching, 33.3% chance to win not switching.

Yeah, it bottled my mind too :P So, why? How is that possible? The short, to the point numeric explanation is this. You choose a door starting. You had a 33% (1 in 3) chance to choose the car. It doesn't matter what Monty does or what else happens, if you stick with that choice, you have that 1 in 3 chance. Now for switching, you would think it's 50/50 but that is incorrect. You had 1 in 3 to choose right, but if you switch you have a 2 in 3 because the other door is out of the question now. It really doesn't seem like it, but Monty Hall, by eliminating that other door, is "giving" you that other 1 in 3 when you switch.

An easy way to grasp it is imagine 1,000,000 doors. Your chance of guessing the right one is 1/1,000,000. If Monty revealed all but 1 other door, would you switch? Yes, because um, there is a 999,999/1,000,000 chance that door has the car. Same with 3 doors, its just less apparent as the odds are not quite so clear cut.

Enough nonsense, to the code!

Ok, so you can ponder that all you want, but here is logical and mathematical proof for you if you want. I coded this in C and it was a rush job, so the code is inefficient and bloated. When debugging, instead of rewriting the code for efficiency I just tacked on stuff that made it work hah. Anyway this ought to compile on anything with the cstdlib and a C99 compatible compiler.

THE SOURCE CODE

Sample output:

This study is designed to sample (at high iterations) the Monty Hall problem, and produce results. Successful results should show that switching doors produces a win ~66% of the time. Not switching - 33%
Switch set to 0.
Wincount = 33516.
Switch set to 1.
Wincount = 66795.


13 Jun. 2012

Cool bash script for RDP goodness

If you find yourself needing to admin a Windows server now and again no matter how hard you try not to (like I do), you will likely need a remote desktop client. If you are running windows, you can just put mstsc in the run box. In linux however, my poor little terminal just can't do it on its own. rDesktop is a neat little basic program that is light weight and covers all your RDP needs. Launching it is typical for a linux program, you command line launch with parameters for what to connect to. That's fine, but I wanted a menu entry in my fluxbox setup for it. That posed a little problem. How do you pass a command line parameter to a fluxbox menu item? You don't. But as it turns out Xdialog will work perfectly as a workaround! I whipped up this quick little script using Xdialog to create a text field entry complete with titles that make it look like a real program ;) So go ahead, give it a try. It even forwards any errors to new Xdialog windows so you get neat little error window popups instead of terminal spam. You may want to change the resolution in the script, depending.

#!/bin/bash
TXTMSG="\
rDesktop RDP Client.\n\n\
Please enter the servername/IP to connect to below:"

ADDRESS=$(Xdialog --title "rDesktop RDP Client" --clear \
        --inputbox "$TXTMSG" 10	60 2>&1)

RETVAL=$?

case $RETVAL in

    0)
      ERROR=$(rdesktop -g 1280x1024 "$ADDRESS" 2>&1)
      if [[ $ERROR ]];then
        Xdialog --title "Warning" --textbox - 10 60 <<< "$ERROR"
      fi
      ;;
    #Other customizations based off return values here

esac

11 Jun. 2012

How to fill up a harddrive really fast

I happened upon an interesting little problem. I (for reasons I won't go into here) needed to generate a really huge file really fast. I experimented with something, and it turns out that when the system doesn't have to run all output to a console (like, say, if stdout were a file), programs such as /usr/bin/yes run REALLY fast. in the neighborhood of ~150mb/sec fast. That's north of what most of my harddrives at home can write (enterprise SAN in vmware doesn't seem to have a problem with it, however). SO, need a big file or to fill up a HDD fast?

yes >> filename

Make sure to ctrl+c before it gets too out of hand.


27 Apr. 2012

SLES 11 tomcat problem, RHEL subnet fail

SLES 11 is not your friend

SuSE Linux Enterprise Server 11 is Novell's (latest) enterprise Linux distribution. They tout it as a great product, but in my job as an admin, I've noticed it is worth about as much as Novell's stock. If you are looking into linux and want to give it a try, or looking for the next good solution for your server operations, I highly suggest you steer clear of SuSE. Brought to you by a company that has yet to create something they've not driven into the ground, SLES is quite possibly the worst distribution I've ever had the misfortune of using.

My face every time I need to use YaST

I encountered a somewhat strange error on two of our SLES 11 boxes (dev/prod pair). The Apache Tomcat 6 install was taking 100% of one CPU on each box. Luckily they were both dual CPU machines, so our websites still responded, but even with 0 traffic these things were cranking away. I searched and searched and eventually happened upon a fix released by Novell regarding Tomcat using large amounts of CPU. It had something to do wtih a new linux scheduler and some silly incompatability in Java with it or something of that sort. So I ran through the fixes, setting the scheduler into some backwards-compatible mode and whatever else Novell said I should do. No dice. Still had Tomcat raping exactly 1 full CPU on each box.

After a few hours of beating my head against a wall, I did what any good sysadmin would (and something I should've done first). I updated shit. All of it. Turns out, after updating the IBM Java JRE that was installed from sr7 to sr8, the incompatability that Java had was no longer an issue and my tomcat process dropped back down to .5% cpu like it should. Welp, lesson learned.


RHEL isn't perfect

I really wasn't OVERLY familiar with RedHat until my most recent job when we started moving to CentOS. Before that, I was more familiar with Debian and BSD (ArchLinux anyone? I fanboy it). As I've become more familiar with it, I've actually grown to love it quite a bit. It is a solid, logically set up, well documented, smoothe system to work on (none of which apply to SuSE). It isn't, however, without its quirks. Here's how to fix one of them.

At work we run a large VMWare environment like most large entities probably do, or at least should. Because I clone VMs and deploy new servers frequently enough, I figured I would spare myself the trouble of sifting through tons of system files buried who-knows-where just to set up a new network config (the clone uses the original's, and that's no good...). So I wrote myself a neat little script, complete with interactive questionnaire for your network settings. Real slick. After being completely impressed with myself, I cloned a new server and fired up my script. I filled in all the network information, and voila, a shiny new network config and I didn't have to do anything! Awesome!

But then I noticed it.

None of my subnets for my secondary IP addresses (on aliased interfaces) were correct! Nooooooooooooooooooooooooo!!!!! Figuring that my script probably just fubar'd something, I poked around in my network config files. Everything looked solid in my ifcfg-eth0* files. IP Address was correct, prefix was correct, gateway, etc.. EVERYTHING was flawless. But for some reason, no matter what was listed in the ifcfg-eth0* files for the prefix (I had PREFIX=25), it would pop up on the /16 subnet. WTF? I was able to shut the network down and manually bring the interfaces/IPs online properly using ip link and ip addr, but that is hardly kosher... And forget writing a script to do that automatically on boot. Isn't that what /etc/init.d/network is? So I set out doing some detective work.

Four hours later I was at my wit's end. I had tried everything I could think of. I had 2 other boxes this was working fine on. I had rebuilt the config files from scratch 10 times, copied them from working boxes and replaced IPs/subnets 10 times. Still nothing. Tired and annoyed, finally I decided to try one last thing before I ragequit. I replaced the PREFIX=25 entry in my config file with NETMASK=255.255.255.128. Now, the manuals say that NETMASK has been deprecated in favor of CIDR notation and to use PREFIX instead. But when I restarted the network with the NETMASK command in there, THEY CAME UP WITH NO PROBLEMS WHATSOEVER AND IN THE RIGHT SUBNET! WHY!?

So, after wading around through the darkest recesses of linuxdom (or maybe its in bold on the front of some manpage or doc, idk), I discovered why it was throwing my IPs on the /16 subnet. When NETMASK was deprecated in favor of PREFIX, a routine called ifcalc() is run that calculates subnets and stuff. I guess this program is from before 1993 when CIDR didn't exist because it can only compute classful-range subnets, that is only values of 0 or 255 per octet. Your subnet not a /8,/16,/24, or /32? No worries! With ifcalc(), it soon will be! As I was running on a /25 (255.255.255.128), ifcalc was thrown for a loop and decided to round down to /16 for whatever reason I still to this day do not understand.

Dear Red-hat, please do not deprecate things that are vital components of a system and you do not have a working replacement for. Thank you.

Update:

Looks like something very similar was reported as an official bug here.


3 Apr. 2012

Evading your work's site block:

Remember: This can get you fired. Also remember: Your network monitoring team can still see the huge amounts of encrypted traffic you are using to watch youtube at work and may eventually wonder what your appeal is with yourhomeserver.com and why you are using an encrypted connection to shuffle ~200kbps constantly. My job isn't to follow your workplace rules, that is your job. My job is to show you how to break them :D

Things you will need:

Once you have these in place, you need to decide which instructions you want. For stupid people or for smart* people.

*The qualification for "smart" in this context is the ability to properly pronounce the word banana.


For stupid people:

For smart people:

Congratulations! You are smart. Or at least you think you are. This is just a brief explanation of how it actually works and what is going on behind the scenes, not just step by step instructions on how to set up your computer to get to the WoW forums to flame your guildie about aggroing a boss early.

What this setup does (a not so well known ability of ssh) is sets up a "tunnel" to your ssh server that will essentially forward all network traffic you send into the tunnel to the server, and the host will act as if the traffic were local on the server. SOooooooooooooo, logically it follows that if you set up your web browser to fire off requests to this tunnel and listen for responses from that tunnel (instead of its usual operation which uses your network's gateway as the "tunnel"), you will be browsing quite literally from your home (or friend's) server.

Your computer's setup: PuTTY can be configured to listen on a port on your local system, which will then tunnel to the designated port on a remote system as a dynamic SOCKS proxy. Any port on your local system (assuming no local firewalls prohibit) works just fine. The remote host/port need to be ones that are not blocked by your internet firewall, (the likelyhood of your home server being blocked is small, but usually few ports are open). To better mask, run it over port 443, which is where https runs. This will, however, prevent your home server from running a ssl web server as well, since SSHD will be listening on the port instead of your web server. Once this SOCKS proxy is setup in PuTTY, anything aimed at the port you selected will tunnel to the sshd server remotely. So, open up your browser, select "use proxy" or similar, make sure it is using a SOCKS proxy (not http or what have you), and use the address of localhost:port where port is the port you had PuTTY listen on. I tried this on Opera, and on my particular system it would only run using the loopback address 127.0.0.1:myport instead of the hostname localhost. YMMV.

Your server's setup: If you are running Windows on your home box, install cygwin and then OpenSSH. If you are running linux, you probably already have it. Make sure in the config file for openssh server (I think defaults to /etc/ssh/sshd_config) that the line "AllowTcpForwarding" says yes. Restart sshd. That's all. And this is why you should love Linux and FOSS. Oh be sure to note or change what port sshd is running on and to forward it if you're behind a NAT router. SSHD, when receiving tunneled TCP requests, takes commands and sends them out from the server as if they were its own. It forwards the responses it gets back through the tunnel.

Now that you've made it through, you can refer to the stupid section for step by step if you can't figure out PuTTY's quirks on setting this up :)

UPDATE 27 Jul 2012: After checking into this, it looks like DD-WRT (the firmware for many home wireless routers) has the TCP Forwarding capability with any version v24 RC7 or higher (so pretty much anything even remotely recent). That's good news for people who don't have a server always chugging away. You can use your router to do this with! Just go to services -> check ssh, check ssh tcp forwarding, note the port, forward a DNS name to your home (dyndns or what have you) and voila!
NOTICE: I haven't personally tried this because I use an enterprise level firewall, switch, and ap to run my network. YMMV with the success of using this over DD-WRT. If your router has a slower processor it may not be able to keep up with encryption of heavy traffic. If you overheat your router doing this, sorry. I'll try and test it later. Maybe. Probably not.

UPDATE 16 Aug 2012: I had a friend try it on his mid-upper range consumer buffalo router. It seemed to have no speed issues that couldn't be attributed to his cable connection. No word on overheating of router.


Setting up a Kerberos5 server in Arch Linux:

1. Ensure krb5 package is installed (should be)

2. Edit /etc/krb5.conf to reflect your desired realms/hostnames. NOTE: I did have issues using localhost or the hostname on my system. It wouldn't run properly. Didn't have time to troubleshoot, tried loopback addr (127.0.0.1), worked.

3. Ran /usr/sbin/kdb5_util create -s to create KDC db.

4. Created (wasn't there by default) the kadm5.acl. NOTE: It seems most distros, particularly Cent/Fedora/RedHat have all this in /usr/kerberos and /var/kerberos/krb5kdc. Arch keeps this all in /var/lib/krb5kdc (binaries in /usr/sbin). I needed to symlink the /usr/local/var/krb5kdc directory to the /var/lib/krb5kdc where Arch keeps it.

5. Once this was symlinked, I was able to launch the kadmind process, then run kadmin.local to login with the password created and then add principals at the prompt via "addprinc username". If you want accounts to have admin privileges, be sure to do "addprinc username/admin", and add the line
*/admin@YOURREALM.COM *
to the kadm5.acl file.

6. Test by running kinit to get a ticket, klist to show it, kdestroy to destroy it.