42

I cloned a server and so they've the same RSA key fingerprint.

It seems to be defined in /etc/ssh/ssh_host_rsa_key.pub.

What is the correct way to change that?

Thanks.

46

Or, remove keys and

ssh-keygen -A

Explanation:

-A: For each of the key types (rsa1, rsa, dsa, ecdsa and ed25519) for which host keys do not exist, generate the host keys with the default key file path, an empty passphrase, default bits for the key type, and default comment. This is used by /etc/rc to generate new host keys.

3
  • The OP's tags specify debian, but being non platform specific, this answer seems like the better solution.
    – mc0e
    Oct 31 '14 at 14:00
  • Hmm, except it doesn't seem to work for older versions. Eg fails on debian squeeze, which has OpenSSH_5.5p1
    – mc0e
    Oct 31 '14 at 14:39
  • 1
    For your information (from manpagez.com/man/1/ssh-keygen) ssh-keygen -Adoes the following: "For each of the key types (rsa1, rsa, dsa, ecdsa and ed25519) for which host keys do not exist, generate the host keys with the default key file path, an empty passphrase, default bits for the key type, and default comment. This is used by /etc/rc to generate new host keys." Feb 10 '15 at 20:42
33

Follow these steps to regenerate OpenSSH Host Keys

  1. Delete old ssh host keys: rm /etc/ssh/ssh_host_*
  2. Reconfigure OpenSSH Server: dpkg-reconfigure openssh-server
  3. Update all ssh client(s) ~/.ssh/known_hosts files

Reference

17

For a generic method of doing this:

ssh-keygen -q -N "" -t dsa -f /etc/ssh/ssh_host_dsa_key

ssh-keygen -q -N "" -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key

ssh-keygen -q -N "" -t ecdsa -f /etc/ssh/ssh_host_ecdsa_key

ssh-keygen -q -N "" -t ed25519 -f /etc/ssh/ssh_host_ed25519_key

mix and match according to the keys your version of OpenSSH supports. Current implementations commonly generate only rsa, ecdsa & ed25519.

Do note that that the -b argument can be used in (most) cases to specify key size.

You should pick a key-size appropriate for the intended lifetime of the key and the amount of time you find acceptable to open a connection as the impact will be more pronounced on slower hardware. For example, using the default RSA key size (2048 at the time of writing) is absolutely fine (again, as of the time of writing) if you're rolling the key over periodically.

4
  • 1
    I think one way to improve this question would be to add the way to increase the number of bits. i.e. ssh-keygen -q -N "" -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key
    – Whitecat
    Apr 7 '16 at 17:18
  • ecdsa default is 256. Use ssh-keygen -q -N "" -t ecdsa -b 521 -f /etc/ssh/ssh_host_ecdsa_key to get the biggest key. Yes 521 not 512.
    – user136036
    Mar 14 '20 at 22:17
  • I've updated the answer. Using larger keys is not free. You are usually better off rolling keys over periodically rather than simply picking the largest size possible and paying the computation costs since, even a 2048bit RSA key is best attacked by trying to obtain it rather than trying to factorise it.
    – Olipro
    Jan 14 at 9:25
  • Best answer for repairing remote server like centos 6x via anaconda
    – Quake1TF
    Apr 14 at 14:14
3

If you are using RHEL, CentOS or Fedora, then you can simply delete them and restart the SSHd service. They will be regenerated.

5
  • 3
    No, it doesn't work. /etc/init.d/ssh restart<newline> Could not load host key: /etc/ssh/ssh_host_rsa_key<newline> Could not load host key: /etc/ssh/ssh_host_dsa_key<newline> [....] Restarting OpenBSD Secure Shell server: sshdCould not load host key: /etc/ssh/ssh_host_rsa_key<newline> Could not load host key: /etc/ssh/ssh_host_dsa_key Jan 22 '13 at 10:34
  • 1
    Indeed. Only works on RHEL based distribs. Sorry Jan 22 '13 at 10:45
  • Good advice, thanks. It worked for me on CentOS installation. Apr 25 '16 at 20:17
  • Definitely works on Fedora Aug 12 '16 at 8:46
  • FYI, this approach works on Alpine Linux v 3.13.2 What I did was rm /etc/ssh/ssh_host_* then reboot. I bet you could just bounce the ssh service, but I didn't try that.
    – Granger
    Feb 24 at 23:12
1

Script (in case restarting the sshd daemon does not automatically regenerate the keys)

#!/bin/bash

# Regenerate SSHD key materials, restart sshd if "-r" passed on command line

set -o nounset

WHERE=/etc/ssh

# go to directory

pushd $WHERE >/dev/null

if [[ $? != 0 ]]; then
   echo "Could not cd to $WHERE -- exiting" >&2
   exit 1
fi

# create backup folder

NOW=`date '+%Y%m%d.%H%M%S'` # default NOW string
BAKDIR=bak_$NOW

mkdir $BAKDIR

if [[ $? != 0 ]]; then
   echo "Could not mkdir $BAKDIR -- exiting" >&2
   exit 1
fi

# move existing key material to backup folder

mv ssh_host_* $BAKDIR

if [[ $? != 0 ]]; then
   echo "Could not move old files to $BAKDIR -- exiting" >&2
   exit 1
fi

# generate new keys

ssh-keygen -A

if [[ $? != 0 ]]; then
   echo "Could not recreate keys -- exiting" >&2
   exit 1
fi

# ssh-keygen may create DSA keys but:
# "Never use DSA or ECDSA"
# http://security.stackexchange.com/questions/5096/rsa-vs-dsa-for-ssh-authentication-keys

/bin/rm -f *_dsa_key *_dsa_key.pub
/bin/rm -f *_ecdsa_key *_ecdsa_key.pub

# on Fedora, one has to tune permissions a bit

chmod 640 *_key
chgrp ssh_keys *_key

# make sure SELinux attributes are as they should be

restorecon -R $WHERE

# Done

echo "New key material"
ls -l *_key *_key.pub

# Do the risky thing

if [[ $1 == '-r' ]]; then
   echo "Restarting SSH daemon"
   systemctl restart sshd
fi

# go back to where you where

popd >/dev/null
3
  • The link in your comment does not say that ECDSA should not be used. Mar 19 '19 at 13:17
  • 1
    @ToddWalton Actually it does. Third answer in sequence: "- Never use DSA or ECDSA. - Ed25519 is probably the strongest mathematically (and also the fastest), but not yet widely supported. As a bonus, it has stronger encryption (password-protection) of the private key by default than other key types. - RSA is the best bet if you can't use Ed25519." Mar 20 '19 at 22:12
  • Ah, you're right. I see it now. Mar 22 '19 at 13:13
1

Debian 10.7 user here. Mixing the two best answer was the cleanest way to solde the problem :

( As root or sudo it yourself )

  • server A.B.C.D : Mooving old keys in a "backup" folder

    mkdir -p ~/ssh_backup && mv /etc/ssh/ssh_host_* ~/ssh_backup/.

  • server A.B.C.D : Generate new keys :

    ssh-keygen -A

  • CLIENT SIDE : forger about the previous key for server A.B.C.D

    ssh-keygen -R A.B.C.D

Here you go, the fresh ssh keys can be used.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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