Friday, September 05, 2014

You Should Really Enable Two Factor Authentication

To your standard user, when you access a website you create a login and password combination for verification of your id.  The login name (also referred to as a username) is typically either a unique name or an email address.

At first thought, one would think that creating a login and having a user set their password should be sufficient security, even considering that a lot of sites have a minimum set of standards for their passwords (ie:  Length, types of characters required, frequency of those characters, etc).  Unfortunately this is incredibly far from the truth.

As we all know, the number of logins and password combinations that the average user has created could be anywhere from a dozen or two, all the way up into what some consider an astronomical number (depending on the number of sites they have accounts on).  The problem most people run into is that they don't want to have to remember all of those passwords, so they use one common password across all of their sites.  While this is great for them, the problem is, is that once an intruder has your password on one site, they will save it for use elsewhere as a 'just-in-case'.

You can now see the inherent vulnerability in this.  Sorry for the digression, but I felt it necessary to get across my point for the need for another, added layer of security that is very difficult to circumvent.  Two Factor Authentication.

 To quickly sum up the gist of what Two Factor Auth is (referred to after this as TFA), it is an added layer of security on an account, typically by way of login verification.  This verification is usually in the form of either an sms (text message) with a code that the application will then prompt you for (and not continue the login unless the correct code is entered), or via an application produced verification code.  The later, application produced verification code, is used by things like Facebook, where the application on your phone will have an option for a security code.  It will display a code that has been synced with the Facebook servers.

What happens when you login is:
  • You log in to the application on your computer using your login and password
  • You are then prompted for the security code. 
  • You then grab your phone, open the application, click to the security code page in the app and enter the code in to the waiting box in the browser.
If all was entered correctly you are granted access to the application.  What's nice is that the potential intruders may have been able to steal your credentials from the Facebook servers (hypothetically of course), but they would not have your phone with the verification code.  So, even if they try, they will not be able to gain access to your account.

There are a number of sites today that offer TFA in order to protect their users, and the number grows every day.  There is even another page that list sites and the links to the page on each site to enable TFA.  Lifehacker also put up a page on TFA that gives a nice overview of how some of the bigger names have implemented it.  I just hope that those that do not currently offer it are smart enough to know of the benefits and actually implement it before it is too late. 

If you do not yet use TFA, please look into doing so.  While it does add a little bit of action on your part to implement it and use it, that little bit of time is well worth not having your personal and private information stolen and sold.  It is all of our responsibilities to make sure we protect ourselves, not assume that someone is going to do it for us. 

Wednesday, September 03, 2014

Remove Offending Host Key From known_hosts File

If you are managing a whole mess of servers, you may have occasions where the host key associated with a host or hosts, changes.  This is typically due to re-installation.  None the less, when you attempt to ssh to a host for whom you previously had an entry for in your ~/.ssh/known_hosts file, you will see a message similar to the following

Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending key in /home/user/.ssh/known_hosts:811

RSA host key for has changed and you have requested strict checking.

Now, if I were accessing something over the internet via ssh and not on my corporate network, I would definitely need to be suspicious of this message.  You don't want to take chances with your security so always be sure.  But, if you are on your own corporate network and get this, check with your System Administrators, but the machine might have been re-installed.

So, looking at the above output, you will see a lot of information.  Most of it doesn't matter.  What does mater for the sake of removing the key in question is the line that reads:

  Offending key in /home/user/.ssh/known_hosts:811

That line tells you exactly what line in the known_hosts file contains the entry you want to remove.  So, whether you are on Mac, Linux or Unix, this should work just the same. What you want to do is grab that number after the colon above, and run the following command:

  sed -i "811 d" /home/user/.ssh/known_hosts

The -i tells sed to run in interactive mode.  Inside the double quotes you have the line number (grabbed from the output) and then a d (which stands for delete the entry, which it will at the line number you provide).  The only other thing on there is the full path to the known_hosts file.  If your not sure of where it is, it was on the line above the offending key line, in the above output.

Now, you could easily put this into a quick bash script that takes 1 field of input (the line number) and then calls the command as shown.  Either way, I hoped this helps with this common problem.

**Update: Thanks to a comment below from Attila-Mihaly Balazs, for letting me know that you can also use:

  ssh-keygen -f "/home/user/.ssh/known_hosts -R offending-hosts-name

That will remove the entry for the offending host who's key has gone stale, with the added benefit of a back up of the known_hosts file, saved with a .old extension, just before the entries removal.  

If you find you do not need the backup, you can simply delete it.

Creative Commons License
This work is licensed under a Creative Commons Attribution 3.0 License.