Mastering SSH Keys

Welcome to the wonderful world of SSH keys! If you don’t yet share my enthusiasm you soon will! SSH keys are a perfect way for you to control access to your machine, whether that be a very secure way for only you to have access, locking down other authorized users and preventing their passwords from getting distributed or stolen, or even allowing access to scripts for very specific purposes. SSH keys accomplish all of it and more. First, let me just lay out how simple SSH keys are in case you aren’t clear and maybe get discouraged by the length of this post. The basics of it are, you have a host server create a private and public key pair. You can optionally provide a password for the keys. You copy the public key to servers you wish to log on to, while keeping private key secured and on your system. Then when you login to the system the private key is used to decrypt the public (also with optional password) and you get in. It is that simple at its core, there are just a lot of various configuration options you can use to accomplish certain features or functionality that may be more desirable for you. The keys are very secure as using this method alone prevents against man-in-middle attacks and eliminates a few other possible break-ins from password only authentication.
The most common way I see SSH keys being used is as a password-less easy login for an admin to use for his remote linux systems. Although this is better than using a password only system you still are vulnerable to someone obtaining your private key and using it for instant access to any system with the corresponding public key. I prefer to use them as a type of two factor authentication for the ssh logins where I need to provide the password to the key plus (of course) have the actual key. Regardless, let’s get a basic configuration going and start using ssh-keys. First on the server side you can follow a config I’ve used in a previous post but general settings to ensure:

  • Port 2992 – (I always recommend changing the default port)
  • Make sure both “RSAAuthentication” and “PubkeyAuthentication” are both set to yes
  • PermitRootLogin no
  • AuthorizedKeysFile %h/.ssh/authorized_keys
  • I’d also only allow users in a certain group to use ssh for further protection so “AllowGroups sshlogin” for example and add users who will ssh into this system into the sshlogin group.

Now on your machine, the computer you will be ssh’ing from, you need to create the key pair and copy the public key to the host(s). Generate the key pair as follows:
Create the .ssh directory in your linux home directory if it doesn’t exist already. Ensure correct permissions with chmod 0700 .ssh. Then create the actual keys and when prompted specify a pass-phrase to use (This pass-phrase is the optional part if you just want to authenticate with the keys alone but as I mentioned above I prefer supplying one so you have a two factor authentication going on). Keep in mind this can be a passphrase not just a password.
ssh-keygen -b 2048 -t rsa -f ~/.ssh/MainKey
The -b specifies the length of the key and the -t the type (which is rsa or dsa).
I’d use RSA 2048 or if you are the more paranoid type RSA 4096. I won’t delve into the RSA/DSA debate except to say that I’ve done a LOT of reading on the topic and I’m choosing RSA keys and with sensitive servers I’d go with RSA at 4096.
Once the keys are created scp the public key to the server but copy the public key into the .ssh directory named as “authorized_keys” (or wherever you specified in sshd_config the AuthorizedKeysFile). You can append multiple public keys to the authorized keys file just cat mykey.pub >> authorized_keys for each public key.

Now you may have noticed above when generating the key pair we passed the -f option. This way we can name our private key something other than the default. If you do not specify the -f the default will be id_rsa with the corresponding id_rsa.pub. So now to ssh into our system we will want to specify the identity file to use as:
ssh -i /home/user/.ssh/MainKey user@myserver.com -p2992
The reason I want to show the more complicated use case of specifying a particular identity file is that you may want to have different key pairs for servers that are yours versus your employers’ or any other separation that would be important to you. You can simplify the management of which keys are used for which hosts by specifying in the ~/.ssh/config file.
vi ~/.ssh/config

Add both host names and their identity file as follows:
Host server1.myserver.com
IdentityFile ~/home/user/.ssh/MainKey
Host server1.workserver.com
IdentityFile ~/home/employee/.ssh/id_rsa

That’s all there is to your basic key based login! Now lets briefly go over many of the popular use cases for these ssh-keys so you can see how powerful and helpful they can be for you.

First, as I mentioned earlier, I frequently see administrators using these without a password so they can quickly login to the servers they manage. The problem is you are now solely relying on the security of that private key for complete access to those systems. I will strongly recommend (yet again) putting a pass-phrase on your keys and then if you want a quick password-less login then simply configure ssh-agent to cache your pass-phrase on your system for that session. For details just search for “ssh-agent cache password” and you’ll find a few examples. In this way if your key is somehow stolen that person still has no access to the servers as they don’t know the password, yet you have the efficiency of not typing a pass-phrase once you set up and configure ssh-agent to cache it on your system. Win-win here.

Next, we can limit by IP or IP subnet where users with ssh-keys are able to login FROM. So say you are the server admin and you have other users you manage on the server. Maybe you (especially after reading this) have a requirement that they only login with ssh-keys. Being security conscious you might have a few concerns, not the least are:

  • Did they create a passphrase or leave blank?
  • Will they give their key and pass to someone else to use?
  • What if their key is stolen or compromised?

One thing you can do if you just control the server with the public key, is limit by IP or subnet where they can be coming from. In this way if the users key is stolen it can’t be used anyway if that person isn’t trying to login from the same IP (or subnet) as where the original user is from. You can either wait till they login the first time and see what IP they are coming from or ask them to send you the subnet or possible IP’s they might come from. Once you have this IP or list of IP’s just open the authorized_keys file on your server and add a “from=” line to the beginning of their public key as shown below:

[root@mainserver .ssh]# cat authorized_keys
from="10.20.30.*,172.16.31.*,192.168.1.*" ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEArAkcHTOXZiDxcJEHNmrJRoM2HJE9Rq1uoiVHuTSjgl0THp0UFDNepnmCvk5bX22KzjAUa8PWnq1ZDw5Uf9/i6N/SiXittnxT0dFnZGj6RRep5Ae3AmOJbg0i69XL9o2zBJnYo2JVPXJkCDhSvVWokZUn5QjaJiGNigP9plA1He94Slkhn2jTxx1iehx9Vy/ojnxsJDqpTa8hX1GQK/b1jzvWdN3Qg+EhlxBDfKSA8u4uGsPP+6hXGgFLRluG/6yizj8LDF1LRWIKYaBvaLNJ+720sAI9O4miHyxY4n3ghBDbULPoLGz5a6bYRJ9pY9i0ySQEmXNSD+0u31+fAaGGpQ== user@sauronseye

So if you have this public key and it is supposed to be used by a user at Company A and that user gives it to someone else at Company B or it is compromised by evil haxor, then that key whether it had a password or not will not allow them access. Then with your normal audits you do (right?) you see failed logins from a foreign IP and realize the key was compromised. Server is still secure your world is safe from harm :) .

The last and yet another very common way of using ssh-keys is for specialized scripts use. You have a script on one server and at a certain point in the script you’d like it to kick off a command or script on another server. How do you do this? Well you can create an ssh-key specific for this purpose. Create your keys just as above but name its identity for the job at hand so you don’t get confused.
ssh-keygen -t rsa -f ~/.ssh/login_audit
For an example lets say you have primary internal server and you want it to go out and gather a report of all the last logins from your remote servers. You could put a script like this on the remote server:

# Script: last_logins.sh
last -a > /home/user/last_logins.barney
scp /home/user/last_logins.barney fred@mainserver:.
# End Script

Then in the authorized_keys file on the remote server edit the public key just as we added the “from=” line but instead use “command=”:

command="/home/user/scripts/last_logins.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding [rest of pub key...]

Now whenever you ssh in using that identity file the only thing it will do is run that command and exit. There are countless uses for this alone and being aware that you can use ssh-keys like this will help you realize WHEN you should use them like this.
There is a bunch more you can do with ssh and ssh-keys so use this as a starting point and take advantage of the tools at your disposal!

~~~~~BONUS TWO-FACTOR AUTHENTICATION SECTION~~~~~
We discussed above using ssh-keys as two-factor authentication to login to a server via ssh. Some of you may be aware that Google offers a two factor authentication to login to your Google services (gmail, apps, etc.). They accomplish this with an application you can install called Google Authenticator.
If you don’t use google authenticator and 2-factor authenication on your google account you should strongly consider it. Gmail accounts are prime targets for being compromised and a lot of people use that account for a wide array of things that would make the compromise that much more damaging. Read some of the links below for starters:
http://www.multitasked.net/2011/jun/27/hacked-gmail-google-account/
http://threatpost.com/en_us/blogs/new-password-not-enough-secure-hacked-e-mail-account-100410

Once you have google authenticator installed cause now you fear for the safety of your gmail… what else can you do with this thing? Well we can use it for two-factor authentication to login to our machines, much in the same way we used the ssh-keys.
I’ve found a great post that details how to do this and don’t forget to read the comments there as they include a lot of valuable information as well:
http://www.mnxsolutions.com/security/two-factor-ssh-with-google-authenticator.html

Linked also in that post is how to use a YubiKey to login with two factor authentication. These are all great and really secure methods to login and authenticate to your systems.

Hopefully you can realize the importance of two factor authentication to secure the things that really matter to you. There are countless hacks and exploits and more found every day. Trust me it is much easier to take the extra 10 minutes to set this up than the hours or days of recovery from a security breach. One needs to be proactive about security because if you are reactive then you are too late.

 
Here Come 4k Advanced Format HDDs

Looks like the 4k sector drives are really starting to hit mainstream. This year marks the first time I’ve received a new laptop that came with a 4k Advanced Format hard drive. The laptop was from Dell and we get in new Dell laptops all the time. The funny thing is that until I tried installing Windows XP on it (came with Windows 7), I would have never even known it was a 4k sector drive. It’s one thing for an industry to move to a new technology or practice but without digging around there is virtually no media or even clear labeling about this change for HDDs. For the most part it should be a non-event for your typical user. If you buy a new computer with such a drive you shouldn’t notice any difference. Though there are a few caveats I think people should keep in mind, hence the “Caution” in the title:

  •  If you use hard drive cloning software it’ll have to support the 4k sectors
  • If you buy a new USB disk that uses 4k sectors, be sure the OS you connect it to supports reading this.
  • If you buy a new computer and think to install an older OS on it, or buy a new HDD for an old computer, thinking to keep the old OS, either don’t get a 4k sector drive or ensure you can get it working -  continue reading…

For the most part you should be able to get everything working with 4k sector drives.  A lot of the drives out now are 4k internally but emulate 512 bytes to the OS to keep with the old standard.  These drives should be labeled or described as 512e drives.  You might see a performance hit when using those so either make sure you get a native 512 sector drive or you explore your options for getting the 4k sector drive working.   Western Digital for example, makes an align utility you can use on their 4k drives that will correctly align the partitions if you use the disk on an OS that doesn’t support the new sector size (like XP).  There seems to also be a jumper option on the WD drives that will get the partition aligned for the non supported OS’s.  From my quick research it seems any Linux kernel from 2.6.31+, Windows Vista, Windows 7, and Mac OSX 10.4+ should all be good reading and writing to the 4k sector drives.  It’ll be your Windows 2000, XP, etc OS’s that you’d have to pay close attention to.

I believe the 512byte sector also hit its size limit at 2TB disks.  So any drive larger than 2TB would have to be a 4k sector drive.  Which means 4k sector drives should hit their storage capacity at 16TB so I guess we’ll be revisiting this topic once manufacturers want to go over 16TB disks.   If you want to learn about why the industry needed to move to 4k sector drives and more details on the low level changes it makes to the disks then one of the best articles I’ve found on it is here: 4K Advanced Format Hard Disks.  Although this change is slipping into the mix very quietly there are clearly situations where you’ll want to know if the drive you are getting uses 4k sectors, take a moment to look into it so you don’t get hit with any unexpected surprises.

 

 
Xirrus, Dense Wireless Solved

It wasn’t too many years ago that you could calculate the number of wireless clients you’d have to support simply by counting heads. Oh I have 100 people to support here? Okay, roughly 100 wireless clients then, max. Well that nice, simple equation is about as true as 1 + 1 = 1 nowadays. Think of all the things you might possess that have a Wi-Fi chip in them. In my workplace alone we have:

  • just about every cellphone (and I know a lot of people who regularly carry 2 phones with them for work vs personal)
  • laptops
  • tablets (iPad, Xoom, etc.)
  • Desk phones (Cisco 9971)
  • more than I’d like to admit, weird, random things discovered while scanning

My most accurate calculation is figuring a 4:1 ratio of wireless devices per employee. Think of your small 20 employee company. One normal access point could easily reach an area that 20 people would sit within. Yet if there were 80 wireless clients on that access point it could quickly get saturated. With cube farm layouts you could easily have hundreds of wireless clients within range of one access point. Typically in an enterprise world if you were to run into that situation you would have to deploy more access points in that area, not for range, but simply for throughput and load. Seems like more of a bandage on the issue than a true solution. Especially realizing the complexity of having multiple access points close to each other fighting in the same airspace. Well if you find yourself either needing more range out of single access point or more importantly needing to support a dense population of wireless clients then you should definitely look at what Xirrus has to offer.

Xirrus puts anywhere from 4 to 16 radios into an “access point” and in doing so truly solve your density issue with wireless clients. My example above is a manageable situation. Think about conferences or trade shows though and you see where there can be a huge demand for an access point that can handle hundreds of wireless clients within its range. I don’t want to go over all the technical specifications but let me point out a few of the most notable differences in this array. Instead of omni-directional antennas they use directional antennas covering the 4 basic directions (north, south, east, west). These 4, regardless of your model will be the only dual-band a/b/g/n radios. So their basic model, the XN4 has these 4 radios, the XN8 has these four and then adds 5ghz a/n radios in the NW,NE,SW,SE positions. There are XN12 and XN16 models each adding to your 5GHz band. As you can imagine, placing directional antennas in a circular array will give you a bit more range than an omni-directional one. As you move to the XN8+ they can more tightly focus the beam of the directional antenna giving an even greater range.

In the enterprise access point space there is a great need for wireless monitoring. In other words detecting other wireless signals within your air space so you can either move to a cleaner channel or identify rogue AP’s that should be shutdown or removed. Cisco has what they call Cisco CleanAir Technology. Its actually a great technology and Cisco implements it quite well. However one of your radio’s in a Cisco AP has to quickly switch to monitoring mode then switch back to accepting clients in order to maintain this discovery of your wireless signals. You could also buy an access point dedicated to monitoring but in a large deployment it would only monitor within the limits of its range. If you were to use a Xirrus XN8 you could designate one of the radios solely to monitoring this spectrum thus not messing around with that switchover to take clients, still having 7 left for throughput and you could do this for each access point increasing your monitoring coverage. From my initial research you could replace standard access points with ones from Xirrus at a 4:1 ratio quite easily.

The other nice tidbit these add are dual gigabit lan ports for either primary/failover or load balancing into enterprise switches. Considering the number of users they support this is almost a requirement but nice enough even for failover if you need to power cycle a core switch on your network these could stay up serving clients. These Xirrus Wi-Fi arrays lack virtually no core feature I could find within the enterprise AP space handily matching Cisco bullet point for bullet point. There are some differences of course in implementation but if you need to cover a further range, and more importantly a DENSE population of wireless clients you’ll want to check out Xirrus for a solution.

© 2011 VigilCode Suffusion theme by Sayontan Sinha