What is the difference between an OpenSSH key and PuTTY key?

OpenSSH is the de facto standard implementation of the SSH protocol. If PuTTY and OpenSSH differ, PuTTY is the one that's incompatible.

If you generate a key with OpenSSH using ssh-keygen with the default options, it will work with virtually every server out there. A server that doesn't accept such a key would be antique, using a different implementation of SSH, or configured in a weird restrictive way. Keys of a non-default type may not be supported on some servers. In particular, ECDSA keys make session establishment very slightly faster, but they are only supported by recent versions of OpenSSH.

PuTTY uses a different key file format. It comes with tools to convert between its own .ppk format and the format of OpenSSH.

This ssh-3.2.9.1 you found is a commercial product which has its own different private key format. There isn't any reason to use it instead of OpenSSH. It can only be less compatible, it requires paying, and there's about zero tutorials on how to use it out there.

Most Linux distributions have PuTTY (package name putty) available for Linux. You could install PuTTY on the Linux side and use puttygen to convert the .ppk files to the regular ssh style key files (called PEM files - even though they don't get a .pem in the file name).

puttygen id_dsa.ppk -O private-openssh -o id_dsa

NOTE: You can also use puttygen to import ssh style PEM files back into PuTTY.

PuTTY's author opted for simplicity, so the public and private keys, which make up the underlying security used by PuTTY/SSH-2 key authentication, are stored in a single proprietary .ppk file. Typically these keys are maintained as two separate files by ssh.

On Linux the key files are typically kept in the directory .ssh.

There is a good overview of the conversion process here in this Stack Overflow question titled: Convert PEM to PPK file format.

The author of PuTTY also discusses his rationale for using .ppk files in the PuTTY users manual. You can read about it here in section 8.2.12.

They both store an "RSA key pair for version 2 of the SSH protocol" and can be converted interchangeably; however, regarding the actual stored format difference:

from https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/key-formats-natively.html

The advantages of the PuTTY key format are:

• Public half of key is stored in plaintext. OpenSSH's private key format encrypts the entire key file, so that the client has to ask you for your passphrase before it can do anything with the key at all. In particular, this means it has to ask for your passphrase before it can even offer the public key to the server for authentication. PuTTY's format stores the public key in plaintext and only encrypts the private half, which means that it can automatically send the public key to the server and determine whether the server is willing to accept authentications with that key, and it will only ever ask for a passphrase if it really needs to.
  
  I think OpenSSH will read a .pub file for this purpose if it appears alongside the private key file, but this is a source of confusion as often as convenience (I've seen people replace a private key file and leave an out-of-date .pub alongside it, and then be very confused by the resulting SSH authentication process!).
• Key is fully tamperproofed. Key formats which store the public key in plaintext can be vulnerable to a tampering attack, in which the public half of the key is modified in such a way that signatures made with the doctored key leak information about the private half. For this reason, PuTTY's key format contains a MAC (Message Authentication Code), keyed off the passphrase, and covering the public and private halves of the key. Thus, we provide the convenience of having the public key available in plaintext but we also instantly detect any attempt at a tampering attack, giving a combination of security and convenience which I do not believe is found in any other key format. As a side benefit, the MAC also covers the key's comment, preventing any possible mischief that might be possible if someone were to swap two keys and interchange the comments.
  
  OpenSSH's approach of keeping the public key encrypted might also provide some security against this type of attack, but it's unclear that it provides proper protection: encryption designed for confidentiality often leaves ways in which the encrypted data can be usefully modified by an attacker. For real integrity protection you want a real dedicated MAC, which is designed to do precisely that.

[emphasis added]