[wplug] OpenSSH on Debian -- generate new host keys?

D. Joe wplug at etrumeus.com
Fri May 23 06:52:29 EDT 2008


On Fri, May 23, 2008 at 12:04:29AM -0400, Will Rodina wrote:

> Can someone point me to something I can read that will tell me how to
> beat down the old host keys and replace them with good ones? I assume
> it involves ssh-keygen, but I'm not sure what other voodoo has to be
> included to make it all come together.

 http://wiki.debian.org/SSLkeys#head-974d8e1e1a4fd26f5ef20635eda3f58860d9569b

Or, go to the base page (without the #head-97.... part) and look
for "OpenSSH (Server)" in the table of contents.

Also, see

 http://www.debian.org/security/key-rollover/#openssh

Basically, what it says is to upgrade.  

I *think* that the install scripts will do the right thing, but
I updated before the current set were completely available IIRC.

The wiki basically says you can delete the old server keys, and
then use

  dpkg-reconfigure openssh-server

to generate new ones and restart the server.  Though simple,
both the "just upgrade" and the "upgrade, delete keys, and
reconfigure" approaches are a bit opaque, so I'll run down here
what I think it does in terms of just the regular ssh commands
and how to track what keys you start with and what keys you end
with.

You can use 

  ssh-keygen -l -f keyfilename

to get the keysize and fingerprint of any given key and, of
course, ls -ld keyfilename to see the ownership and permissions
of a keyfile.  So, do that first on the old keys, do whatever
you are going to do to replace them, then issue those two
commands on the new keys and compare to convince yourself
they've been changed.  

On the client side, you'll be deleting ~ssh/known_hosts anyway,
so you should be prompted by the ssh client whether to accept or
not the new server public keys, and will be presented with the
new key fingerprints, which you should recognize as being the
same as what you saw from 
 ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub

for instance. In my opinion, the "right" way if you have control
of the server in the first place is to make note of the server
key fingerprint first, anyway, then check to be sure it matches
what you are presented on the client.  If you don't control the
server, then it's on the server's owner/admin to convey to you
in some trusted out-of-band fashion what the proper fingerprint
is (though I think a common practice is for the person on the
client side to just assume they aren't meeting a
monkey-in-the-middle attack the first time they connect,
unfortunately).

If you want to do the replacement in a less automated fashion,
look at the keys you have first to see what parameters
(ownership, permissions, keysize and type [dsa or rsa]), then
move them elsewhere or delete them, then regenerate new ones
with

  ssh-keygen -t TYPE -b SIZE -f NAME

where TYPE is dsa or rsa, SIZE is typically 2048 and name is as
below (without the .pub, of course, since keygen will make one
each with and without that extension).  Server keys normally
don't have a passphrase.

Here are the server keys one typical has, their locations, and
ownership:

-rw------- 1 root root 1192 2008-05-22 15:14 /etc/ssh/ssh_host_dsa_key
-rw-r--r-- 1 root root 1112 2008-05-22 15:14 /etc/ssh/ssh_host_dsa_key.pub
-rw------- 1 root root 1675 2008-05-22 15:14 /etc/ssh/ssh_host_rsa_key
-rw-r--r-- 1 root root  392 2008-05-22 15:14 /etc/ssh/ssh_host_rsa_key.pub

Anyway, that's roughly how it goes, I think.

HTH,

-- 
D. Joe




More information about the wplug mailing list