Mailing List Archive

On Fri, Jan 30, 2009 at 09:41:28AM -0500, George Horvath (Scotia Capital)
wrote:
> into this. We are using RSA host keys that get dumped on the client server

What's a "client server"?

> by the package install script. The new server will have the same IP address
> and hostname

Then copy the host keys over from the old server to the new one.

They're typically in /etc/ssh/ssh_host_*key* or /usr/local/etc/ssh_host_*key*
(the location is configured at compile time).

Make sure the permissions are correct on the new server. You don't want
the private keys to be readable.

Each time a key is generated it is different from others whether done on the same server or a new one.

You should definitely test this before making the move, but I believe you can move/copy the public/private host key pair off of the existing server and onto the new one. Assuming they are located in the correct place and the configuration makes the server aware of them, that should keep the clients happy with their saved host-key.

Tom Pfister
Enterprise Systems Administration
Indiana Universtity

-----Original Message-----
From: listbounce@securityfocus.com [mailto:listbounce@securityfocus.com] On Behalf Of George Horvath (Scotia Capital)
Sent: Friday, January 30, 2009 9:41 AM
To: secureshell@securityfocus.com
Subject: Replacing server without having to update host key on connecting clients?

Hello,

I have a large number of servers sending reports to a central server using keys to automatically sftp the report in. I need to replace the central server without going to each client to update the known_host file with a new key so that the first transfer doesn't break due to the host being replaced. I realize the whole point of strict checking is to notify if the server has been replaced or otherwise modified but I'm sure I'm not the first one to run into this. We are using RSA host keys that get dumped on the client server by the package install script. The new server will have the same IP address and hostname and I'm hoping this will help the situation but I'm assuming the key is generated using a finger print of the server and which would be different from the new one.

Some of the clients are OpenSSH_3.9p1. The central server and most clients are a more recent version of OpenSSH. Sorry but I can't be more specific than that.

Any help would be greatly appreciated.


--------
George Horvath
Project Leader
Bank of Nova Scotia - ISS - TAG Security
Tel: 416-607-4841
E-mail: George_Horvath@scotiacapital.com


---
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this email in error, please contact the sender immediately by return electronic transmission and then immediately delete this transmission, including all attachments, without copying, distributing or disclosing same. No member of the Scotiabank Group is liable for any errors or omissions in the content or transmission of this email or accepts any responsibility or liability for loss or damage arising from the receipt or use of this transmission. Scotiabank Group may monitor, retain and/or review email. Trading instructions received by e-mail or voicemail will not be accepted or acted upon. Unless indicated in writing, opinions contained in this email are those of the author and are not endorsed by any member of the Scotiabank Group.

For information on some members of the Scotiabank Group: http://www.scotiacapital.com/EmailDisclaimer/English_entities.htm
For authorized users of the Scotia Capital trademark: http://www.scotiacapital.com/EmailDisclaimer/English_trademark.htm

Pour obtenir la traduction en français: http://www.scotiacapital.com/EmailDisclaimer/French.htm
Traducción en español: http://www.scotiacapital.com/EmailDisclaimer/Spanish.htm

George Horvath (Scotia Capital) wrote:
> Hello,
>
> I have a large number of servers sending reports to a central
> server using keys to automatically sftp the report in. I
> need to replace the central server without going to each
> client to update the known_host file with a new key so that
> the first transfer doesn't break due to the host being
> replaced. I realize the whole point of strict checking is to
> notify if the server has been replaced or otherwise modified
> but I'm sure I'm not the first one to run into this. We are
> using RSA host keys that get dumped on the client server by
> the package install script. The new server will have the
> same IP address and hostname and I'm hoping this will help
> the situation but I'm assuming the key is generated using a
> finger print of the server and which would be different from
> the new one.
>
> Some of the clients are OpenSSH_3.9p1. The central server
> and most clients are a more recent version of OpenSSH. Sorry
> but I can't be more specific than that.
>
> Any help would be greatly appreciated.

An elegant solution is to install the server's fingerprint in your DNS zone file (I'm assuming that your internal DNS system is fully DNSSEC enabled). When you are logged onto the server, "ssh-keygen -r <servername fqdn>" will generate the appropriate RR. Once this is in place, you can put something like this in your ssh configuration files:

Host <regex to match your servers>
UserKnownHostFile /dev/null
StrictHostKeyChecking no
VerifyHostKeyDNS yes

For the configured hosts, this enforces the use of DNS to store/check ssh fingerprints and disables the use of a local known_hosts file.

The only icky bit about this is the zone-file-crawling blunder in the current DNSSEC standard.


Paul

Paul,

Back up /etc/ssh_host_[dsa|rsa]* from the existing one and copy them
over on the new one.

Boby






Paul Ryland wrote:
>
> George Horvath (Scotia Capital) wrote:
>
>> Hello,
>>
>> I have a large number of servers sending reports to a central
>> server using keys to automatically sftp the report in. I
>> need to replace the central server without going to each
>> client to update the known_host file with a new key so that
>> the first transfer doesn't break due to the host being
>> replaced. I realize the whole point of strict checking is to
>> notify if the server has been replaced or otherwise modified
>> but I'm sure I'm not the first one to run into this. We are
>> using RSA host keys that get dumped on the client server by
>> the package install script. The new server will have the
>> same IP address and hostname and I'm hoping this will help
>> the situation but I'm assuming the key is generated using a
>> finger print of the server and which would be different from
>> the new one.
>>
>> Some of the clients are OpenSSH_3.9p1. The central server
>> and most clients are a more recent version of OpenSSH. Sorry
>> but I can't be more specific than that.
>>
>> Any help would be greatly appreciated.
>>
>
> An elegant solution is to install the server's fingerprint in your DNS zone file (I'm assuming that your internal DNS system is fully DNSSEC enabled). When you are logged onto the server, "ssh-keygen -r <servername fqdn>" will generate the appropriate RR. Once this is in place, you can put something like this in your ssh configuration files:
>
> Host <regex to match your servers>
> UserKnownHostFile /dev/null
> StrictHostKeyChecking no
> VerifyHostKeyDNS yes
>
> For the configured hosts, this enforces the use of DNS to store/check ssh fingerprints and disables the use of a local known_hosts file.
>
> The only icky bit about this is the zone-file-crawling blunder in the current DNSSEC standard.
>
>
> Paul
>

I just wanted to provide feedback to let you know that moving the key pair to the new server worked. It took a while to test and implement. Thanks to all who responded.

George

-----Original Message-----
From: Pfister, Thomas P [mailto:pfister@indiana.edu]
Sent: January 30, 2009 3:52 PM
To: George Horvath (Scotia Capital); secureshell@securityfocus.com
Subject: RE: Replacing server without having to update host key on connecting clients?

Each time a key is generated it is different from others whether done on the same server or a new one.

You should definitely test this before making the move, but I believe you can move/copy the public/private host key pair off of the existing server and onto the new one. Assuming they are located in the correct place and the configuration makes the server aware of them, that should keep the clients happy with their saved host-key.

Tom Pfister
Enterprise Systems Administration
Indiana Universtity

-----Original Message-----
From: listbounce@securityfocus.com [mailto:listbounce@securityfocus.com] On Behalf Of George Horvath (Scotia Capital)
Sent: Friday, January 30, 2009 9:41 AM
To: secureshell@securityfocus.com
Subject: Replacing server without having to update host key on connecting clients?

Hello,

I have a large number of servers sending reports to a central server using keys to automatically sftp the report in. I need to replace the central server without going to each client to update the known_host file with a new key so that the first transfer doesn't break due to the host being replaced. I realize the whole point of strict checking is to notify if the server has been replaced or otherwise modified but I'm sure I'm not the first one to run into this. We are using RSA host keys that get dumped on the client server by the package install script. The new server will have the same IP address and hostname and I'm hoping this will help the situation but I'm assuming the key is generated using a finger print of the server and which would be different from the new one.

Some of the clients are OpenSSH_3.9p1. The central server and most clients are a more recent version of OpenSSH. Sorry but I can't be more specific than that.

Any help would be greatly appreciated.


--------
George Horvath
Project Leader
Bank of Nova Scotia - ISS - TAG Security
Tel: 416-607-4841
E-mail: George_Horvath@scotiacapital.com


---
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this email in error, please contact the sender immediately by return electronic transmission and then immediately delete this transmission, including all attachments, without copying, distributing or disclosing same. No member of the Scotiabank Group is liable for any errors or omissions in the content or transmission of this email or accepts any responsibility or liability for loss or damage arising from the receipt or use of this transmission. Scotiabank Group may monitor, retain and/or review email. Trading instructions received by e-mail or voicemail will not be accepted or acted upon. Unless indicated in writing, opinions contained in this email are those of the author and are not endorsed by any member of the Scotiabank Group.

For information on some members of the Scotiabank Group: http://www.scotiacapital.com/EmailDisclaimer/English_entities.htm
For authorized users of the Scotia Capital trademark: http://www.scotiacapital.com/EmailDisclaimer/English_trademark.htm

Pour obtenir la traduction en français: http://www.scotiacapital.com/EmailDisclaimer/French.htm
Traducción en español: http://www.scotiacapital.com/EmailDisclaimer/Spanish.htm

---
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this email in error, please contact the sender immediately by return electronic transmission and then immediately delete this transmission, including all attachments, without copying, distributing or disclosing same. No member of the Scotiabank Group is liable for any errors or omissions in the content or transmission of this email or accepts any responsibility or liability for loss or damage arising from the receipt or use of this transmission. Scotiabank Group may monitor, retain and/or review email. Trading instructions received by e-mail or voicemail will not be accepted or acted upon. Unless indicated in writing, opinions contained in this email are those of the author and are not endorsed by any member of the Scotiabank Group.

For information on some members of the Scotiabank Group: http://www.scotiacapital.com/EmailDisclaimer/English_entities.htm
For authorized users of the Scotia Capital trademark: http://www.scotiacapital.com/EmailDisclaimer/English_trademark.htm

Pour obtenir la traduction en français: http://www.scotiacapital.com/EmailDisclaimer/French.htm
Traducción en español: http://www.scotiacapital.com/EmailDisclaimer/Spanish.htm