Hello, world

Welcome to new server land!

This post isn’t really important, just testing out that everything is working properly on the new server. Move along.

Failover Networking at OVH: A Complete Explanation

At OVH, you can purchase many of what they call “Failover IPs”, which are basically additional IP addresses for your server. They can also be moved between servers in your account relatively quickly, but today we’re going to talk about their applications in virtual machines. The obvious advantage to having many IP addresses is, of course, being able to run lots of VMs and giving them each their own IP addresses. You can run your own VPS provider! Unfortunately, OVH’s configuration for these things is a little bit non-standard, so you’ll need to jump through some additional hoops to get it working.

This post isn’t going to tell you how to get it working in your VMs. I have a handful of other posts (and might make more later) on that topic. This post is going to attempt to explain how failover IP actually works so you can figure it out yourself assuming you know how the networking system you’re working with works.

Continue reading “Failover Networking at OVH: A Complete Explanation”

Abandoning SSH Password Authentication

All too often, I find myself logging into remote computers using a password. You should, of course, never do this. You should always be using pubkey authentication, and password authentication should always be disabled on your machines, but still, I find myself logging into my servers with a password and obviously not disabling the feature. Why? Well, it all goes back to the annoyance of moving my public keys around, especially since I make an effort to never move my keys between machines. I generate separate keys for each machine I have, and I generate new keys when I reinstall my machines. Obviously, this makes it difficult to keep everything up to speed, but it doesn’t have to be so hard. Continue reading “Abandoning SSH Password Authentication”

LessPass: A Password Manager That Doesn’t Know Your Passwords

I have recently started using LessPass for all my important accounts. What is LessPass? It’s a password manager, but unlike other password managers, it doesn’t actually know any of the passwords you have stored in it.

Okay, that doesn’t make any sense. How does it actually work? It securely hashes the settings you define, including the site name, username, “master” password, and some other things such as the number of characters in the password, and allowed character groups in order to generate a secure password. It does all this within your browser and without contacting a remote server. This is where things get interesting. Instead of saving the password, you just enter the same information again, and it regenerates the same password. You can set up an account with the LessPass Database which will let you store the settings for many sites and quickly recall them. It still does not remember your master password, and therefore has no way of actually getting the final passwords that it spits out. Of course, if you still don’t trust it, the database account is completely optional, and you can host your own pretty easily too. I really like LessPass, it allows me to never use the same password for any two sites like I am always told, have a nice password manager, and still not have any of my passwords stored in any databases. I think this is a far more secure system than LastPass or any other password manager on the market.

If that sounds cool to you and you want to give it a shot, you can try it out over at https://lesspass.com/. There is an applet you can use in real time right on the site, and you can also install it as an extension on Chromium and Firefox based browsers. There is an Android app for it too so you can always have your password manager with you. Of course, it’s also all open source and on GitHub (both the applet and the database) so you can host your own or make any changes you like.

An Exploit

Regrettably, some sort of exploit has allowed some of the posts here to be edited by an unauthorized party. For now all posts have been made private, and I will restore them all once I have everything worked out. The security of the site was compromised, and I must take responsibility. It seems the flaw existed somewhere within WordPress itself, and luckily, it has recorded all of the changes. I probably should have been keeping on top of updates more, but I didn’t, and now I have some serious work ahead of me. I will be restoring all posts to their original state as soon as possible. I apologize for any inconvenience and will be taking further steps to make sure it never happens again.

The only content affected was the body of some of the posts. Pages and other content was unaffected. We currently have no reason to believe that any private information including user data or any other information was leaked or vulnerable at any point in time.

Update: I have gotten all posts back to February 2016 repaired and re-published. It appears that no post older than February 2016 was affected, however I will still keep them quarantined until I can confirm that no other posts were affected.

Update 2: I have now confirmed that posts between February 2016 and October 2015 were not affected and restored them. Back to the grind.

Update The Third: As I feared, a few more posts that have been modified have popped up. Now all posts dating back to August 2013 have been repaired and re-published. That includes this post, which is great. 🙂

The Fourth And Final Update: A small handful of other posts were altered, which have now been repaired, and all posts have successfully been restored. Once again, sorry for the inconvenience.