Hook up to IRC when your network blocks it

April 18th, 2008

Just a quick write up for my own reference really, but hopefully some other people will find it useful.

My office is hooked up to the academic JANET network in the UK and it turns out that IRC is completely blocked. This is less than ideal for my new job at Engine Yard which uses IRC extensively for customer support and communication between staff.

Rather than fight with IT department goons I managed to quickly setup irssi to proxy my IRC access via my dedicated server and avoid network port blocks. Here are the steps I followed:

  1. Download and install irssi (use the—with-proxy flag on configure) – see this doc for more info
  2. Set up irssi to access your chosen server and various options – see this doc
  3. Run irssi using screen so you can start and then detach it (this means you can log out and keep it running between sessions) – see this doc
  4. Connect your local IRC client to the server running irssi on the port you specified
  5. Use IRC!

Thanks to people on the Geekup mailing list for their help and advice

Ban bruteforce SSH attacks

March 21st, 2007

I picked up on a post over at Michele’s Blog giving some good advice on stopping bruteforce SSH attacks against your dedicated server.

I get a daily log report emailed from my server and am normally too overwhelmed with the sheer number of bruteforce login attempts to even bother reading the rest of the log summary.

However, with Michele’s suggestion I have successfully implemented Fail2Ban on my CentOS box and am now happy to see repeat offenders being banned for 15 minutes at the IPtables level.

Another step I took before this was to switch my server to key based authentication only and refuse any password attempts, which was thwarting any attempt to actually login but still generating a lot of log noise.

Today my emailed log file was big enough to fit onto one screen, hurrah! Thanks for the tip Michele :)

1 comments »

SSH Keys on OS X

December 8th, 2006

It turns out that if you use an SSH/SFTP aware app on a Mac (such as transmit) and can’t figure out where you are supposed to choose the key to use…OS X handles it all for you.

Simply make sure the key is in your /.ssh directory (and possibly setup a /.ssh/config file pointing to your key if your key doesn’t seem to get picked up). Now when your ssh aware app tries to connect it will use the key automatically!

This is perhaps as you might expect, but if you have a password protected keyfile then you need to enter the password for the keyfile in the password box of the application rather than a user login password. This is very counter intuitive in my opinion (and the reason I had to spend so long looking for a solution).

Spread the word – I have confirmed this works in Navicat and Transmit so I assume it will work for all SSH/SFTP aware apps on OS X.