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.

Post-migration steps: what to do after a Drupal to WordPress migration project

From time-to-time I get clients who ask me to only export the content to a WordPress database, after which they’ll complete the remaining setup themselves. If this applies to your project, you can use these migration notes to help get your new WordPress site running properly.

Import the database dump file

Please see these notes for importing the WordPress dump file.

Administrator credentials and email address

I will have changed your content management system (CMS) administrator password and email address to help with debugging. It’s important that you change these to your own as soon as possible.

Drupal and WordPress user passwords are encrypted so I won’t be able to view them. However, for your peace of mind, I recommend that you ask all your users to reset their passwords after your new WordPress site is live.

Server credentials

Please remember to change any database, (S)FTP, SSH server and control panel credentials you may have given me.

Migrating to a live server

I perform most Drupal to WordPress migrations on a development server. For help on how to move WordPress to your live server, please see: WordPress Codex: Moving WordPress.

Common errors after moving to a live server

Please see below for some common errors you may experience after migrating your new WordPress site to a new server.

Incorrect domain in URLs

WordPress stores domains in the database. If you performed the migration on a local or development server, there’s a good chance that the links will be incorrect after migrating to your live server. Use the Interconnect IT utility to run a search and replace on your database. This will also correct changed database prefixes.

More information can be found on the interconnect/it Search Replace DB page.

“You do not have sufficient permissions to access this page”

If you receive this error after logging in to your new WordPress installation, it’s possible that the database prefix on your new WordPress site is not set correctly. This may happen if you move your WordPress installation to a host that uses a different database prefix.

Try running one of the queries below. Replace wp_new_usermeta, oldprefix_ and newprefix_ as appropriate.

Option 1:

UPDATE wp_new_usermeta SET meta_key = REPLACE(meta_key,’oldprefix_’,’newprefix_’);

UPDATE wp_new_options SET option_name = REPLACE(option_name,’oldprefix_’,’newprefix_’);

Option 2:

update wp_new_usermeta set meta_key = ‘newprefix_usermeta’ where meta_key = ‘wp_capabilities’;

update wp_new_usermeta set meta_key = ‘newprefix_user_level’ where meta_key = ‘wp_user_level’;

update wp_new_usermeta set meta_key = ‘newprefix_autosave_draft_ids’ where meta_key = ‘wp_autosave_draft_ids’;

update wp_new_options set option_name = ‘newprefix_user_roles’ where option_name = ‘wp_user_roles’;

Please note that these queries may not work for you. Success depends on your specific setup.

For more information, please see the following pages:

Further help

I’ll be very happy to provide support you if have difficulties after migration. For a quotation, please contact me. I also offer customised hosting and maintenance packages. Please ask for details.

Importing your WordPress dump file after a Drupal to WordPress migration

If you hired me to run a content export only, you’ll be responsible for setting up WordPress on your own server. Here are some notes to help you with importing the migrated WordPress database.

Import the database dump file

I will deliver either a MySQL database dump file or login credentials to the phpMyAdmin control panel for your project. The first thing you’ll need to do is import the WordPress database into your hosting environment.

Update the database for your domain

WordPress stores domain settings in the database. Since we run the migration and testing on a development server with a temporary sub-domain, you’ll need to update the settings to match your live domain. The easiest way to do this is to use a search and replace utility by Interconnect IT.

It’s pretty straight forward and only takes a few minutes. In the search and replace section:

  • Search for: the domain for your test server
  • Replace with: the domain for your live server

Change the login credentials

I use my own admin email address and password during the migration. For security, please change the administrator user details for your live site. After updating the domains, go directly to the login page to make additional adjustments.

  • http://YOUR-DOMAIN/wp-login.php
  • username: [Your username]
  • password: [Your password]

Your temporary administrator username and password will be sent separately.

Set your WordPress theme

Set the WordPress theme to one that you have installed. I use one of the standard WordPress themes for the migration. However, if the new WordPress site isn’t set to use to a theme you have installed and configured, you may get a blank screen while browsing the site.

  1. After logging in as admin, go to Dashboard > Appearance > Themes.
  2. Select the theme you want to use.

Handling Drupal terms during a Drupal to WordPress migration

When migrating Drupal terms into WordPress, it’s important to understand exactly what terms are and how the two systems handle categorising information.

A primer on Drupal taxonomies

One of Drupal’s most powerful features is its ability to organise content with taxonomies. Unfortunately, the taxonomy system is also notorious as one of the trickiest things about Drupal for beginners to understand. You can find a more detailed explanation here but essentially, a taxonomy is the practice and science of classifying things. In content management terms, you would mostly use taxonomies to organise and categorise articles or posts.

Taxonomies in Drupal uses the concept of vocabularies and terms. Terms are just a list of words that describe a particular type of content. They’re grouped together into vocabularies, which can be thought of as ‘containers’ for a set of terms. Vocabularies may be assigned to any content type. Drupal allows you to arrange the terms within a vocabulary using a parent-and-child hierarchical structure or they can be a flat list, with each term being on the same level as the others.

You can have many vocabularies in Drupal, each containing any number of terms. Vocabulary names must be unique and you cannot have duplicate term names within a vocabulary. It’s possible, however, to have the same term name appear in different vocabularies. Fig. 1 shows an example Drupal taxonomy with three vocabularies, Music, Movies and Books. The Movies and Books vocabularies both have the term Sci-Fi.

An example of Drupal vocabularies and terms
Fig 1: Drupal vocabularies and terms

For more information about the Drupal taxonomy system, please see Organizing content with taxonomies.

WordPress categories and tags

WordPress’ system for organising content is simpler. You have the option of categories–which can be hierarchical–and tags which are flat, or non-hierarchical. In general, categories in WordPress are used as a way of broadly organising posts and tags are used for more detailed descriptions.

Unlike Drupal, where you can have many containers in the form of vocabularies, a standard WordPress installation offers one container for categories and one for tags. Also as standard, categories and tags can only be assigned to the WordPress post content type. A WordPress developer can extend this by creating custom content types with their own categories and tags.

Fig. 2 shows show you’d organise the Music, Movies and Books categorisation in WordPress.

WordPress categories and tags
Fig. 2: WordPress categories and tags

Migrating Drupal terms as WordPress categories and tags

When running a Drupal to WordPress migration, we need to map Drupal’s more complex multi-vocabulary taxonomy system into the simpler WordPress model of categories and tags. How we do this depends on how you want to organise your new WordPress site. For example, we can:

  • convert Drupal vocabulary names into WordPress categories and Drupal term names into WordPress tags;
  • convert Drupal terms into WordPress categories and sub-categories;
  • vocabularies and their associated terms.

It’s all up to you and we figure this out during the requirements gathering stage of the project. For many sites, converting Drupal vocabulary names into WordPress categories and Drupal term names into WordPress tags, as shown in Fig. 3, seems to be the most sensible option. The important thing to know is that the migration may require us to ‘collapse’ or combine your taxonomies.

Merging Drupal and WordPress taxonomies
Fig 3: Merging Drupal taxonomies into WordPress

Since WordPress doesn’t support duplicate category or tag names, another thing to consider is how to handle any duplicate Drupal terms. Normally, the easiest solution is to append a unique number so that you can filter them out post-migration. We can do some clever merging and re-assigning of terms to posts but frankly, it’s probably not worth incurring the extra fees. Unless you have a great number of duplicates, you can probably do the job yourself quite easily via the WordPress Dashboard controls.

Organising your categories and tags in WordPress

Now that we know what’s involved in converting Drupal’s taxonomy over to WordPress, the next obvious question would be, “What’s the best way to structure categories and tags in WordPress?” While I cannot prescribe exactly how you should organise your site, I can point you to this excellent article so you can decide for yourself: Categories vs Tags – SEO Best Practices for Sorting your Content. Generally you should only have a few categories, maybe five or ten in total. Any more and they can become unwieldy and difficult to manage. These categories will reflect the main themes of your site. Tags can then further describe the details of each post and link specific topics together. You can have any number of tags.

The chances are that you probably want to avoid any drastic changes to the site structure when migrating from Drupal to WordPress. A simple mapping of vocabularies to categories and terms to tags is usually the closest equivalent in WordPress.

Drupal to WordPress migration activity diagram

This UML activity diagram accompanies my post, Drupal to WordPress migration explained.

Drupal to WordPress migration process activity diagram

Diagram created with draw.io.

Migration steps listing

  1. Prepare tables: This is where we reset the development database tables to a known state, ready for another migration pass.
  2. Delete unwanted vocabularies
  3. Delete unwanted terms
  4. Merge terms? Yes: go to step a; No: go to step 5
    1. Create tables for each vocabulary to merge
    2. Create duplicate table for each vocabulary
    3. Make duplicate terms unique
    4. Merge terms
  5. Create tags
  6. Create categories and sub-categories
  7. Set uncategorized term
  8. Create posts from nodes
  9. Set posts and page types
  10. Associate posts with terms
  11. Update tag counts
  12. Set default category
  13. Migrate comments
  14. Migrate authors
  15. Site-specific settings and customisation: this would include WordPress site information settings and URL redirects

Drupal to WordPress migration: user table mapping

This is part four of a series of posts documenting the table mappings for a site migration from Drupal 6 to WordPress 3. For more information, please see the first article in the series.

Table mapping for WordPress users

This maps Drupal user export to WordPress.

Drupal 6.x

WordPress 3.x

Notes

users

wp_posts

uid

ID

name

user_login

Format to lowercase, replace spaces with underscores

pass

user_pass

name

user_nicename

mail

user_email

created

user_registered

Formatted from UNIX time

name

display_name

user_status

Whitespace string

user_activation_key

Set to 0

Table mapping for WordPress user meta values

User information like capabilities and roles in the wp_usermeta table.

users

wp_usermeta

uid

user_id

meta_key

Set to string e.g. ‘wp_capabilities’

meta_value

Set to string e.g. ‘a:1:{s:6:”author”;s:1:”1″;}’

More information about the settings for appropriate meta_key and meta_value can be found in the WordPress Codex:

Node authors and comment authors

Drupal stores both node authors and comment authors in the users table. WordPress handles things differently. Page and post authors are stored in the wp_users table but comment authors are stored in wp_comments together with the comment data.

Drupal to WordPress migration: comments table mapping

This is part three of a series of posts documenting the table mappings for a site migration from Drupal 6 to WordPress 3. For more information, please see the first article in the series.

Table mapping for WordPress comments

Drupal 6.x

WordPress 3.x

Notes

comments

wp_posts

cid

comment_ID

nid

comment_post_ID

timestamp

comment_date

Converted from UNIX timestamp

comment

comment_content

pid

comment_parent

name

comment_author

mail

comment_author_email

homepage

comment_author_url

Truncated to WordPress limit of 200 chars

status

comment_approved

Comment authors

A note about the different ways Drupal and WordPress store comment author information: Drupal stores comment authors in its users table alongside site users like node authors. In WordPress, comment authors are stored in its wp_comments together with the comment data. WordPress comment authors are not entered into the wp_users table.

Drupal to WordPress migration: terms table mapping

This is part two of a series of posts documenting the table mappings for a site migration from Drupal 6 to WordPress 3. For more information, please see the first article in the series.

Table mapping for WordPress terms

This table mapping exports the Drupal terms into WordPress.

Drupal 6.x

WordPress 3.x

Notes

term_data

wp_terms

tid

term_id

name

name

name

slug

Make lower case and convert spaces to underscores

vid

term_group

Not used in a default WordPress installation

term_data

wp_term_taxonomy

tid

term_taxonomy_id

tid

term_id

taxonomy

String: ‘post_tag’ or ‘category’

description

description

parent

0 (No parent)

In the WordPress Taxonomy documentation, “term_group is a means of grouping together similar terms.” During a standard migration, the WordPress term_group is set to the Drupal vocabulary ID, which seems to make sense. Nevertheless, a default WordPress installation does not actually use the value for anything. It may have been included by the developers for future expandability or use by plugins.

term_group=0 is the default value when creating a term using the Drupal user interface.

Below, we associate posts with the newly migrated terms.

Drupal 6.x

WordPress 3.x

term_node

wp_term_relationships

nid

object_id

tid

term_taxonomy_id