Regenerate SSH config after virtual machine cloning

Hi,

I’m new to openSUSE but have used other distros in the past fairly extensively.

I’ve built an openSUSE virtual machine image (KVM) that I want to use as a base image with the intention of rapidly “cloning” it over and over. For security reasons I want to regenerate the SSH config and recreate new keys after I clone it into a new machine.

From having previously done exactly this on Ubuntu/Debian machines, I know how to regenerate the SSH config on Debian/Ubuntu:

rm /etc/ssh/ssh_host_*
dpkg-reconfigure openssh-server

Can anyone tell me what the equivalent command to dpkg-reconfigure would be on openSUSE? Or, if there’s another, better way to do it under openSUSE, that’s obviously fine too.

Thanks in advance.

I’m not quite sure what you are looking for.

The initial configuration, on install, consists of sshd_config and ssh_config

In my case, I keep a copy of the original before making any changes. So I could restore to the original.

As far as I know, if you do


# cd /etc/ssh
# rm -f *_key*

that will remove all of the host keys. They should be recreated (with new keys) on the next boot.

nrickert,

Thanks. I think you answered my question. I basically wanted to know how to recreate new keys after deleting the ones originally created. As I mentioned, there’s a command to do so in Debian based distros and that’s why I thought there might be something equivalent in openSUSE. Deleting the keys and rebooting is fine too. I’ll give that a try.

The underlying reason is that if I clone a virtual machine, it will have the exact same server keys as the original machine. Obviously, that’s not good. So, I simply want to delete and create a unique set of ssh server keys on the cloned VM. Sounds like your solution will accomplish exactly that.

Confirmed. Works fine. Thanks again nrickert.

It would be better to go the Linux style way and do an dpkg-reconfigure openssh-server after deleting the keys.
I do not know how to do this with Suse…

I stumbled on to this thread looking for the debian/ubuntu method. I love happy accidents. Just in case it’s useful to someone, we use this in Suse/RHEL:

Generate new SSH host keys.

/sbin/service sshd stop
/bin/rm -f /etc/ssh/ssh_host_*
/usr/bin/ssh-keygen -f /etc/ssh/ssh_host_key -b 2048 -N ‘’ -t rsa1
/usr/bin/ssh-keygen -f /etc/ssh/ssh_host_rsa_key -b 2048 -N ‘’ -t rsa
/usr/bin/ssh-keygen -f /etc/ssh/ssh_host_dsa_key -b 1024 -N ‘’ -t dsa
/sbin/service sshd start

On 2014-08-26 20:06, gbroad1960 wrote:
>
> Kr4bat;2566974 Wrote:
>> It would be better to go the Linux style way and do an dpkg-reconfigure
>> openssh-server after deleting the keys.
>> I do not know how to do this with Suse…
>
> I stumbled on to this thread looking for the debian/ubuntu method. I
> love happy accidents. Just in case it’s useful to someone, we use this
> in Suse/RHEL:
>
> #
> # Generate new SSH host keys.
> #
> /sbin/service sshd stop
> /bin/rm -f /etc/ssh/ssh_host_*
> /usr/bin/ssh-keygen -f /etc/ssh/ssh_host_key -b 2048 -N ‘’ -t rsa1
> /usr/bin/ssh-keygen -f /etc/ssh/ssh_host_rsa_key -b 2048 -N ‘’ -t rsa
> /usr/bin/ssh-keygen -f /etc/ssh/ssh_host_dsa_key -b 1024 -N ‘’ -t dsa
> /sbin/service sshd start

You only need to stop the service, delete the keys, and start the service again. Check the service script, the first thing it does is see if the keys do exist, and if they don’t, they are created. No booting necessary:


start)
if ! grep -q '^:space:]]*HostKey:space:]]' /etc/ssh/sshd_config; then
if ! test -f /etc/ssh/ssh_host_key ; then
echo Generating /etc/ssh/ssh_host_key.
ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_key -N ''
fi
if ! test -f /etc/ssh/ssh_host_dsa_key ; then
echo Generating /etc/ssh/ssh_host_dsa_key.
ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N ''
fi
if ! test -f /etc/ssh/ssh_host_rsa_key ; then
echo Generating /etc/ssh/ssh_host_rsa_key.
ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N ''
fi
if ! test -f /etc/ssh/ssh_host_ecdsa_key ; then
echo Generating /etc/ssh/ssh_host_ecdsa_key.
ssh-keygen -t ecdsa -f /etc/ssh/ssh_host_ecdsa_key -N ''
fi
fi

You can also get from there the files to delete…


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

I just ran a test and verified that simply doing a forced re-install of openssh regenerates the keys.

zypper in -f openssh

One of the cool things about openSUSE (not usually available in other distros) is that when openSSH is installed, the routine to generate keys is automatically invoked. In other distros, typically you have to generate the keys
manually.

The first thing I tried on my own was to simply restart the sshd service and didn’t see the keys regenerate (13.1). I’m pretty sure the keys are generated only during the install procedure and not when the service is simply starting up.

TSU

I’m pretty sure that, after a clean install, there are no keys in “/etc/ssh” until the service is first started.

If the installer finds an older linux on the same disk, it does save a copy of the keys from there, and put into the new install.

They’ll get regenerated if they are missing when you start the sshd - try it :slight_smile:

There’s a “if/test -f/fi” loop in /etc/init.d/sshd that checks for the existence of the keys, if they are missing, it re-creates them with ssh-keygen.

On 2014-08-29 20:16, Miuku wrote:
>
> tsu2;2661923 Wrote:
>> I’m pretty sure the keys are generated only during the install procedure
>> and not when the service is simply starting up.
> They’ll get regenerated if they are missing when you start the sshd -
> try it :slight_smile:
>
> There’s a “if/test -f/fi” loop in /etc/init.d/sshd that checks for the
> existence of the keys, if they are missing, it re-creates them with
> ssh-keygen.

Gosh, I posted the code here two days ago :wink:


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

You guys are right!
Seems you have to remove the keys altogether to regenerate.
I re-did the test <removing altogether> the keys and the regeneration ran.

Before,
I simply renamed them leaving them in the same directory which apparently is not enough to regenerate with a sshd restart…
But as I described that scenario was fixable by simply force re-installing.

TSU