My guide to setting up SSH keys with Putty

TL;DR: if you just want to set up keys with putty: IDGAF about Cloud At Cost take me to the Putty screenshots. If you are sitting in front of a computer that you don’t have keys set up on, and you are trying to log into a remote server that you have already locked down: I haven’t set up keys on my other computer like an absolute walnut.

Fun with Cloud At Cost
I have become a kind of fan of Cloud At Cost. Their one-time-fee servers and easy build process is great for spinning up test machines. I would hardly recommend running anything that I would consider “production” or mission critical on a cloud at cost VM, but it is a cheap, quick, and simple way to spin up boxes to play with until you are ready for more expensive/permanent hosting (like with Digital Ocean or Amazon). Spinning up a new box means securing SSH. So here is my guide.

The major problem with a hosted server of any kind is drive-by scans. There are folks out there that scan for huge swaths of the Internet looking for vulnerable machines. There are two basic varieties: scanning a single host for all vulnerabilities, and scanning a large number of hosts for a specific vulnerability. A plain box should really only be running SSH, so that is the security focus of this post. There should also be a firewall running, that rejects connections on all ports except the services you absolutely need, but that’s a blog post for another day.

It should be noted that Your security measures don’t necessarily have to be top notch, your box just has to be less convenient than the next host on the scanners’ lists. It’s not hard to scan a large subnet and find hosts to hammer on. Drive-by scans are a numbers game; it’s all about the low hanging fruit. With C@C, it’s a question of timing. You have to get onto the box and lock it down quickly. Maybe I’m just being paranoid, but I have had boxes that I didn’t log in to right after spinning them up and I have seen very high CPU utilization on them when they aren’t really running anything, which leads me to believe that the host has been compromised. Also, beware that the web-based stats can be wildly inaccurate.

This guide will only lock down SSH. If you are running a web server, this guide will not lock down the web server. If you are running Asterisk, this guide will not lock down Asterisk. If you are running MySQL, for the love of god make sure that it’s only accessible from localhost (127.0.0.1) and that is not accessible from the Internet. All this guide will do is shore up a couple of vulnerabilities with SSH. I recommend running these steps *BEFORE* installing anything on your VM.

My use case for Cloud At Cost is something like this: There are times when I need a box that is easier to get to than hosting a box on my home network, but doesn’t really justify the monthly cost of running a server on Linode, Digital Ocean or Amazon. For me, I spend a lot of time working all night inside a very restrictive corporate network, so it’s hard to get access to my stuff at home especially since Team Viewer is compromised. C@C is cheap and easy, which probably means it’s a playground for scammers and other bad actors. This means it’s a good idea to lock down your box before you do anything useful with it, and keep the useful things that you do with it to the bare minimum.

You can get started with C@C for around $35, but if you follow them closely, you can catch some of their discount deals and get a very low end developer box for around $10. I took advantage of a few of these promotions and now I have a bucket of resources at my disposal for all of my tinkering needs. Also, if your box starts to misbehave (loads of network traffic, high cpu utilization, etc.) it’s probably compromised, so just torch it and build a new one.

Getting Started

You can learn about the basics of the Cloud At Cost panel here, the info will be useful later on:

Once you have signed up with C@C, bought some resources, and fired up your Linux VM, it’s time to do some housekeeping. I prefer Debian, and it’s what I am using in this guide, but it doesn’t really matter what you choose.

As soon as the box is up, log in with SSH, using the root password given in the information button. I use putty*, because most of my time in front of a computer is spent working or gaming, so I use Windows a lot. I know it upsets a lot of folks to hear that, but hey, those folks can feel secure in knowing that their “Unix Beards” are mightier than mine.

The very first thing that I do is change the root password. Make like 30 or more random characters. You shouldn’t actually need to type it in after this point, but keep it somewhere encrypted just in case. I also comment out the non-us repo that C@C Debian machines are still pointed to in sources list:

passwd
nano /etc/apt/sources.list

Just locate the line that begins with “deb http://non-us.debian.org” and put a # in front of it. On a C@C Debain 8 box, it should be the first line.

With that pesky non-US entry removed, you are clear to update your packages:
apt-get update
apt-get upgrade

I also run these commands from the Nerd Vittles blog to make sure the password doesn’t revert to the Cloud At Cost root password:

sed -i '/exit 0/d' /etc/rc.local
killall plymouthd
echo killall plymouthd >> /etc/rc.local
rm -f /etc/rc3.d/S97*
echo "exit 0" >> /etc/rc.local

I don’t know if they are strictly necessary, but the dudes at Nerd Vittles recommend it, and they spend waaaay more time doing this stuff than I do, so there you have it.

After that, it’s time to install fail2ban, and then create a non-root user:

apt-get install fail2ban
adduser steve

Hopefully, in a few minutes fail2ban will be made superfluous by our additional security measures. In the meantime it will stop brute force attempts. Some of my hacker buddies change the default port for SSH to throw off driveby scans, but the restrictive corporate network I mentioned before doesn’t like arbitrary ports, so that’s a hard no in this case.

Enable Sudo for a Non-Root User

To start implementing our security measures, we will install sudo, add ‘steve’ (our non-root user) to the sudo group, and then make sure steve has the right permissions in the sudoers file:
apt-get install sudo
adduser steve sudo
nano /etc/sudoers

At this point the /etc/sudoers file should open in the Nano next editor. I know I should be using vi, but I am too busy #YOLOing to do that Unix Beard crap. 🙂

Press ‘ctrl+w’ to open the search box, and type ‘%sudo’ to find the permissions line.
Press ‘ctrl+k’ to cut the ‘%sudo ALL=(ALL:ALL) ALL’ line, and then ‘ctrl+u, ctrl+u’ (hold ctrl and press ‘u’ twice) to paste the line in twice.
Edit the second line to read ‘steve ALL=(ALL:ALL) ALL’ and press ‘ctrl+x’ to exit, and press enter to save.

Setting up sudo is important because we are going to disable root logins here in a minute, but first we are going to set up SSH Keys for logins and then disable clear text logins. SSH does use clear text passwords, but it passes them through an encrypted tunnel. This means that while your password isn’t likely to be sniffed, it could be guessed or brute forced. Using SSH keys means you have to have the right private key to match with a public key on the server. But before we can do any of that, we need to test the new non-root account by logging in with it.

Once you are logged in as steve, test sudo:
sudo whoami

Which should return ‘root’.

Securing SSH with Asymmetric Keys

Once the non-root account is working and sudo-ing, we can proceed to lock down SSH with public+private key pairs. I will explain how to do this with putty for Windows, but it’s actually way easier to do this with Unix.

The first step is to make sure you have puttygen.exe handy. Download it and launch it, change the bits for your keys to 4096 (in the lower right corner) then click the ‘Generate’ button.

Wiggle the mouse around for a bit, and in a minute or so you will see your public key, with a key comment and blanks for your passphrase. You don’t have to change the comment, or enter a passphrase, but I recommend it. I like to change the comment to match the username and server (‘steve@stevesblog.com’ in the screenshot below), since I have lots of different keys. The passphrase keeps things safe in case your private key file falls into enemy hands.**

At this point, you may be tempted to use the same passphrase for your private key as you use for your non-root user account. This is a bad idea, because your non-root password is now basically your root password. Do yourself a favor and use two completely different passwords.

Next, click ‘Save private key’ and save the resulting .ppk file in a safe location, but don’t close the puttygen window just yet. If you use multiple computers, putty will let you re-use your private key file between Windows machines, if that’s what you’re into. SSH on Linux may, but it will not let you use a puttygen file in a Linux system. (Based on that one time I tried it and it didn’t work for me.) So just keep that in mind.

Also, it’s no big deal to have multiple private/public key pairs on the same server. You can use a different pair for each client computer, which is probably safer and more convenient than using a shared key pair. If you lose access to a client machine for whatever reason, you can just delete the public key off of the server and that machine won’t be able to connect to your server.

Leave your puttygen window up and switch back to your putty/SSH window. Create a .ssh folder and a key file for SSH, then a text file to store your keys:
mkdir ~/.ssh
nano ~/.ssh/authorized_keys

Paste the Public Key text in the top of the puttygen window onto a single line in the file. This will be a Very Large Line Of Text(tm) (VLLOT). The VLOTT should begin with ‘ssh-rsa’ and end with ‘rsa-key-yyyymmdd’ where yyyymmdd is the date you created the key. Sometimes the key comment (steve@stevesblog.com in the example below) is the last bit of text. I haven’t quite nailed down why that is, presumably an order of operations thing. Anyway, be sure that the VLOTT begins with ssh-rsa, or you didn’t grab all the text in the public key.

Save and close the file (‘ctrl+x’ and then ‘enter’) and then set the permissions for the file:
chmod 600 ~/.ssh/authorized_keys

UPDATE: on CentOS 7 the home directory (~), the .ssh directory and the authorized_keys file should all be writable only by the owner so do this instead:
chmod 0700 ~
chmod 0700 ~/.ssh
chmod 0700 ~/.ssh/authorized_keys

Now exit your ssh session and reopen putty. You need to set the IP address of your server as the hostname. I prefer this to host names because DNS can’t always be trusted. Give your session a useful name.

Under ‘Connection -> Data’ add the username for your non-root account. In this example, I named my account ‘steve’.

Under ‘Connection -> SSH -> Auth’ browse to the safe place you saved your private key. You pasted your public key onto the server, and you have your private key stored on your computer. You will want to keep the private key file safe because if you lose it you have to set up a new pair while logged in at the console, which is a total pain. I keep mine in Dropbox so I can use them on multiple PCs, but I keep them secured with a passphrase.**

Now go back to Session and save your session profile. Henceforth you can connect simply by double clicking ‘steve’s server’ under ‘Saved Sessions’.

Now it’s time to test your new key pair. Just double click ‘steve’s server’ and you should be prompted for the passphrase that you set for your private key. Once you enter it, you should be logged in to the server as user ‘steve’. If you were able to log in using your key, you are all set to move on. You are now free to close PuttyGen.

* Protip: put your putty.exe file in ‘c:\windows\system32’ so you can run putty from the command line or the run line. If you want to be a real hard rock, rename putty.exe to ssh.exe. Did you know putty accepts commandline args? It does, so you can do awesome Unixy shit from the command line like type ‘ssh steve@testbox.stevesblog.com’ to connect to a remote host. It still pops up your connection in the putty window, but it keeps your hands on the keyboard. 🙂

** Another Protip: not setting a passphrase is handy for automating ssh connections, especially if you want to move files back and forth with ‘scp’ or mess with tunneling via local and remote ports. I haven’t found a decent scp command line app for Windows, other than the Unix utils in CygWin.

If The Server Rejects Your Key

It’s most likely that you didn’t paste the public key correctly. This is why we left the PuttyGen window open. 🙂

Log in with your non-root username and password (‘steve’ in this example) and open your ~/.ssh/authorized_keys file in nano again:
nano ~/.ssh/authorized_keys

In the PuttyGen window, make sure that you scroll to the top of the public key text. It should begin with ‘ssh-rsa’. Now click and drag down to the end of the public key text, then right click and select ‘copy’.

In the Putty window, with your authorized_keys file open in nano, delete the incomplete key and paste the complete text of the public key on a single VLLOT.

Save and exit nano, then exit your SSH session and try again.

Also make sure that you changed the permissions of the authorized_keys file:
chmod 600 ~/.ssh/authorized_keys

If your key is still being rejected, generate a new public and private key by clicking the ‘Generate’ button and starting the whole key process over again.

Disable Root and Cleartext Logins

Once your keypair is working, (and you are able to log in with it) it’s time to eliminate root logins and cleartext logins. Some folks will tell you that root logins are fine with SSH because passwords don’t get sent in the clear. While that’s true, ‘root’ is still the one username that is guaranteed to be on every Unix-based machine, so if you are going to brute force an account, this is the one to focus your efforts on. Disabling root logins and clear text logins is all done in the sshd_config file:
sudo nano /etc/ssh/sshd_config

Press ‘ctrl+w’ and search for the word ‘root’. You are looking for this entry:
# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

Change ‘#PermitRootLogin yes’ to ‘PermitRootLogin no’. (uncomment if necessary and change from ‘yes’ to ‘no’.)

Then press ‘ctrl+w’ and search for the words ‘clear text’. You are looking for this entry:
# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

Change ‘#PasswordAuthentication yes’ to ‘PasswordAuthentication no’ (uncomment and change from ‘yes’ to ‘no’.)

Once these changes are made, DO NOT LOG OFF OF YOUR SSH SESSION. Once these changes are implemented, it will be hard to log back in to undo anything if you make a mistake. You should have tested and succeeded with your ssh-key based login because we are about to restart the ssh daemon and prevent clear text logins:
sudo systemctl restart ssh

UPDATE: on Debian 9 you can restart SSH with
service ssh restart
UPDATE: on CentOS 7 you can restart SSH with
systemctl restart sshd.service

To test ssh logins, connect to the IP of your server with putty using the ‘Default Settings’ profile. Your login attempt should fail because only people with private keys are allowed to the party:

At this point you are far from being hack-proof, but you are a bit more locked down than you were before, and there are always more convenient targets out there 🙂

Hardening web servers is another story, which really isn’t my bag to be honest. There’s a reason that I host my blogs with Google or WordPress 🙂

OH SHIT! I set this up on my Windows machine at home and I don’t have access to my private key at work/school/Aunt Tillie’s computer!

So you’ve set up your keys, you’ve disabled clear text logins and now you are trying to get a new public key onto your locked down box, but you can’t log in because you don’t have the private key. How screwed are you?

Not completely.

I find myself in this situation when I am setting up a new Linux or Unix workstation. With Windows I use a cloud storage service to keep my keys (that have passphrases), and I use one key pair per server, and just reuse my private key on each of my Windows machines.. The passphrase protects the private key on the cloud service (should the cloud service experience a breach or some other security failure) and on the local drive of my PC, should it fall into the wrong hands.

In the Unix world, I do the opposite. As I stated above, SSH keys are way easier to do with Unix. It’s no problem to produce key pairs and upload them to remote servers, so I use one key pair on per workstation, but then I use that pair on each of my servers.

This is probably a much safer practice than my Windows+Dropbox approach, but I use encryption tools like BitLocker and KeePass to add an little more security when I use Windows.

All you have to do on your new Unix box is create a new key pair like so:
ssh-keygen -t rsa -b 4096

And then use the ever so handy tool ssh-copy-id to add the newly created public key:
ssh-copy-id -i ~/.ssh/id_rsa user@remote-server

It couldn’t be easier, except when you have disabled password logons like an absolute walnut. In that case, you will need to log into both your new Unix box and your locked down remote Unix box from a computer that already has a key pair configured with the locked down remote server. For this reason, I recommend setting up a VM, a container, or a shell account to use as an intermediary.

By default, RSA key pairs will be stored in ~/.ssh/id_rsa (private) and ~/.ssh/id_rsa.pub (public). Once you are logged in on your third computer that is already set up with a key pair, open an SSH connection to the new Unix machine and an SSH connection to the locked down remote server. For the purposes of this demonstration, I will call the new box “newbox” and the locked down remote server “remotebox”. Both non-root user accounts will be called “steve”.

In the window for your session on newbox, view your id_rsa.pub file like so:
steve@newbox:~$ cat ~/.ssh/id_rsa.pub

You will see the familiar Very Long Line of Text ™ (VLLOT) which is the public key. The text will fill multiple lines. This is important to note, because you will need to copy all of these lines in a moment.

In the window for your session on remotebox, edit your authorized_keys file like so:
steve@remotebox:~$ nano ~/.ssh/authorized_keys

You will see the VLLOT that you pasted in when you locked down the server initially. It will be all on one line, and will most likely be truncated. This is important to note because you will be pasting text into this window in a moment.

Now you just copy the VLLOT from the window with your session on newbox into the editor window with your session on remotebox. If you are using putty for this operation, you can copy text by pressing ALT+C, instead of CTRL+C. CTRL+C cancels things in the Unix shell, and in Nano it will show the current cursor position.

Your window with our session on remotebox should now have two Very Long Lines Of Text(tm). Use the arrow keys on your keyboard to verify that the whole line is there. If you are certain that the VLLOT was pasted correctly, simply save the authorized_keys file and exit. In Nano, CTRL+O to saves and CTRL+X exits.

Once you have saved the authorized_keys file, switch to your window with your session on newbox. You can now attempt to connect to remotebox via SSH:

steve@newbox:~$ ssh steve@remotebox

If all goes well, you should be prompted for your passphrase for “/home/steve/.ssh/id_rsa”. If not, you probably didn’t paste the VLLOT correctly.

Public Access Unix Rocks

As I stated before, I recommend having a VM, container, or a Unix shell account to use as an intermediary for accessing locked down remote servers. Getting remote access to your gear is important. So important that I run multiple VMs to make sure that I can access everything remotely.

If you are not fortunate enough to be blessed with an embarrassment of hardware like I am, you can still use a dedicated server as an intermediary by signing up for a shell account with SDF.

I have had a shell account at SDF for decades. It enabled me to learn about large Unix systems without needing to set up a Linux box. Even if you have a server at home and a hosted server somewhere else, having a Unix shell account is still a great tool to have in your arsenal for way more than just stupid SSH tricks.

The FBI asking Apple to Backdoor an iPhone is a Rubicon for Privacy

The US District Court of California has asked Apple to backdoor a locked iPhone for the FBI. This isn’t a request to unlock a single phone, this is a request for Apple to build a tool that lets the FBI circumvent the security on the iPhone… as in basically all iPhones, which will then set a precedent for all smart phones.

“Make no mistake: This is unprecedented, and the situation was deliberately engineered by the FBI and Department of Justice to force a showdown that could define limits our civil rights for generations to come. This is an issue with far-reaching implications well beyond a single phone, a single case, or even Apple itself.”

In case this is your first time reading about why government mandated back doors are a universally bad idea, here is the quick list:

1. A digital backdoor, much like a real back door, can be used by anyone, not just those authorized to access it. Back doors make excellent targets for criminals, spies, and other bad actors. These things get discovered, and then they get misused. If you are a criminal, and you are looking to steal data, knowing that there is a backdoor in a system lets you focus your cracking efforts.
2. Encryption is only good when it’s secure. Insecure crypto is worse than useless because it creates a false sense of safety and control. This is why Digital Rights Management technologies never work. No matter how you slice it, a purpose built entry point is a vulnerability. Once you introduce a back door, or a “Golden Key” it invalidates the security (and value) of the entire system (see point 1). An insecure phone just isn’t worth as much as a secure one.
3. The bad guys you are trying to catch are bad guys. They don’t give a single runny shit about government regulations. This means that the bad guys who use crypto will simply switch to new illegal tools that don’t have back doors. When the SOPA bill threatened to block DNS for sites accused of piracy, tools immediately began to surface that would defeat the blocks, before the bill was even voted on.
4. In the case of criminals, government mandated back doors would create a market for secure tools. These tools wouldn’t be Made In America like the *iPhone. Back doors would devalue the iPhone (see point 3) and add value to technologies that aren’t made in the US. Meanwhile, Federal Law Enforcement still couldn’t access phones that belong to terrorists. All the damage done by this would be collateral because the only people affected by this mandate would be innocent bystanders.

There are *tons* of other reasons why back doors are bad, but those are the top 4. Cory Doctorow sums the argument against back doors fairly succinctly in an article in The Guardian:

That’s really the argument in a nutshell. Oh, we can talk about whether the danger is as grave as the law enforcement people say it is, point out that only a tiny number of criminal investigations run up against cryptography, and when they do, these investigations always find another way to proceed. We can talk about the fact that a ban in the US or UK wouldn’t stop the “bad guys” from getting perfect crypto from one of the nations that would be able to profit (while US and UK business suffered) by selling these useful tools to all comers. But that’s missing the point: even if every crook was using crypto with perfect operational security, the proposal to back-door everything would still be madness.

The Law Enforcement community declares war on crypto in one form or another once or twice a decade. Every time they do, we as digital citizens need to stand up and say “NO!” They will keep trying, and we have to keep fighting, every time. It really is that important.

*The iPhone isn’t made in America either, but Apple does employ Americans around the country. Russian mobsters or Romanian cyber-criminals presumably don’t employ many Americans.

More on the War on Crypto, Inspired by Paris

Darren KitchenThreatWire captures the issues at stake when states take aim at crypto:

The Drama With My New Laptop: the High Cost of Saving $350 (part 2)

This post contains a lot of profanity. Like a shitload.

When we last left our heroes, I had finally gotten Windows working on an SSD after trying a bunch of things, and then basically giving up and then reinstalling everything. Now that the SSD was working, the time had come to encrypt the SSD.

I am a fan of block crypto. I encrypt lots of things, not because I am worried about the government seizing my gear (well, not *that* worried) but because gadgets get lost and stolen. I lost my mobile phone a couple of years ago, and if I hadn’t encrypted it, it would have been nerve wracking worrying about what someone might do with the data that’s on it. So rather than worry about what is or isn’t protected, I just encrypt the whole drive. Full drive encryption is important because Physical Access is Total Access. I have rescued untold amounts of data for others from their crashed or otherwise misbehaving hard drives by removing them and plugging them into a different computer. I don’t normally encrypt the drives on my gaming rigs because if the FBI or whomever needs my Goat Simulator game saves that badly, they are welcome to them. This was a special case because it’s a gaming laptop. My rule is that if it leaves the house, it has to be encrypted.

Modern computers use UEFI to “securely” boot the operating system. I guess this is a security measure to prevent someone from booting your laptop from a CD and stealing all your shit, but since this laptop doesn’t have a Trusted Platform Module, Secure Boot doesn’t protect you from someone plugging your drive into another computer and stealing all your shit, I think it’s more trouble that it’s worth. If you have to ask Windows for permission to boot off a CD, it’s just going to stop the user from doing what he or she wants, it will not stop Proper Villainy(tm).

My favorite disk encryption tool, TrueCrypt, vanished under mysterious circumstances. I won’t get into the conspiracy theories behind its demise, but I have decided to keep encrypting my drive, and that leads me to the next chapter of this saga, where I get punished for using the basic version of Windows.

Part 2 – Solid State Drama’s Revenge

I prefer to run Windows on laptops because of all the bullshit proprietary hardware that goes into them. I am probably showing my age here, but there was a time when hardware support in Linux was spotty. I have swapped out Intel WiFi card for an Atheros cards in laptops to make sure I can do packet injection, but I now have a dedicated Kali laptop for that sort of thing. For my daily driver/EDC laptop, life is just easier with Windows. I know that that fucking with Linux makes a lot of dudes feel superior, and they probably are. For me, I prefer to use Linux for specific tasks (i.e. Kali and Clonezilla) or for servers. With that being said, I am not such a Windows fanboy that I care about the differences between Windows versions. My personal laptop won’t be joining an Active Directory domain, so I just go with whatever version came with my laptop, which I replaced with whatever version MS let me download when I migrated to the SSD.

This path of least resistance philosophy led me to entertain thoughts of using BitLocker to encrypt my hard drive, only I am not running Windows 8.1 Professional or Enterprise, so I guess that BitLocker isn’t included with my version. There is no fucking way that I’m forking over $150 for a new version of Windows after working so hard to save $200 on the RAM and SSD. No TrueCrypt? Fine. No BitLocker? Whatever. I don’t give a fuck. I’ll just use a fork of TrueCrypt called VeraCrypt. Well, VeraCrypt’s boot loader doesn’t play nicely with UEFI and GPT partitions. It only works on MBR disks. feelsbadman.jpg

So after days of messing with various tools to get Windows working on my SSD, and then enduring the hassle of setting up Windows all over again, and waiting on my Steam library to download again, I am faced with yet another hard disk challenge: converting my GPT partitioned drive to MBR without deleting anything. Honestly, now that Steam is in the Debian repos, I am sorely tempted to make my next gaming rig run Linux.

I tried a bunch of things and ended up using the pirated AOMEI tool to do the conversion, and it worked, sort of. The drive booted, and VeraCrypt didn’t bitch about GPT anymore. However, when I went to back up the drive one last time before encrypting it, I discovered that AOMEI half-assed the conversion. According to Clonezilla, my drive had some remnant of the GPT boot stuff left on it that I had to fix with the Linux version of fdisk for GPT, a.k.a gdisk. I have screwed up plenty of working partitions with fdisk, so I was nervous to say the least. Also, the magical -z option that I needed to was buried in the “expert” menu section (AKA Here There Be Dragons!) which added to the danger. Clonezilla said to run gdisk -z but -z isn’t a valid option from the command line.

I read this tutorial to figure out what had to be done, and in the end I just closed my eyes, clenched up my butt cheeks, and hit enter. I got it working, and thankfully I had already made plenty of backups, just in case. Speaking of backups, I should find a way to make running Clonezilla easier…

Update 8/16 – A few months ago, I tried migrating to Win10, but it was a shitshow. I just pirated Win10 Pro (thanks to KMSPico portable, JFGI) and used BitLocker without a TPM. This was less stressful since I set up easy bare metal backups in Part 3.

Stay tuned for the thrilling conclusion in Part 3 – Making Backups Easy to do is Hard 🙂

The Drama With My New Laptop: the High Cost of Saving $350 (part 1)

This post contains a lot of profanity. Like a shitload.

I bought a new laptop a month ago, which for me is like moving to a new apartment. Getting it set up the way that I want it has been a total pain in the ass. Mostly because I have decided to save money by implementing key features myself, but also because the relentless march of progress in the PC market has left me behind. This was an uncharacteristic purchase for me, but I wanted a powerful laptop that I could write, code, play games, and run multiple VMs on. In short, I violated my first rule of personal computing, which is to use dedicated computers for specific tasks.

The goals were:

1. Be made mostly of aluminum – my laptops tend to have case or hinge problems before they have actual hardware problems, although when they do have hardware problems, it’s almost always the hard drive.
2. Be ready for anything – have 16gb of RAM, an SSD, USB3.0 and a high end GPU
3. Have a big screen and full size keyboard – this is replacing a full-sized laptop
4. Have ample storage – I also bought a caddy to go into the CDROM bay to house a second hard drive
5. Be encrypted – I normally don’t keep important things on laptops, or gaming rigs, but this is my main computer now
6. Be backed up regularly – I am not usually a stickler for backups because I use several computers. But with this machine, I want to be able to do a full disk image fairly easily

I have built enterprise servers in less time than I have spent tweaking this fucking laptop. I have more or less achieved all of my goals at the considerable expense of my time and possibly my sanity. There are three major sources of my discontent. The first is that copying a Windows install to a smaller drive is wildly difficult and Asus makes the process even more so. The second, is that Modern versions of Windows are not very friendly with the block crypto tools that I trust. The third is that because I decided to remove the optical drive, I wanted dual-boot Windows with my favorite cloning tool, Clonezilla.

Part 1 – Solid State Drama
I went with the Asus N550jx because it is a mostly aluminum mid-range gaming laptop with a big screen, full size keyboard with keypad, and a touch screen. I can sort of take or leave touchscreens on laptops, but my wife is a fan. I like for she and I to have the same model of laptop. That way, when she runs into problems, I am already very familiar with the hardware and software she is using. The N550jx comes in two models: one with 8GB of RAM and a 1TB mechanical HDD, and one with 16GB of RAM and a 240GB SSD. Both models have the same processor, GPU, screen, and case, and I was able to price another 8GB of ram and a 250GB SSD for almost half the price of the difference between the two models, for a savings of roughly $200. It was a mistake brilliant idea!

Getting the upgrades installed was a series of misadventures. The first obstacle was that for no good goddamn reason, Asus decided to use #5 Torx screws on the chassis. I have plenty of star bit screw drivers from working on Compaq computers back in the Dark Ages, but no #5’s. So what any red-blooded All American Man would do. First, I went on the Internet and complained, and then I ordered yet another set of screwdriver bits from Amazon.

With the SSD and RAM in place, it was time to get the OS off the mechanical drive onto the SSD. In the past, moving an install of Windows was simply a matter of shrinking partitions with GParted and cloning them with Clonezilla. With the Asus N550jx and Windows 8.1, there is a bunch of bullshit associated with hidden restore partitions with weird flags and whatnot. It is this bullshit that thwarted my countless attempts to migrate the partitions correctly. I even used pirated copies of notable commercial disk cloning tools like Norton Ghost and AOMEI with little success. After a few days of trial and error, I ended up just doing a clean install of Win8 on the SSD. Fortunately, Microsoft lets you create your own install media from an activated Windows system, and Asus is kind enough to make drivers and utilities available on their website for download. So after much installing of software, I had a working OS on the SSD.

All of this trial and error is why I am a huge fan of bare metal backups. I have used all manner of tools and other nonsense to back up Windows and/or data, and the only thing that is truly reliable is dumping the entire drive to an image file on a separate drive. Copying data always leads to missed files, and snapshots and restore points become corrupted especially when malware is involved. Rolling an infected PC back to a restore point is the fastest way to get rid of malware, so most crackers wipe out your restore points as part of the exploit process. Because of this, I don’t really care about recovery partitions, or restore points, or any of that other bullshit. If my laptop eats itself, I just want to roll it back to where it was just before the last time I tried to do something stupid to it. I understand that your typical consumer isn’t familiar with imaging hard drives, and that is why those other tools exist, but for me it’s Clonezilla or GTFO.

Stay tuned for Part 2: Solid State Drama’s Revenge 🙂

The Paris attacks and the Intelligence Community’s Renewed Attack On Internet Crypto

There are a number of stories circulating about calls from the intelligence community to backdoor encrypted communications in the wake of the Paris terrorist attacks by ISIS. Some of these stories personally blame Edward Snowden for these attacks.

The desire for the powers that be to have access to all means of communications is not new. In fact, government surveillance of telecommunications without a warrant dates back to the telegraph.

Wanting to monitor enemy communications makes sense from a tactical standpoint. Knowing what your enemy is communicating gives you a tremendous advantage on the battlefield. The problem with monitoring everything is that it violates the rights to privacy of literally everyone. That means that in the war on terror, everyone’s 4th  and 5th Amendment rights are collateral damage.Signals Intelligence is important, make no mistake. It can also be a boondoggle. Like computer forensics, intelligence offers you a tremendous number of tools that you can employ to gather all manner of information, but if you are looking in the wrong place, you can end up allocating a lot of resources and end up with not much in terms of useful or actionable information. Case in point, the East German Stasi who spied on so many of its own citizens and missed the warning signs that the Berlin Wall was going to come down.

One notable bit of info from these stories is that there could be some sort of ISIS help desk available 24×7 to assist with subverting American surveillance, which I think is pretty funny. It conjures to my mind the image of a young jihadist wearing a headset and being yelled at by a heavily armed cleric who is insisting that “I don’t need to turn it off and on again!” Finally there is a tech support job that must suck even more than working for doctors 🙂