How to avoid manually typing your password into OS X’s password dialog box

When mounting an encrypted disk in OS X for the first time, you’ll be presented with a dialog box that doesn’t allow you to paste in the password. This can be troublesome, especially if you’ve used a long, high-quality random password. Here’s how to get around having to manually enter your password into OS X’s password dialog box.

A. Get the logical volume UUID

First get the universally unique identifier (UUID) for the drive using diskutil. Open a terminal window and enter the following command:

$ diskutil corestorage list

Look for the Logical Volume for the disk. Ensure that you copy the Logical Volume UUID, not the Logical Volume Group or Logical Volume Family UUID.

diskutil to get the disk's Logical Volume

B. Save a Keychain Access password item

Now we need to save a Keychain Access password item for the disk. Open Keychain Access and create a new password item:

  • Keychain Item Name: Name for your disk
  • Account Name: Name for your disk
  • Password: Password to unlock the disk

We’ll need to save more information into the item so once it has been created, search for it in Keychain Access and open.

OS X Keychain password item

Edit the password item to make sure it contains the details for your encrypted drive:

  • Name: Name for your disk
  • Kind: encrypted volume password
  • Account: Name for your disk
  • Where: UUID for the volume copied found using diskutil
  • Show password: checked

The important part for this step is to make sure you enter the UUID for the volume in the Where field.

Save the password item and OS X will no longer ask you to enter a password when you mount your drive.

How To Configure SSH Key-Based Authentication on FreeBSD for Mac OS X and Panic’s Transmit FTP Client

This is a guide for setting up an Apple Mac OS X workstation with SSH key-based authentication to a remote FreeBSD server. I won’t go into any detail about these protocols or try to make a case for using them. If you’re reading this, you probably already have a basic grounding on SSH, SFTP and the implications of SSH key-based authentication. My goal is to outline the steps needed so you can start using key-based authentication on your Mac.

I. Intended audience

The instructions here are aimed at Mac OS X based web developers with at least a moderate level of systems administration knowledge. Most likely you host websites for your clients or employer on *nix servers controlled through a command line interface. You generally work on multiple servers per project. Repeatedly entering secure long random passwords is becoming a hassle. If this sounds familiar, this guide is for you.

I’m on a Mac OS X workstation, currently Yosemite, using the Mac Terminal App to connect via SSH and Panic’s Transmit FTP client to transfer files. The server instructions here are for FreeBSD but you should still find the information useful if you run a Linux-based web server. I expect that you’re familiar with your own environment and have a preferred way of doing things so won’t list every command needed.

The prerequisites for this guide are that you:

  1. already have your server set up to SSH and SFTP with password authentication;
  2. have an account on the server that you use for day-to-day web development;
  3. also have root access to the server.

II. Setting up your Mac workstation and server for SSH Key-Based Authentication

We’ll need to do two main things to get everything working:

  1. Set up your server to accept the key files instead of a password.
  2. Configure your Mac OS X workstation to use SSH key files.

We’ll be moving back-and-forth between the them so for clarity, open up two terminal windows: one will be used for configuring the server, which I’ll refer to as your server terminal and another for configuring your Mac workstation, which I’ll call the Mac terminal.

A. Configure the server

First make sure your server is configured to accept key-based authentication. On the server terminal, open a secure shell to the server as you normally would. Edit the configuration file for your OpenSSH Daemon at /etc/ssh/sshd_config.

Look for the following lines and uncomment or add them:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
ChallengeResponseAuthentication no

You may need to return to this file later but for now, save it and restart sshd. On FreeBSD, it’s the command:

# /etc/rc.d/sshd reload

B. Generate the key files on your Mac

Now you need to generate your private and public SSH key files. The private key file will remain on your Mac and you’ll place a copy of the public key file on the server. To generate the key files, switch to your Mac terminal and run:

$ ssh-keygen -t rsa

The -t flag specifies that you’re creating an RSA key.

You’ll be asked to enter a file name for the key. The default for key files on Mac OS X is /Users/username/.ssh/id_rsa.pub. While you can simply select the default, it might be a good idea to create a key file specifically for each project. That way, if your Mac workstation is ever compromised, you minimise the risk of access to servers used for past projects where your account has been inadvertently left active.

ssh-keygen will also ask if you want to set a password for the key. If you set a password, you’ll have to enter it every time you try to authenticate with the key file. 1

The result should be two new key files in your .ssh directory:

  • The public key: /Users/username/.ssh/yourkeyfile_rsa.pub
  • The private key: /Users/username/.ssh/yourkeyfile_rsa

If you use a service like GitHub you may also see your GitHub key files already in that directory.

C. Copy the public key to the server

Transfer your public key to the .ssh directory of the server account you use to do your day-to-day web development. There are two ways to do this on a standard-install Mac OS X workstation. You can follow these steps:

  1. Go to the server terminal and cd into the account’s home directory.
  2. Create a .ssh directory (~/.ssh/).
  3. Switch back to the Mac’s terminal and copy the public key text using the command:
    $ pbcopy < ~/.ssh/yourkeyfile_rsa.pub
  4. Move back to the server terminal and create an authorized_keys file within the .ssh directory.
  5. Paste the public key text into your authorized_keys file. (Remember that the pbpaste command won’t work on a non-Mac operating system.)

Alternatively, you can run the following command on your Mac’s terminal:

cat ~/.ssh/yourkeyfile_rsa.pub | ssh [email protected]_host “mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys”

However it’s done, you should end up with a file ~/.ssh/authorized_keys for the developer account on the server.

It’s worth making this clear so there’s no confusion: you are giving the public key, yourkeyfile_rsa.pub, to the developer account that you’d previously been using to connect using a password. You should not be giving it to the root account. Make sure you put the authorized_keys file in the developer account’s home folder. Also make sure you don’t accidentally copy and paste the private key, yourkeyfile_rsa.

D. Test authentication to the remote server over SSH

Make sure everything worked by checking if you can connect to the server without having to supply a password. Log out of your existing connection on the server terminal and try connecting again:

ssh -i ~/.ssh/yourkeyfile_rsa [email protected]

The -i flag should be the path to the private key file we generated in step B. Also, if you set a key password, you will be asked to supply it before you can access the key.

You should see your server motd and terminal prompt after pressing enter.

E. Optional: disable password authentication

Since you’ve gone to the trouble of setting up SSH key-based authentication, you may want to disable password authentication after you’ve successfully testing the connection. Uncomment or add the following lines in /etc/ssh/sshd_config:

PasswordAuthentication no

Finally, restart sshd:

# /etc/rc.d/sshd reload

Make absolutely sure that everything works before disabling password authentication, otherwise you may find yourself without any way to remotely connect to your server.2 Unscheduled trips to the data centre are no fun. (Can you tell I’m writing from experience?)

F. Optional: use a ssh config file

An option to save yourself some typing is to put the server and key details into an ssh config file. On your Mac terminal, create a config file at /Users/username/.ssh/config with the following:

Host serveralias
    HostName host
    User your_username
    PubKeyAuthentication yes
    IdentityFile ~/.ssh/yourkeyfile_rsa

This will let you login just by typing:

ssh serveralias

III. Setting up the Transmit FTP client for SSH Key-Based Authentication

After configuring SSH key-based authentication on your server, the SFTP service will start rejecting your login attempts unless you supply your key. Setting up Panic’s Transmit FTP client with key-based authentication is simple but it can be a little buggy.

  1. In Transmit, delete your old connection details and add new connection settings 3
  2. Leave the password blank
  3. Either:
    • From the menu, select Favourites > Import SSH Key File
    • Or click the key picker, which is the key icon to the right of the password box
  4. Import your private key file yourkeyfile_rsa

Connect with these new settings and the SFTP server will grant you access.

Panic Transmit FTP client ssh key picker
Panic Transmit FTP client ssh key picker

If you try this process with a password-encrypted key, Transmit will give you the error: “The file is not in a supported format.” This is a bug and you’ll have to apply a workaround. Panic’s customer support sent me the following instructions:

If the private key is passphrase encrypted (as yours is), or if it lives in a directory other than ~/.ssh/, there are a few extra steps needed to get up and running.

Instead of using the key picker, edit your ~/.ssh/config file and add the following:

Host yourserver.com
IdentityFile /Users/yourusername/.ssh/id_rsa

Then set the site’s Password field to your key’s passphrase and try connecting.

Alternatively, you can try this method:

  1. First, add the keyfile and password to your keychain:
    ssh-add -K path/to/.ssh/yourkeyfile_rsa
  2. Now add the connection details to Transmit but do not enter the password or set a key file.
  3. Transmit will connect using the credentials in you keychain

In addition to being able to conveniently log in to your various servers, you will now also be able to use Transmit for your regular web development file transfers.

IV. Notes

  1. It’s tempting to think that setting a password for your key negates the whole point of this exercise. After all, if you have to enter a password to authenticate with the key file, you might as well keep the existing model of password authentication to the server, right? Not quite and here’s why: the ssh key is a cryptographically secure way of authenticating to your server and is exactly what you want for something accessible to the open internet. While manually typing in the key itself every time you want to open a connection isn’t practical, SSH key-based authentication handles key exchange automatically.

    The key password protects against a different threat. It prevents unauthorised use of the key itself. This has a lower threat profile because it’s stored on your own private workstation. It therefore can be something that’s easier to remember and type.

  2. Remember to backup your keys and store the backups in a secure location. If you lose your keys and have also disabled password authentication, you won’t be able to access the server without physical access or help from your hosting technical support.

  3. I’ve found that editing a saved connection sometimes doesn’t work. This might be a bug in Transmit. Deleting the old connection and creating a new one seems to always work.

Safeguard your email address by registering a domain

A primary email address tied to your email provider could set you up for a great deal of inconvenience if they shut down. Registering your own domain helps control your email regardless of which company you’re currently using.

On Thursday, 8th August 2013, a secure email service provider called Lavabit suddenly suspended operations. Its founder, Ladar Levison, wrote in an open letter on the company’s website that he would rather shut the company down than “become complicit in crimes against the American people.” Although Mr Levison took what he believed to be a principled stand, Lavabit customers were understandably angry at being blocked from accessing their emails. Without warning, long-time customers lost years worth of archived messages. Active users who relied on the company to host their primary email now face the inconvenience of updating their contacts and online accounts with a new address.

One may be tempted to think that a simple solution would be just to set up another email account elsewhere. After all, there are many free email providers offering reliable services. If you’re in this camp, ask yourself how your day-to-day life will be affected if you suddenly and unexpectedly lose access to your email account.

  • Do you conduct business over email? How much productivity will be lost re-establishing communication with clients?
  • Have you saved passwords, document attachments and important account information in your webmail folders? What happens if you can’t log in to the webmail account?
  • How much time will it take to inform all your relatives, friends and contacts of your new email address, especially if your address book was also hosted with the lost email service?
  • How easy is it to reset the passwords of your other online accounts (internet banking, Facebook, Skype, etc.) without that lost email address?

Keeping control of your email address

There are some important lessons we can learn from the Lavabit incident and two things can save you from similar trouble:

  1. Register your own domain and link it to your email provider. That way, you can switch providers while retaining the same email address.
  2. Do not rely on webmail as your only method of accessing your messages. Set-up an email client on your computer and regularly download copies of your email.

Exactly how you go about using your own domain and downloading emails depends on your existing set-up and requirements. I’ll give a quick overview in this post but please note that it only briefly touches on some steps which can be quite technical.

Step 1: Register your own domain

An email address under your own domain keeps it independent of the email host. Your current email provider may go out of business, get bought-out or become unreliable but having your own domain means that you can switch to another while retaining the same email address.

To get an email address under your own domain, you first need to register a name with a domain name registrar. (See this post for more information.)

You can register your domain with the following companies but a web search for “domain registration” will bring up a list of other providers:

  • Another Cup of Coffee Limited – we’ll handle the details of domain registration under your name for £9.99 GBP per year
  • 123-reg.co.uk – a popular UK-based registrar and hosting company
  • namecheap – a US-based registrar that seems to have a good reputation for customer service (I personally haven’t used them)
  • Network Solutions – one of the oldest and well-known registrars but quite expensive

Regardless of which domain registrar you choose, the whole process should only take a few minutes to complete. However, depending on their system, it could take a few hours to a day or more before it’s available for use.

Step 2: Link your domain to your email provider

Linking your domain to an email provider can be intimidating for non-technical people. To make matters more complicated, some end up with different combinations of registrar, free web-based email, business email hosting, and web hosting. Everything can be under one roof or you may have different companies handling each component. The exact steps needed will depend on your subscription packages so covering them in a short tutorial is not practical. (That’s why companies like us exist!)

In general, your registrar will give you an online control panel. This lets you specify settings to hand over control of the domain’s email to an external email provider. Alternatively, it may offer an email forwarding service that automatically redirects messages to another address, such as Gmail or Yahoo Mail.

Changing email providers then becomes a matter of adjusting the control panel to reflect the new company’s settings.

Here are some help pages for a few of the popular email providers:

Step 3: Download backups of your emails

For many people, their main method of checking and sending email is through their provider’s webmail interface. It’s very convenient because there are no programs to set up on your computer. All that’s needed is to open up a web browser and log in. The downside is that you do not retain any copies of your messages. As some of the Lavabit customers found, you will lose everything if the provider suddenly ceases operations.

The solution is to set up an email program (also known as an email client), like Mac Mail, Microsoft Outlook or Mozilla Thunderbird to download emails from your server. Even if you prefer webmail, periodically connecting from your email client ensures that you save the latest messages on your computer’s hard-drive.

Most email providers offer you a choice of ‘POP’ or ‘IMAP’ as mechanisms for retrieving your email. POP will simply download all the messages and if set in your email client, delete the messages after they’re read. IMAP synchronizes your email client with the server so it copies the same structure of read, unread, sent messages and saved folders. (This Rackspace article gives more detail on the difference between the two.) I find IMAP to be the most convenient option. If you mostly use webmail, you should also use IMAP if it’s available.

Too much trouble?

These steps might seem daunting but you don’t need to be a computer expert to get everything set-up. Business users usually have more complex configurations that may need an IT administrator to get everything working properly. However, for personal users and micro-businesses with simple needs, a little bit or research and background reading should allow you to get the job done without any help.

Of course, if you’d rather not go to the trouble of doing this yourself, we’ll be very happy provide you with a quotation. This is not a big budget job as the whole process is fairly quick for those familiar with what’s required.

Some background on the Lavabit incident

I’ll make a slight digression from technical matters as the Lavabit incident may have wider implications for anyone using US-based internet services.

Lavabit offered encrypted email services and was reported in the press to have been used by the NSA whistleblower Edward Snowden. Unlike most email systems, the company’s technology meant that there was no way for them to directly read user emails. While we may never know the truth, it seems likely they were ordered to participate in ongoing surveillance in a form that the founder believed to be against the United States Constitution. Levison was issued with a ‘gag order’ preventing him from giving details on the matter. Shortly after the Lavabit news broke, Silent Circle, another secure email provider, pre-emptively shut down its own service in order to protect its customers.

There is increasing industry speculation that the US government’s surveillance is jeopardizing the country’s businesses since they can no longer be trusted to protect their users’ privacy.

It’s clear that no matter which country you’re in, if your email is hosted with a US provider, you need to assume that the US government will want (or already has) backdoor access to them. Whether or not this is acceptable is a discussion outside the scope of this post. Regardless of where you stand, it’s important to realize that the industry landscape is changing and we can no longer be complacent about safeguarding our data.

Protecting your password

A client’s Yahoo email account was hijacked recently. She found out after an email was sent out in her name, to her entire contact list, asking to borrow several thousand pounds. This was such an obvious scam that no-one fell for it. Fortunately, other than some embarrassment and inconvenience, there were no serious consequences. It could have been much worse.

How did this happen? She’ll probably never find out but easiest route would have been by getting hold of her password. Criminals use different techniques but common methods are:

  • ‘phishing’;
  • ‘shoulder-surfing’;
  • through an infiltrated computer;
  • by capturing the transmitted information.

‘Phishing’

This method because is so common that I’d be surprised if you’ve never encountered it. Phishing is when someone tries to trick you into visiting a fake website and entering your login credentials. Treat any email asking for your account details with suspicion. If in doubt, contact the company using their published telephone number or email address to double-check.

‘Shoulder-surfing’

Shoulder-surfing is a technique where someone simply looks over your shoulder watching what you type. You’re most susceptible to this when you’re working in a public place, like an internet cafe, airport or train. To avoid this, just be aware of your surroundings.

Through an infiltrated computer

Computers can be infiltrated by software that secretly records everything you type on the keyboard. The most risky are those in internet cafes or hotel business rooms. What happens is that a malicious person will install recording software and wait for people to use the computer. A while later, the person retrieves the captured information, which would include web addresses, usernames, passwords and emails. It can be very difficult to know when this is happening so don’t trust public PCs.

Your own computer can also be infiltrated by a computer virus caught through email attachments or infected websites. Windows users should keep their anti-virus software up to date. Apple users have less to worry about but it’s still a good idea to be cautious and occasionally run virus checks.

Capturing transmitted information

This technique is probably one of the most difficult to avoid. Someone with enough technical knowledge can literally watch the passwords and emails flowing through your internet connection. Although it’s possible for this to happen with your wired office network, you’re most at risk when using WiFi.

If you have wireless internet at home, read the manual to make sure you configure it with the highest security setting possible. Things get more tricky when you’re travelling and using the wireless internet services at cafes and hotels.

To protect against this, you’ll need to use VPN software. VPN stands for Virtual Private Networking and is a way of scrambling your transmitted information, hiding it from prying eyes. Unfortunately this software can tricky to set up. They’re often used by corporations with their own IT department. As a small-business owner, this will probably be outside of your comfort zone unless you have someone technical on-board. Nevertheless, if you’re willing to give it a try, ask a computer retailer about VPN broadband routers.

Just remember to exercise caution

As you can see, the techniques range from old-fashioned confidence tricks to high-tech computerised traps. I’ve glossed over the details but key is to use the same common sense online as you would in the real world: don’t take everything at face value; be cautious when in unfamiliar surroundings; get advice on how to use your tools.

This is a complex topic so if there’s demand, I’ll write a more in-depth articles in the future.