Date: Tue, 22 May 2012 13:12:07 -0600 From: Ian Lepore <freebsd@damnhippie.dyndns.org> To: Jason Usher <jusher71@yahoo.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Need to revert behavior of OpenSSH to the old key order ... Message-ID: <1337713927.1116.40.camel@revolution.hippie.lan> In-Reply-To: <1337705956.52238.YahooMailClassic@web122505.mail.ne1.yahoo.com> References: <1337705956.52238.YahooMailClassic@web122505.mail.ne1.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2012-05-22 at 09:59 -0700, Jason Usher wrote:
> Hi Ian,
>
> Thank you very much for taking a look at this, and for understanding what I'm talking about here.
>
> Comments inline, below...
>
>
> --- On Tue, 5/22/12, Ian Lepore <freebsd@damnhippie.dyndns.org> wrote:
>
> > >
> > > > But have you tried it in this order
> > ?
> > > >
> > > > HostKey
> > /usr/local/etc/ssh/ssh_host_key
> > > > HostKey
> > > > /usr/local/etc/ssh/ssh_host_dsa_key
> > > > HostKey
> > > > /usr/local/etc/ssh/ssh_host_rsa_key
> > > > HostKey
> > > > /usr/local/etc/ssh/ssh_host_ecdsa_key
> > > >
> > > > Which is to say, have your sshd_config file list
> > multiple
> > > > hostkey's, and then restart sshd after making that
> > change?
> > > > I tried a similar change and it seemed to have
> > some effect
> > > > on what clients saw when connecting, but I can't
> > tell if
> > > > it has the effect that you want.
> > >
> > >
> > > The order of HostKey directives in sshd_config does not
> > change the actual order. In newer implementations, RSA
> > is provided first, no matter how you configure the
> > sshd_config.
> > >
> > > As I mentioned before, removing RSA completely is sort
> > of a fix, but I can't do that because some people might
> > actually be explicitly using RSA, and they would all break.
> > >
> > > Anyone ?
> >
> > After poking through the sshd code a bit, it looks to me
> > like this is
> > working as designed and it's the clients that are
> > broken. For host key
> > algorithm, and other things where both the server and the
> > client side
> > have a list of possibilities and have to agree on a match
> > from those
> > lists, the client side is completely in control of
> > precedence, by
> > design.
>
>
> OK. That's bad news, as I have no influence on the clients at all.
>
>
>
> > In your case it appears that the client sends "rsa,dsa" as
> > the host key
> > algorithm list. The server has
> > "dsa,rsa,maybe,other,stuff" and since
> > rsa is the client's first choice and exists in the server
> > list, it gets
> > used. Then the client rejects the rsa key because it
> > was really only
> > ever going to be happy with a dsa key. IMO, this is a
> > client-side bug;
> > if it's only going to accept dsa (because that's the only
> > thing in the
> > known_hosts file) then it should only ask for that.
>
>
> Exactly. It would be nice if the client at least tried the other algorithm to see if that does indeed match up with the public key it is sitting on ... breaking automation out in the field is really problematic.
>
>
>
> > 1) Only offer a dsa key. It appears the right way to
> > do this would be
> > to have just one HostKey statement in the sshd config file
> > that names
> > your dsa key file. The presence of at least one
> > HostKey statement will
> > prevent the code from adding the default keyfile names
> > internally, so
> > you should end up with only a dsa key being offered.
>
>
> Ok, I did this - I explicitly defined a HostKey in sshd_config that happens to be my DSA key:
>
> #HostKey for protocol version 1
> #HostKey /etc/ssh/ssh_host_key
> #HostKeys for protocol version 2
> HostKey /etc/ssh/ssh_host_dsa_key
>
> (note the last line is uncommented)
>
> and sshd does indeed just present the DSA key (to clients that were previously negotiating the RSA key, after the upgrade).
>
> So this is great... I was originally wary of forcing DSA only like this, since there might be clients out in the world that had somehow negotiated an RSA key, but based on your further comments, it sounds like that is not the case.
>
> So if everyone has DSA keys (we'll find out ...) then we are all set.
>
> Thank you very much for examining this issue - I hope the archives of this conversation will help others in the future.
Seeing your example config with the commented-out HostKey lines made me
realize that you probably want to have two HostKey lines, one for the
protocol v1 key and another for the dsa key for v2. The 6.x server
added the v1 key and the v2 dsa key by default, so you could have
existing clients relying on a v1 key. Since you now have a HostKey
statement the new server code won't add the v1 key by default so you'd
need to be explicit about it.
Based on examining the code, I think this will be safe because the keys
have different type-names ("rsa1" vs "rsa") so a client wanting to use a
protocol v2 rsa key won't accidentally match the protcol v1 rsa key
named in the config file (and it will still match the dsa key).
-- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1337713927.1116.40.camel>