Generating SSH the key files

There are different types of key files, so the first step is going to be to determine what kind of key file to make. The key things here to decide are the key encryption method and the format of the key file. There are different kinds of keys, and there are some key conversion options, but ultimately each piece of SSH software will only support keys if they are in a recognized format. Knowing what software will be used may help to determine an appropriate format.

Determining the key type

One task, which should be done before trying to actually create the key, is to decide what kind of encryption the key file is going to be using.

The current recommendation is no longer DSA (DSS) keys. RSA may be the most current recommendation provided at certificate key types. (However, that recommendation may change, perhaps rather soon, as noted in the section about “certificate key types”. When finding yourself making keys in the future, you may wish to consider using something newer than RSA.)

Determine a key length

At the time of this writing (in the year 2015), the most common answer was “2048”. Larger numbers create keys that are considered to be “stronger”, but might reduce compatibility with some software that doesn't support certain numbers.

Pick a system

Choose a secure, trusted system/computer/device.

Ideally, this chosen machine is a client, not the SSH server which will be storing the public key file long term. (This is not a big deal if the SSH server is the only system convenient to generate these keys, but if multiple are available to choose from, choosing another is preferred.)

Bad SSL key generators

There are two classifications of questionable, or certainly bad, SSL key generators that are worth mentioning: an old issue that was related to Debian, and commercial software. Details are at: generators of bad SSL key files.

An issue that affected any Unix (and similar) platforms

Note to users of old Debian systems: there is a vulnerability which became quite famous, so before generating keys, make sure that the SSL implementation (“package”) used is not the Debian release of OpenSSL 0.9.8c-1 up through 0.98g-9 (as these are the versions identified by CVE-2008-0166). In general, this means not using any Debian version from September 2006 through May 13, 2008, nor any operating system based on such Debian releases such as older versions of Ubuntu (namely Ubuntu 7.x and 8.04 LTS, as noted by Ubuntu advisory) or operating systems based off of such older versions of Ubuntu.

If the system does use that a Debian system within this range, note the likely problem: Debian security advisory documents the issue. Essentially the problem is that a random number has an upper range of 32,768 (and usually 3,000 or less, according to a page with code, keys, and related comics, as noted by Wayback Machine @'s archive of page with code, keys, and related comics). (The first comic on that page uses a black and write version of the (colored) October 25, 2001 Dilbert comic from presentation of October 25, 2001. Note that in the colorized version, the creature in the far right panel should probably be brown... The other comic comes from XKCD comic 221: Randomization.)

It is generally recommended that any keys which were created from affected systems (and so which are probably old keys) should be replaced with keys created by a non-affected system. So, therefore, it is probably not a good idea of create such keys. If using an software based on this old code, update the code before making the keys. Or, probably a less ideal situation, simply make the keys on a different computer that is using other software.

Using keys made from commercial software

OpenSSH FAQ 2.6: “What are these warning messages about key lengths” documents a bug in commercial software which created keys that “were advertised as being full-length, but are actually, half the time, smaller than advertised.” Apparently this issue was effectively detectable because OpenSSH can print out a warning when it knows (or just believes?) that such a key has been used.

PuTTYGen (for Microsoft Windows)
Users of Microsoft Windows may want to use PuTTYGen. Users of Unix may also use that, but may find that the OpenSSH software is better, due to being more likely to being pre-installed and possibly using stronger entropy. (PuTTYGen simply gathers entropy from some mouse movement. As OpenSSH is widely considered a prestine example of excellent security, hopefully it uses better entropy than that.)

Now that those recommendations are provided, here's some details on how to use the software.

Generating the key files with the OpenSSH software suite

On the chosen system, run the following command which will generate three files.

ssh-keygen -t rsa -o -vvv -f mykey -N "" | tee mykey.fng

The “ -N ""” specifies an empty key. That may not be the absolutely most secure method of creating keys, although it does simplify this for usage with this guide. This method is actually used by OpenBSD's /etc/rc file (except that the /etc/rc uses apostraphes rather than quotation marks).

The -o parameter

This attempts to add a bit of security by using an OpenSSH format which is not PEM-based. This does break compatibility with some software, including OpenSSH versions prior to version 6.5


An alternative syntax is:

ssh-keygen -t rsa -vvv -f mykey -N "" -C "optionalComment" | tee mykey.fng


ssh-keygen -t rsa -vvv -f mykey -N "" -C "mykey" | tee mykey.fng

After creating the files, the recommended action is to make sure that the public key file contains the filename as part of the optional comment at the end of the file. First, though, let's look at that's been done so far.

Created files

The ssh-keygen command creates two files and sends output which the tee command uses to generate a third file. An example of the output from ssh-keygen is as follows:

Generating public/private rsa key pair.
Your identification has been saved in mykey.
Your public key has been saved in
The key fingerprint is:
01:23:45:67:89:ab:cd:ef:fe:dc:ba:98:76:54:32:01 myusrnam@myhostname.mydomain
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|=*E              |
| S+.o+.          |
|  o.O..=         |
|                 |
|                 |
|                 |
|                 |
|                 |

Information, for the curious, about what is displayed: The “randomart” image is meant to be a visual representation so a key alteration may be more easily spotted by a human if the randomart is displayed regularly. The randomart images tend to always touch at least one of the borders, and (perhaps one or two, but) not all three of the other borders, and favor periods and lowercase letter o characters and spaces. The randomart image may be viewed again by running “ ssh-keygen -lvf ” (specifying the actual public key file as needed). That same command shows the critical details of the .fng file (which is created by the example command line above, specifically by using tee on the output of ssh-keygen when the key was made). Therefore, the *.fng file does not need to be made and serves little to no purpose as long as ssh-keygen is readily available: The main reason for creating it is in case ssh-keygen is not available (and for convenience, so the syntax of using “ -lvf”, does not need to be looked up if that syntax isn't yet memorized).

The private key file made does not have an extension by default.

Private key file

The private key file may look something like this:

Subject: username
Comment: Comment line no longer than 72 characters
Comment: This is a comment line.  Every single line in this type of file
Comment: must remain under 73 characters long.  So, the longest possible
Comment: length for the comment portion of a line is 63 characters long.
Comment: (The remaining characters are used up by the text "Comment: ".)
Comment: All lines that start with Subject and a colon, or Comment and a
Comment: colon, are part of a header which must not have a length longer
Comment: than one thousand and twenty four characters (approximately two
Comment: times this example's pre-URL text.)

In theory, the line that starts with “Subject: ” will show the username that created the key. In reality, the private key files may often/usually be created without such a subject line, and without any lines that start with a “Comment: ” header.

Note, if you're trying to add a comment, consider adding comments below other text. For example, if you have a key that looks roughly like this:

Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,...

Then add the comment as shown here:
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,...
Comment: CustomComment


(Trying to put the comment above the Proc-Type line may cause software to not successfully use the key in the desired way. Basically, the key will appear to not work, similar to if a passphrase is mistyped.)

new openssh key format and bcrypt pbkdf discusses an enhancement made to the format.

Public key file

An example/demonstration of an OpenSSH public key file is available.

OpenSSH Fingerprint Output sample

An example/demonstration of an OpenSSH Fingerprint Output sample is available.

[#pbkycmnt]: Recommended further modification: public key file's comment

Recommended further modification: public key file's comment seemed like such a good idea, that the discussion was moved to a separate section that could be easily hyperlinked from multiple locations. Check it out!

Generating the key files with PuTTYGen (for Microsoft Windows)

Use PuTTYGen, obtainable from PuTTY download page. Choose the parameters, such as the key encryption type (e.g., “SSH-2 RSA”) and the key length. Select (click on) the Generate button. (Plan to move a rodent in order to generate entropy.) The private key will then be generated in memory.

Once PuTTYGen has a private key to work with, PuTTYGen will then allow saving a public key and saving a *.ppk private key. The public key can be re-generated later from the private key, so saving the private key is the more important key to keep a copy of.

[#iosshmky]: Generating keys from within IOS

Note: this guide is meant for people who are familiar with interacting with the Cisco IOS. Details are described by the standard Cisco IOS warning (which also provides references to additional resources for those who might not have that familiarity yet).

The following information does not show how to use an existing key, but does show how to create a new key. This does not show how to view the key (or access it in a way that allows you to easily copy it to another machine), or to view the key's fingerprint.


Not all IOS images support cryptography. If you find that the crypto command does not exist, and you cannot run “no ip http secure-server” because “secure-server” is not recognized, maybe your IOS image simply doesn't support cryptography. (In that case, applying a software change, to use an IOS boot image that does support cyrptography, maybe required.)

Customize names

Determine a domain name. (In other words: make one up.) For some reason, that seems to be required.

Router> enable
Router# conf terminal
Router(config)# crypto key generate rsa
% Please define a hostname other than Router.
Router(config)# hostname deviceName
deviceName(config)# crypto key generate rsa
% Please define a domain name first.
deviceName(config)# ip domain name
deviceName(config)# show running-config | inc name
Making the key
Router> enable
Router# conf terminal
Router(config)# crypto key generate rsa modulus 2048 exportable
The name for the keys will be:

The above example shows creating a 2,048 bit key. Specifying the key size on the command line is optional. (And, even if you do specify the key size, it appears that the word “modulus” may also be optional.) If the modulus is not specified, then the user will be asked:

Chosoe the size of the key modulus in the range of 360 to 2048 for your
General Purpose Keys. Choosing a key modulus greater than 512 may take
a few minutes.

How many bits in the modulus [512]: 2048

Some documentation has stated that SSH version 2 will require that keys use a modulus of at least 1024 bits. In practice, it was found that creating a key that was 512 bits could be possible but insufficient, as SSH may require more bits (but would work fine with a 768-bit key).

The maximum bit length seems to vary between different devices (or IOS versions). For example, Cisco documentation: generating RSA keys shows a maximum of 4096 being used. A larger modulus is considered to be more secure, and is recommended when it can be supported by the devices that need to use it. The biggets substantial downside to using a large modulus may just be that the key takes longer to be created. However, after that one-time cost of creating the key, the result is more secure. So, for any non-test non-sample non-demonstration use, where data actually ought to be protected, aim high. Go big.

The following shows some example output if the word “ exportable” was not used.

% Generating 2048 bit RSA keys, keys will be non exportable...[OK]

(That generated a key.)

At this point, the device can start services that rely on the key. (Presumably there ought to be a way to extract the key too: information in the section on file handling in Cisco IOS may be useful.)

Router# show crypto key mypubkey rsa

Shows RSA keys. (Is “mypubkey” meant to be customized somehow? Maybe try “show crypto key ?”. This command was found mentioned at: Cisco documentation: generating RSA keys.

Some actions may delete keys. For instance, keys will be deleted during a password recovery process (as noted by Ciscio IOS documentation: Deploying keys. The same web page notes that older IOS versions might not be compatible with some keys (which are encrypted). The way to prevent that from being a problem, other than the option of not performing actions like requiring the password recovery process, seems to be exporting the keys to a PEM file, and then back up the PEM file to a location where it remains safely available (but still private). Then the keys can be re-imported later, if desired. (further details needed...)