• Increase font size
  • Default font size
  • Decrease font size
Home Linux Linux Network Public How to regenerate a SSH Key

How to regenerate a SSH Key

Envoyer Imprimer PDF

OpenSSH require different keys depending if you use SSH1 and/or SSH2 protocol. All keys are generated by ssh-keygen, that one should be available on your system with the ssh package. The receipt is almost the same as for generating your own keys, except that you should use an empty passphrase. Default key lengths are also appropriate (2048 bits for rsa and 1024 bits for dsa)

Generating Keys

Generating public keys for authentication is the basic and most often used feature of ssh-keygen. ssh-keygen can generate both RSA and DSA keys. RSA keys have a minimum key length of 768 bits and the default length is 2048. When generating new RSA keys you should use at least 2048 bits of key length unless you really have a good reason for using a shorter and less secure key. The key length for DSA is always 1024 bits as specified in FIPS 186-2. Because DSA key length is limited to 1024, and RSA key length isn’t limited, so one can generate much stronger RSA keys than DSA keys, I prefer using RSA over DSA. Another reason for not using DSA is that DSA is a government standard and one may wonder if the key length was limited deliberately so it will be possible for government agencies to decrypt it.

To generate a pair of public and private keys execute the following command:
ssh-keygen -t rsa -b 2048

You can use “dsa” instead of the “rsa” after the -t to generate a DSA key. The number after the -b specifies the key length in bits.

After executing the command it may take some time to generate the keys (as the program waits for enough entropy to be gathered to generate random numbers). When the key generation is done you would be prompted to enter a filename in which the key will be saved. The public key will have the same filename but it will end with .pub. You should make sure that the key can only be read by you and not by any other user for security reasons.

Next you’ll be prompted to enter a passphrase. Each generated key can be protected by a passphrase. When a key is generated with a passphrase, the key can’t be used without the passphrase, so by using a passphrase one can prevent others from using his private keys without first guessing the passphrase. A good passphrase should be at least 10 characters long. One should stay away from English sentences as their entropy level is just too low to be used as a safe passphrase. I usually use a randomly generated passphrase, as this kind is considered the most secure. If you intend to use the key for accessing a remote machine from inside an automated script you may wish to enter an empty password, so the script won’t need user interaction. In this case just press <ENTER> twice.
If you create a passphrase-less key just make sure you only put it on trusted hosts as it may compromise the remote machine if the key falls to the wrong hands.

After entering you passphrase twice the program will print the key fingerprint, which is some kind of hashing used to distinguish different keys, followed by the default key comment (more on key comments later). After printing the key information the program will terminate. Congratulations, you’ve just created you own public key using ssh-keygen.


Adding comments to keys can allow you to organize your keys more easily. The comments are stored in end of the public key file and can be viewed in clear text. For example:

cat ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAyyA8wePstPC69PeuHFtOwyTecByonsHFAjHbVnZ+h0dpomvLZxUtbknNj3+c7MPYKqKBOx9gUKV/diR/mIDqsb405MlrI1kmNR9zbFGYAAwIH/Gxt0Lv5ffwaqsz7cECHBbMojQGEz3IH3twEvDfF6cu5p00QfP0MSmEi/eB+W+h30NGdqLJCziLDlp409jAfXbQm/4Yx7apLvEmkaYSrb5f/pfvYv1FEV1tS8/J7DgdHUAWo6gyGUUSZJgsyHcuJT7v9Tf0xwiFWOWL9WsWXa9fCKqTeYnYJhHlqfinZRnT/+jkz0OZ7YmXo6j4Hyms3RCOqenIX1W6gnIn+eQIkw== This is the key's comment

As you can see the comment is appended in clear text to the end of the public key file. To alter the comment just edit the public key file with a plain text editor such as nano or vim.
To add a comment to the public key file when generating the key add to the key generation command -C "you comment". For example to generate 2048 bit RSA key with “home machine” as a comment you will do the following:

ssh-keygen -b 4048 -t rsa -C "home machine"

Notice that each copy of a public key can have its own comment and you cannot retrieve the comment from the private key.


Passphrases allow you to prevent unauthorized usage of your key by meaning of protecting the key itself by a password. Although your ssh directory holding the private keys should be unaccessible to other users, the root user of the system, or anyone who can achieve is privileges can access your key and copy it. In this case the passphrase will prevent him from using it.

To add a passphrase to a key just type it when prompted during the key generation process. Keep in mind that the password must be at least 5 characters long. A good passphrase, as I said before, should be at least 10 characters long, and consist of random upper and lower case letters, numbers and symbols.

While the passphrase boosts the security of the key, under some conditions you may want to leave it empty. Leaving the passphrase empty allows you to use the key from within scripts, for example to transfer a file via scp. While passphraseless keys are very useful for scripts just remember to only use them at trusted machines.

You can change the passphrase of key after it’s been created, and you should do it at least annually. To change the passphrase execute:

ssh-keygen -p

After this you will be prompted to enter the location of your private key and enter twice the new passphrase. If you don’t want a passphrase just enter empty one.

SSH1 protocol

For SSH1 protocol, you need a rsa1 key generated has follow:

ssh-keygen -q -f /etc/ssh/ssh_host_key -N '' -t rsa1

SSH2 protocol

For SSH2 protocol, you need two keys, one rsa key and one dsa key generated has follow:

ssh-keygen -f /etc/ssh/ssh_host_rsa_key -N '' -t rsa
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -N '' -t dsa

Note: Administrators that have other users connecting to their sshd2 daemon should notify the users of the host-key change. If you do not, the users will receive a warning the next time they connect, because the host key the users have saved on their disk for your server does not match the host key now being provided by your sshd2 daemon. The users may not know how to respond to this error. You can run the following to generate a fingerprint for your new public host key which you can provide to your users via some unalterable method (such as digitally signed email):

ssh-keygen2 -F

When the users connect and receive the error message about the host key having changed, they can compare the fingerprint of the new key with the fingerprint you have provided in your email, and ensure that they are connecting to the correct sshd2 daemon. Inform your users to notify you if the fingerprints do not match, or if they receive a message about a host-key change and do not receive a corresponding message from you notifying them of the change.

This procedure can help ensure that you do not become a victim of a man-in-the-middle attack, as your users will notify you if the host-key fingerprints do not match. You will also be aware if the users encounter host-key change messages when you have not regenerated your host key pair.

It is also possible to send the public host key to the users via an unalterable method. The users can save the key to the ~/.ssh2/hostkeys directory as In this case, manual fingerprint check is not needed

Mise à jour le Mardi, 03 Novembre 2009 13:46  




«  juillet 2015  »


Le Bluetooth 3.0 dévoilé

L'essentiel de cette nouvelle norme passe par de profondes améliorations logicielles plutôt que par du nouveau matériel. En effet, la norme 3.0 va non seulement utiliser le matériel Bluetooth que l'on trouve déjà dans la norme 2.1, mais va aussi pouvoir accéder aux puces Wi-Fi des ordinateurs et appareils mobiles