Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I've found ssh-keygen ("ssh" package) comand produce another keys that puttygen command ("putty" package). If I create public and private keys with ssh-keygen some ssh-servers can not accept my keys. If I create keys with puttygen one server accept it. Why linux repositories don't propose some common solution (package) for it? I've found another package ssh-3.2.9.1 which produce another keys that must work with putty. But why there is no handy solution in SSH?

share|improve this question

3 Answers 3

up vote 13 down vote accepted

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 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's no reason to use it instead of OpenSSH, it can only be less compatible, it requires paying, and there's about zero tutorial on how to use it out there.

share|improve this answer

Most Linux distros have 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 a 2 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.

share|improve this answer
    
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 May 3 '13 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 May 3 '13 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 May 3 '13 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 May 3 '13 at 16:46
    
Are there three different formats of keys? OpenSSH, ssh.com and PuTTY? –  YarLinux May 3 '13 at 16:58

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

from http://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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.