Create An Encrypted DMG

If you’ve got sensitive files you can secure them inside an encrypted DMG. It’s far less drastic than using Fire Vault, and it only takes a minute to implement.

People new to computers often confuse file permissions with encryption. Permissions can easily be circumvented. Any user with admin rights on the computer can change the permissions on a file. More importantly, anyone can take the disk and connect it to a different machine and change the permissions.

Encrypted files are different. The only way to access an encrypted file is with the password. Permissions rely on the security of the operating system for protection. Encrypted files have self-contained security, which also makes them portable.

You might want to make a back up of your novel and store it with your web host. But how do you know the web host won’t snoop? Tuck your files into an encrypted DMG before uploading and you’re all set.

When you create a DMG you’re prompted to add the password to your keychain. That would defeat the purpose of the DMG in most cases. Chances are you’re encrypting files that aren’t going to be on your computer anyway. If they are going to remain on your computer consider leaving the password off the keychain to greatly enhance the security.

You could encrypt your entire home folder with Fire Vault, but that seems like a big step for most people. If something goes wrong or you can’t come up with the password you’ll be locked out of your own data, along with everyone else. Murphy only encrpyts files that are truly sensitive. Locking everything down doesn’t make sense.

When you’re done working with your volume eject it, don’t just close the window. Once ejected the volume requires the password for access. When you want to store the file elsewhere just copy the DMG file, not the volume.

SSH Without A Password

When you start using SSH you’ll quickly find it asks for your password. Frequently. Murphy copies files to the web server over an SSH transport and each new copy operation prompts for a password. But it doesn’t have to be that way. Set up an SSH key pair and the keys will handle authentication.

The steps to implement your key pair are pretty straight forward. On the client computer you execute one command that generates the key pair. Then you add the contents of the public key to a file called authorized_keys2 on the server. If the file doesn’t exist on the server you can simply rename your public key file to authorized_keys2 and you’re done.

That’s it. Once the authorized_keys2 file contains your public key you can login with SSH from any machine with the private key. The logic is that only someone with proper credentials could have placed the public key in the appropriate folder on the server. And once that public key is in place only the corresponding private key will be authenticated without a password.

Here’s the really interesting thing about all these keys: You can give that same public key to as many people as you want. And even though they can all use it, and only it, to verify that you have the corresponding private key, they cannot ascertain what that private key is. The underlying technology is called asymmetric cryptography in case you want to know more.

Once you’ve set up the keys like we’ll show you in the screencast you can use other tools without passwords too, like scp and rsync for copying files. We’ll get to scp in a later screencast. Murphy introduced rsync as a way to copy an iWeb site to a third-party server.

This screencast picks up where we left off yesterday, with SSH already up and running.