I’ve never been great at keeping up with blogging, but I believe it’s important, especially as a software engineer as it exercises our ability to document and write things down. I typically blog when I have free time and my mind isn’t focusing on other things. As I’ve taken a vacation day today, I figured it would be a good time to dust off my blog and talk about what’s been keeping me from posting, but also things that continue to interest me with the hope that it can spark some excitement for new postings.

I’m primarily a Software Developer but I still have a great passion for System Administration. I work with Linux based systems now but if you look at some of my older postings you will find that I have done some work on FreeBSD and OpenSolaris. One of the things that really drove me to FreeBSD and OpenSolaris was their idea of Operating system-level virtualization, FreeBSD with Jails and OpenSolaris with Zones.

I did some postings last year about SSH and making keys and how to move them to systems you are working with. What if you need to do this in reverse? You are the person setting up a system for others to work with and you want to pass the private key to the users. An example of this is Amazon’s EC2 setup where you get the private key to be able to log in to the VMs you make.

From my other posting “Stopping SSH Brute Force attacks with PF on FreeBSD” I’ve been getting a good number of hits from people searching on how to stop SSH Brute Force attacks but on Linux and not FreeBSD, so I kind of feel the need to make a posting on this for the linux people. I also just setup a Fedora 13 server on Rackspace’s Cloud and I wanted to ensure I could stop SSH Brute Force attacks.

Time to time you may find the need to encrypt a file before sending it to someone or store it where other people may have access to it. OpenSSL is a great tool for this and it is installed on most Linux/Unix and OS X (also, I believe there is an install for OpenSSL for Windows too). Here’s the command to encrypt a file, $ openssl enc -aes-256-cbc -a -salt -in mytestfile.

“This was a triumph.” If you find your SSH connections dropping or locking up after not being used for some time you may want to try to edit your ssh_config (/etc/ssh/ssh_config) file and uncomment/add in the line ServerAliveInterval 30. The number is in seconds. What this will do is send a small ‘keep-alive’ packet to the server to ensure you don’t get dropped. Why is this happening? It could be settings on the server that drop users after set time of inactive use or due to a firewall/switch rule that drop inactive connections to improve the performance of the network.

SSH is one of my favorite tools on a Linux/Unix system. There is so much you can do from copying files, to tunneling data security. SSH is a great way to get access to your system at home, but also access to your network. Lets go over some things about SSH tunneling and why it’s good to use! Basic Idea: The idea of tunneling is to give you a secure way to pass data from one point to another.

Ok, lets start with something easy! :) What are SSH keys: SSH keys are a way to allow someone access to a user on another system without the need for a password. This is done with 2 key files one that is public and the other private. This is called “Public-key cryptography”. The public key will be sent to the server that you want to connect to and the private will stay on your local (or client) system.