ssh private key + Clonezilla

[savus]

Hello,

I have a Linux installation. This installation has a public and private key (one with dsa and one with rsa) in /etc/ssh/

This installation was “cloned” with Clonezilla into 3 different PC’s (A, B, C). The users changed the root & user password, but the keys from /etc/ssh/ are the same.

I know that you can make a ssh connection without a password using keys and the file .ssh/authorized_keys - but here is not the case, because the passwords where changed so a user from A cannot edit a file from B.

Here comes the question: is there any danger of unauthorized access, e.g. from A to B after root & users passwords were changed? I’m asking this because every body says never reveal your private key to anyone.

[Matti_Kurkela · Accepted solution]

You're talking about SSH host keys. SSH uses key pairs for two purposes: one is user authentication, the other is host identity verification. The host identity verification is designed to protect the clients against a malicious server, not vice versa.

If the host key is not changed after cloning, and a malicious person has root access to any one of your three PCs (let's say A), then that person can make PC A pretend it's actually B or C, and therefore can perform man-in-the middle attacks on the other users logging into B and C.

When a SSH connects to a new host for the first time, it receives the public part of the server's host key. On subsequent connections, the server uses its private key to provide proof it's actually the same server as before.

If a SSH client is later connecting to a host that should already be familiar (i.e. the public part of the host key is already stored by the client) but the host key does not match, the SSH client will output a dire warning with ALL CAPS to the user, and/or will disconnect immediately if the client has been configured to be extra strict about SSH keys.

As a result, if a malicious person attempts a man-in-the-middle attack against a client that has already connected to the server before, the attack will be uncovered immediately: if the attack server does not have the correct private part of the host key, it cannot create the proper digital signature to its authentication challenge. The client will show big alerts, and the user will hopefully understand that something bad is happening, or at least will contact someone who will.

This protection is not perfect: a man-in-the-middle attack can be successful if the client has never connected to the real server. But afterwards, the attacker must maintain the man-in-the-middle attack with that same client forever, or the attack will be discovered immediately after it stops (because the host key of the real server will look "wrong" to the deceived client). This increases the attacker's risk of being caught.

In short: no, the identical host keys at /etc/ssh don't present a danger of unauthorized access. But if one host of the clone group is compromised, it can be used to pretend it's one of the other hosts of the clone group, and to deceive users into revealing their passwords to an attacker that way.

It's easy to change the host keys after the cloning, if you wish: just use ssh-keygen to create a new key pair, and store both the public and the private part to /etc/ssh, using the proper permissions.

If you have both RSA and DSA algorithms enabled, you have to do this twice: once for each key type. If you have SSH protocol version 1 enabled, you'd have to create yet another key for it - but you probably shouldn't do that, since the SSH protocol version 1 is deprecated and has known weaknesses.

MK

[savus]

Thanks for the explanation!

BR,
Stefan