i had to reinstall a SLES 11 SP2 server. In the setup, i chosed “new installation”, and in the partitions dialog, i chosed the old partitions and the same mounting, but also reformatting of the partitions. After the installation has gone through, i had the same ssh host keys than before the installation ! I tried it three times (because i couldn’t believe it), always the old keys.
Is there a hidden feature in the setup that keeps the old host keys ? When i chose “new installation” and “formatting”, i expect that everything is wiped and no old files from the old installation are kept.
I believe to have seen something similar, too - the files were wiped, so I assumed the generation algorithm isn’t truly random… But that’s just an assumption, I didn’t take the lengths to actually verify that.
i can’t imagine that. 3 times the same key. The algorithm would be ridiculous. The 4. time i wiped the harddisk completely using dd=/dev/hdx of=/dev/zero before starting the setup. After that i got a new key. For me that’s a sign that in the former cases the key is saved before partitioning and formatting with yast.
I agree with both statements - the algorithm would have been sub-optimum and the wipe test proves your point. Now the only question remains: Why/where is the key saved when we select to create new file systems. I guess I’ll have to look into this further.
Anyhow, thanks for testing by wiping the disk… that made clear the key generation algorithm is ok, which puts my mind at ease
I, too, have seen this with a Novell Access Manager appliance that I built
a couple of times (first time failed because I was dumb and gave the
system too little RAM and second time worked). At the time I noticed it
because SSHing into the new system didn’t complain about keys changing, or
even prompt me to accept a new key, and that’s something I always need to
do with a new box (of course), especially when reusing an IP address for a
new box and causing a different key to be presented (warning on
man-in-the-middle potential attack).
I also considered the possibility that the VM starting and using the
appliance install might, possibly, be generating the same key at random;
that has been a documented problem with virtual systems, and particularly
with appliances, in controlled environments where the system-creation
steps can be close enough (because the systems are identical, and the
environments are essentially identical, and “random” is often started with
entropy saved to disk from the previous time the box was turned off)
between appliances. If “random” means start with a seed and hen go from
there, and that seed is stored as can be done, and then that system is
started twice in identical situations, the outcome will randomly be
calculated to the same value for more than one system. Google for
relevant articles.
In the end, remembering that and hearing about this, my guess is that the
installer is really smart and is actually trying to help you by copying
the keys before it wipes things. This could be a nice use little help for
these types of situations where the SSH keys are going to be re-generated
and reusing existing keys is easy and relatively safe, or at least much
easier than finding new keys, updating all clients with those keys, and
removing old keys simply because a box is being rebuilt. I would bet this
can happen anytime the installer can read whatever partition held /etc in
the past, so using disk encryption and then NOT entering the key when
reinstalling should also prevent it.
Anyway, thank-you for sharing. If there is a way to verify this in Yast
I’d love to see that so that this is documented.
From /usr/share/YaST2/modules/SystemFilesCopy.ycp:
/**
* Sets new rules which files will be copied during installation.
*
* @see FATE #305019: configure the files to copy from a previous installation
* @param list <map> of new definitions
*
* @struct
* [
* "copy_to_dir" : (string) "system_directory_to_copy_to",
* "mandatory_files" : (list <string>) [ list of mandatory files ],
* "optional_files" : (list <string>) [ list of optional files ],
* ]
*
* @example
* SetCopySystemFiles ([
* $["copy_to_dir":"/root/backup", "mandatory_files":["/etc/passwd", "/etc/shadow"]]
* $["copy_to_dir":"/root/backup", "mandatory_files":["/etc/ssh/ssh_host_dsa_key"], "optional_files":["/etc/ssh/ssh_host_rsa_key.pub"]]
* ])
*/
global void SetCopySystemFiles (list <map> new_copy_files) {
This isn’t the actual invocation, which might be included only in the files of the installation environment (I had only time for a quick check on a readily installed system). But who’d have included that sample invocation if it weren’t used before
I like people like you; so I guess this answers our question. Nice find!
This feature is one I can probably learn to like a lot… I just wish it
was documented better (maybe it is) or maybe an option in the installer to
be overridden (maybe it is).
This isn’t the actual invocation, which might be included only in the
files of the installation environment (I had only time for a quick check
on a readily installed system). But who’d have included that sample
invocation if it weren’t used before ;)[/color]
I noticed before that the SUSE installer keeps passwd and shadow in
memory as found prior to formatting the hard drives. I was not aware of
the very same behavior for ssh keys. This should be clearly offered as an
option during installation rather than something that is done
automatically as it is a potential security problem.
I too would like it to be an option to fix, or at least something
documented on how to change (pretty simple… delete existing keys as I’m
pretty sure SSH’s service auto-regenerates if they are not there), but I
do not see how this is an exploitable security concern. That keys do not
change is not a problem; the problem is when keys can be reproduced on
another machine at will.
On Wed, 27 Mar 2013 18:12:38 +0000, ab wrote:
[color=blue]
I too would like it to be an option to fix, or at least something
documented on how to change (pretty simple… delete existing keys as
I’m pretty sure SSH’s service auto-regenerates if they are not there),
but I do not see how this is an exploitable security concern. That keys
do not change is not a problem; the problem is when keys can be
reproduced on another machine at will.[/color]
This will be, of course, much worse. But when doing a fresh install from
a newly formatted drive it might come as an unwanted surprise to find the
old keys still in place. Think of a system that has been wiped after a
security incident and where the integrity of the private ssh keys is
questionable.
This will be, of course, much worse. But when doing a fresh install from[color=blue]
a newly formatted drive it might come as an unwanted surprise to find the
old keys still in place. Think of a system that has been wiped after a
security incident and where the integrity of the private ssh keys is
questionable.[/color]
If the drive was already wiped the keys won’t be there. Do you mean the
drive was not already wiped but would be wiped during the install? I
agree, you would not want anything left behind after any kind of “security
event”, though that seems like a corner case that may not justify work to
create an entirely new dialog in the installer (requiring testing) to not
pull in these values. Sounds like there would also be need for preventing
other files at the same time in those cases. For that reason documenting
the feature, and how to overcome it, would be a nice simple solution.
On the other hand, maybe all of these pulled-in bits of information could
be managed from a single new section in the installer. It could default
to how things are now and then provide a way to tell the installer to
forget the old system entirely.
For others following along, I’d bet a lot that this can be overcome in a
few situations:
Disk encryption. Yast will prompt you for the passphrase to reuse
encryption, but do not specify the old one and old data should be lost.
DBAN (Derek’s Boot And Nuke) media. Start it and let it run for a few
seconds and that should be enough if it starts at the beginning of the
disk drive.
Similar to DBAN, but less secure and much faster, use ‘dd’ as ‘root’:
Code:
dd if=/dev/urandom of=/dev/sda bs=1024 count=1024
Should take about one second to run and (for the example above) do serious
damage to the partition table of /dev/sda (modify for your own drive block
device).
After the fact:
4. Delete the /etc/ssh/ssh_host* files (I just tested this) and then
restart sshd:
On Wed, 27 Mar 2013 10:34:02 +0000, jmozdzen wrote:
[color=blue]
Hi Bernd,
I believe to have seen something similar, too - the files were wiped, so
I assumed the generation algorithm isn’t truly random… But that’s just
an assumption, I didn’t take the lengths to actually verify that.[/color]
I wonder if this is related to something I read earlier this week about
NetBSDs’ openSSH implementations having a similar issue?
I have looked up the current implementation, which makes it really easy to influence this behavior: The list of files to be preserved is maintained in the file /control.xml on the installation DVD and thus can be customized (and even emptied) if you feel to have that need. And of course you can look up in advance which files will be carried over to the new install.
On Wed, 27 Mar 2013 19:16:25 +0000, ab wrote:
[color=blue][color=green]
This will be, of course, much worse. But when doing a fresh install
from a newly formatted drive it might come as an unwanted surprise to
find the old keys still in place. Think of a system that has been wiped
after a security incident and where the integrity of the private ssh
keys is questionable.[/color]
If the drive was already wiped the keys won’t be there. Do you mean the
drive was not already wiped but would be wiped during the install? I
agree, you would not want anything left behind after any kind of
“security event”, though that seems like a corner case that may not
justify work to create an entirely new dialog in the installer
(requiring testing) to not pull in these values.[/color]
Yes, indeed. When doing a fresh install from the installation ISO and
creating a new disk layout during the installation Joe “average” Admin
will expect to have a clean and fresh system after the procedure. A
paranoid admin might wipe the installation prior to starting the new one,
but this should not be necessary.
[QUOTE=jmozdzen;12640]The feature seems to be a bit older… although to folks who have been around since the “birth” of Linux, it’s one of the more recent changes
that’s the reason why i prefer an OS with OSS. Things can be claryfied completely, using windows you normally bump to a point while searching where you just can guess (“It could be this or that …”).
But it’s worth to document this “feature”. I expect, when i choose “new installation” and “formatting the partitions” in yast that really /everything/ is lost on the harddisk.
Thanks for finding that out, and happy easter !
Perhaps the right place to have this prompt is right after doing
partitioning; if that which is mounted to /etc (or other partitions should
other directories be included) is formatted, and if it is currently
readable, then provide an option in the screen that sets up the mountpoint
and formatting to prevent keeping any data from there. This way the
option is there for people who care, it’s in an existing dialog (doesn’t
complicate other things, or require new screens), and it isn’t only in the
documentation which nobody will read.
For that reason documenting
the feature, and how to overcome it, would be a nice simple solution.[/color]
Since this is security related, perhaps it is worthwhile to have a bug
opened to warn customers about this /feature/ during the install.
–
Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
