[haiku-development] Re: Administrative notice: new SSH host keys for our machines
- From: Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 16 Apr 2014 10:23:08 +0200
Hi,
On 2014-04-16 at 01:06:36 [+0200], Jonathan Schleifer
<js-haiku-development@xxxxxxxxxxx> wrote:
> Am 14.04.2014 um 18:34 schrieb Oliver Tappe <zooey@xxxxxxxxxxxxxxx>:
>
> > Hi there,
> >
> > since our ssh host keys could in theory have been compromised (and were
> > pretty weak to start with),
>
> Can you elaborate what happened? If for security reasons you don't want to
> make the actual issue public, it would be nice if you could send me a
> private mail.
I find it pretty difficult to judge the exact effects of heartbleed, so I've
decided this is a good time to follow your advice (you were the one pointing
out the weakness of our ssh host keys in the first place) and rotate the keys.
> > I have created a new 4096-bit long RSA host key
> > for each of baron, vmrepo, vmdev and vmweb.
>
> Would it be possible to also get an Ed25519 key? :)
It certainly is, once we are using openssh-6.5. As of now, we're running
openssh-6.2, which doesn't support Ed25519 keys.
> > The change on vmrepo will affect all developers, as git is using ssh to
> > connect to it when pulling/pushing. So, in order to simplify the process,
> > the old keys are going to stay active until end of this month.
>
> Uhm, I'm a little bit confused here. The old key is certainly not active
> for me anymore…
Well, the old RSA key might not, but the ECDSA key should be, which seems to
be preferred by ssh. I have no idea why your ssh client seems to ignore the
ecdsa key, maybe it doesn't support that key type?
> > In order to
> > be able to switch to the new host key when the old ones have been deleted,
> > please follow this steps:
> >
> > 1. Fetch the new RSA-key:
> >
> > ssh-keyscan -H -t rsa vmrepo.haiku-os.org
> >
> > 2. Remove all old host keys for vmrepo from the known_hosts file:
> >
> > ssh-keygen -R vmrepo.haiku-os.org
> > ssh-keygen -R 78.46.189.219
> >
> > 3. Add the new key (what ssh-keyscan has printed) to your known_hosts file
>
> I'm not sure what the point of this would be. AFAIK, there can only be one
> RSA key, and what I get is the new RSA key. Thus this would be exactly
> equivalent to just removing the old key and blindly typing "yes" when SSH
> asks me if I trust that key.
Sure, if you were just using RSA keys. However, the server did provide a DSA
and an ECDSA key, too.
> What about the approach to have /etc/ssh/ssh_host_rsa_key_new.pub, which is
> not used for now, and then just use this as the new key at the end of the
> month?
What's the difference to what has happened for you now? That would mean that
everyone has to switch now without a chance to fetch the new key first.
> As it is right now, the situation is that I can't login unless I accept a
> new key which I can't verify in any way.
>
> > baron: 0a:37:bc:16:88:55:27:d0:98:9e:61:41:fa:75:39:99
> > vmrepo: 42:85:91:9f:c7:75:1b:c6:e2:f8:f1:02:c0:05:96:63
> > vmdev: dc:f0:21:f0:f2:7e:ff:e4:50:37:f9:cc:f4:39:2e:1f
> > vmweb: aa:39:2f:d9:64:43:d6:06:79:91:2a:0e:22:70:14:db
>
> Could you at least sign these with your PGP key, please? (Well, I don't
> have your GPG key either, but hopefully someone of my web of trust signed
> yours.)
All I can offer you is to point out that the same fingerprints are being
shown on https://server-stats.haiku-os.org and that I'm happy to confirm them
via IRC.
cheers,
Oliver
Other related posts:
