Converting Putty Keys to OpenSSH

Useful for using existing keys generated by PuTTYgen under OpenSSH inside a WSL guest.

Load the private key in PuTTYgen on Windows.
Export to OpenSSH format in PuTTYgen using Conversions > Export OpenSSH Key.
Generate a public key from the private key using ssh-keygen (which is available on both Windows and Linux). Not sure how the Windows version got installed on my machine (C:/Windows/System32/OpenSSH) — maybe as a result of installing WSL.
```
ssh-keygen -e -f exported_key > tmp_exported_key.pub
```
The generated public key is not compatible with OpenSSH, so convert it using:
```
ssh-keygen -i -f tmp_exported_key.pub > exported_key.pub
```
Drop both the exported private and public keys in ~/.ssh on Linux.
Fix the permissions to make the keys readable by user only:
```
chmod 600 exported_key*
```

Keychain

Keychain is a handy wrapper for ssh-agent and ssh-add that creates a long-running ssh-agent so that you don't need to keep entering the passwords for your keys. This can also be useful for allowing scripts and cron jobs to use your keys without needing to hard-code passwords.

On first run, keychain will start the ssh-agent, and generate some shell scripts in ~/.keychain that can be sourced to create the appropriate environment variables needed to interact with the agent. To run the scripts you can use:

eval `keychain --eval`

This can be added to your shell RC file if desired.

You can then add a key to the keychain using:

keychain ~/.ssh/<key>

These two operations can be combined:

eval `keychain --eval ~/.ssh/<key>`

Subsequent SSH operations should use the key for authentication (assuming the server is set up for public key authentication).

Connection Multiplexing

You can configure an OpenSSH client to multiplex subsequent connections through an existing connection without needing to authenticate again. Good for small stuff. Not so good for having many concurrent clients all transferring lots of data — don't multiplex in that case.

Add the following to the ~/.ssh/config file on the client side:

Host *
        ControlMaster auto
        ControlPath ~/.ssh/master-%r@%h_%p

That is it. The first connection must be authenticated, but subsequent connections including scp/sftp operations will piggy-back off the existing connection and don't need to be separately authenticated.