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

[Will Rodina]

Woot. Thank you to all for the exceedingly helpful replies.

I now feel like less of a putz. :)

- Will

On Fri, May 23, 2008 at 6:52 AM, D. Joe <wplug at etrumeus.com> wrote:
> 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
>
>
> _______________________________________________
> wplug mailing list
> wplug at wplug.org
> http://www.wplug.org/mailman/listinfo/wplug
>