I've found that ssh-keygen ("ssh" package) produces different keys from puttygen ("putty" package).

If I create public and private keys with ssh-keygen some SSH servers will not accept my keys. If I create keys with puttygen only one server does accept it.

Why don't Linux repositories propose some common solution (package) for it?

I've found another package ssh- which creates keys that work with PuTTY. But why isn't there any handy solution in SSH?

  • 1
    For starters PuTTYGen offers explicitly to convert keys. So the native formats which OpenSSH and PuTTY use to store keys are different. However, the supported algorithms are compatible. A guess I'd have is that you entered some funky value in the field that allows you to give the number of bits (e.g. DSA seems to require 1024 bit) for the generated key in PuTTYGen or alternatively that you picked something like RSA-1 which most servers will have disabled these days. Unfortunately the question doesn't really state what you tried and expected. Commented May 17, 2016 at 12:16

3 Answers 3


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- 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.

  • 2
    Something being widespread or dominant does not mean it is good.
    – foo
    Commented May 29, 2020 at 9:19
  • 8
    Something being proprietary and obscure does not mean it is better. - bar :-) Commented Feb 24, 2021 at 1:42

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.

  • Do you mean my Linux have obsolete and vulnerable SSH-1 (if I don't use putty)? And is it affordable? Vulnerabilities of SSH-1 are described in wikipedia
    – YarLinux
    Commented May 3, 2013 at 16:28
  • Not sure where you got that. No you should be fine. What version of Linux are you using? What Linux Distro are you using? Run this command to find out your Linux version: uname -a. Linux distro: lsb_release -a.
    – slm
    Commented May 3, 2013 at 16:33
  • I use Ubuntu 12.04. Do you mean SSH-2 has different formats? I just confused by name of package and command which "ssh".
    – YarLinux
    Commented May 3, 2013 at 16:38
  • I see. The ssh tool you're referring to is usually part of a package called openssh. The version of this software has nothing to do with the SSH-1 and SSH-2 you're referring to. That terminology (SSH-1 & SSH-2) is referring to the type of key file that you're working with. This file type shouldn't be an issue for you as long as you're using recent versions of openssh.
    – slm
    Commented May 3, 2013 at 16:46
  • Are there three different formats of keys? OpenSSH, ssh.com and PuTTY?
    – YarLinux
    Commented May 3, 2013 at 16:58

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]

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .