Library

SSH Authentication Changes in Transmit 5.6.4

At Panic we are always balancing security, ease of use and of course fixing bugs. In Transmit 5.6.4 and later we’ve made some changes to improve security while fixing some bugs in Transmit when connecting to an SFTP server. As a result, Transmit will now use key files assocated with a server before passwords saved in Transmit favorites.

What is a key, you ask? It’s a file you can think of as a “super password” that is unique to your computer and the server. Odds are, you set this up on your computer and have completely forgotten about it, that’s why you’re reading this article. Since keys are more secure than passwords, Transmit now favors using them when logging in to your servers.

Due to these changes, it’s possible you may find yourself in a situation where you are prompted for an SSH key passphrase upon connecting to any SFTP server, like so:

SSH Key Passphrase Prompt

Another possibility is that you may get an Authentication Failed error with a miscellaneous error code showing up in the Transcript log.

If you find yourself in this situation, it is likely that you have a key defined for this connection in your SSH config file, whether you meant to or not.

Check your ~/.ssh folder for any errant key files

Open your ~/.ssh folder in Finder. Here’s how:

  1. In Finder’s menubar, select Go to folder from the Go menu.
  2. In the box that appears, enter the following and click Go: ~/.ssh

In this folder, look for any key files that start with id_ such as id_rsa or id_ecdsa. If these key files aren’t being used, delete them or rename them. Otherwise, Transmit will offer these default keys before attempting password authentication. If your server isn’t set up to accept these keys, you may run into connection issues.

Check Your SSH Config File For Accuracy

If you’ve checked for any unnecessary keys, the next thing to check would be your SSH config file.

First, open your config file in a text editor of your choosing. Here’s how:

  1. In Finder’s menubar, select Go to folder from the Go menu.
  2. In the box that appears, enter the following and click Go: ~/.ssh
  3. Right click config and open it in a text editor.

Wildcard (*) configurations in your SSH config are often not ideal as they will offer these keys for every connection. Unless you have the passphrase stored in your keychain, Transmit will prompt for a passphrase in order to use the key for authentication. One common situation would be for Github, as their documentation currently instructs you to configure things this way. Here’s an example of what this would look like in your config file:

Host *
  AddKeysToAgent yes
  UseKeychain yes
  IdentityFile ~/.ssh/id_rsa

The entry above will cause Transmit to prompt you for your SSH Key passphrase with every SFTP connection, as this key is explicitly defined for all addresses due to the wildcard.

Since the config file is used by many different apps (Transmit, Terminal, Coda, Git clients, etc.), this is not an optimal way to define the key in your config file. For the most part, Transmit attempts to match the behavior of SSH on the command line. If you attempt to SSH into the same server on the command line (with a wildcard address in your config file like the example above), you’ll be prompted for the passphrase the same as you would in Transmit.

In an ideal scenario, rather than using a wildcard for the host entry, you would use only the address to which the key actually applies. Using the Github example above as the server in question, that entry in your config file would look like this:

Host github.com
  AddKeysToAgent yes
  UseKeychain yes
  IdentityFile ~/.ssh/id_rsa

In this case, Transmit would only prompt you for your SSH key passphrase when connecting to github.com.

If you were previously using a wildcard entry deliberately to use your key for multiple addresses, you can add those all to the host entry separated by spaces, avoiding the wildcard scenario and still allowing multiple hosts for a single key entry. Here’s one possible example:

Host github.com mysite.com myserver.com
  AddKeysToAgent yes
  UseKeychain yes
  IdentityFile ~/.ssh/id_rsa

Other Solutions

If avoiding a wildcard isn’t an option, you’ll need to manually specify any non-key based connection as requiring password authentication above your wildcard in your config file, like so:

Host mysite.com
  PasswordAuthentication yes
  
Host *
  AddKeysToAgent yes
  UseKeychain yes
  IdentityFile ~/.ssh/id_rsa

The configuration above allows you to keep the wildcard while requiring the server “mysite.com” to stick to password authentication.

TL;DR: Now that Transmit 5.6.4 uses explicitly-defined keys in your config file (just like SSH on the command line) make sure that the Host entry for keys defined in your config file are only for the necessary addresses, not a wildcard.

For more information about how SSH keys work in Transmit or any other Panic app, please see our SSH key documentation.