Public key authentication for non-techies

Over the last couple weeks, I’ve had a number of conversations with people on our product and delivery teams about public key authentication due to conversations they’ve had to have with some of our vendors. After having to explain public key authentication to non-techies several times, I figured it might be useful to post something public in case it helps anyone else.

So what is public key authentication and how does it work?

At it’s base, public key authentication is a secure way for a user or client to connect to a service via SSH, without having to send a password across the wire. Passwords can be intercepted and so the fewer times we have to send a password across an untrusted network, the better. Before the first connection is ever established, the client generates a public/private key pair and then sends their public key to the server they wish to connect to, while keeping their private key private.

Now the math that goes into why sharing this public key in the open isn’t a problem is a bit complicated (but hardly goes beyond grade 12 math), but it’s a lot easier to understand when you compare it to a real world scenario.

Let’s say you have a friend (vendor) and they have a shed (server) that you want to access and leave a batch of freshly baked cookies (files) for on a regular basis when they’re not home. You think about it for a while and come up with a solution: “Friend, please install a separate door (username) on your shed that only provides access to a small section of it (your home folder)”. Next, you go to the hardware store and buy a deadbolt lock (public key) that comes with a metal key (private key) that you keep on your keychain. Finally, you send this deadbolt lock to your friend to install on the door, while never showing them the key that opens the lock.

You can now come and go as you please, leaving your friend freshly baked cookies every few days, and since your key never left your possession, you can be sure that one else is sneaking inside the shed to steal the cookies. Additionally, your friend never needs to see the key because they have access to the whole shed, and you can be certain that no one else will ever be able to open up the lock because they don’t have your key.

This is public key authentication in a nutshell.

One added benefit that I haven’t really touched on here is that public key authentication – when properly created and protected – is the securest way to offer access to a system. Due to the math involved, it would take an adversary many times longer than the entire universe’s existence (that is not an exaggeration) to break your private key. Basically you can assume that if you do it right, it’s going to be secure.

I hope this made public key authentication a little less confusing and daunting for the non-techies who read this site, but if not, Khan Academy has a great video that goes into more depth using paint and color mixing. And if that still doesn’t answer your question, please leave a comment and I’d be happy to go into more detail.

Tell purgeCSS to ignore purging all Tailwind colours

For my photography site where I sell prints (https://fortunavista.com), I have been working on building out the eCommerce portion of it and found myself in a very precarious position: I needed the ability to store references to Tailwind colors in the database and then dynamically load them on the page at render time. This is a problem (as the Tailwind docs will tell you) because purgeCSS needs to see the classes you’re using in the raw PHP or HTML to determine whether it should purge them from it’s compiled CSS file. So, how can we tell purgeCSS to ignore purging all Tailwind colours?

Well, thankfully the purgeCSS developers foresaw a similar situation and so they added the safelist option which you can pass in as a regular expression to tell purgeCSS to leave them alone.

In your tailwind.config.js file, just update your purge block with:

purge: {
    content: [
        ...
    ],
    options: {
        safelist: [/(from|via|to)-(.*)-50$/, /(from|via|to)-(.*)-100$/, /(from|via|to)-(.*)-200$/, /(from|via|to)-(.*)-300$/, /(from|via|to)-(.*)-400$/, /(from|via|to)-(.*)-500$/, /(from|via|to)-(.*)-600$/, /(from|via|to)-(.*)-700$/, /(from|via|to)-(.*)-800$/, /(from|via|to)-(.*)-900$/ ]
    }
},

Now, I only needed to store the colours for use in some minor gradients, so I only needed to save the colour utilities that were in the form of either from-colour-## , via-colour-## , or to-colour-## . If you’re not doing any gradient work, maybe you would want to replace the (from|via|to) indicators with (bg|text) or some other combination of utility classes that involves the colour usage you’ll be working with.

The only thing you will need to keep in mind is that this will necessarily increase the size of your CSS file, and likely by a lot. This may be acceptable for you or it may not be. But if you can handle the size increase, just tell purgeCSS to ignore purging all Tailwind colours.

Find old-style interpolations in your Terraform code

I just recently started a new job and the codebase that I inherited is…not great. One of the main problems is that it was written for Terraform 0.11 and was never fully upgraded to 0.12 and the goodies that HCL2 and 0.13 brought with them. Of course this means that I needed to find all of the old-style interpolations in our Terraform code base and replace them with the new format. Luckily with VS Code and a little regex, this is a super easy task. This regex is PCRE so you can also use it with sed/awk too if you prefer the command line.

  1. Open the Find and Replace panel
  2. Next to the Find box, click the box that looks like: .*
  3. Search for: "\${([a-zA-Z0-9_.]+)}" (you can visit https://regex101.com/r/K8E5xc/2 for an explanation of how it works along with some examples)
  4. In the Replace box, enter: $1
  5. Now when you actually run the search and replace, it’ll pull the interpolated data out of the old-style interpolation by removing the opening "${ and closing }"

Hopefully this helps some of you who might not be as comfortable with regex clean up your code base and find those old-style interpolations in your Terraform code, since I believe 0.14 will start throwing actual errors and not just warnings on these issues.

Posts navigation