Date: Tue, 22 May 2012 08:51:16 -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: <1337698276.1116.28.camel@revolution.hippie.lan> In-Reply-To: <1337635587.57757.YahooMailClassic@web122503.mail.ne1.yahoo.com> References: <1337635587.57757.YahooMailClassic@web122503.mail.ne1.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-a0c6cJ9uCGd4jRa9ODOg
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
On Mon, 2012-05-21 at 14:26 -0700, Jason Usher wrote:
>
> --- On Mon, 5/21/12, Garance A Drosehn <gad@FreeBSD.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.
The server has a list of things it can support, A,B,C,D. The client
sends a list of things it desires, in order of preference, D,A,C. The
server chooses a match as follows:
for each client list item
for each server list item
if current-client-item matches current-server-item
return current-client-item as the match
end if
end for
end for
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.
So I think you have two choices...
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.
2) Try the attached patch to violate the design and force the server's
configuration order to override the precedence implied by the client's
request list. Put HostKey statements the sshd_config file in the order
you want enforced.
I don't think #2 is a good option, but I know how it is in a production
world... sometimes you've got to do things that you know are bad to keep
the show running. Hopefully when you do such things it's just to buy
some time to deploy a better fix (but it doesn't always work out that
way; I still maintain horrible "temporary" hacks like this from years
and years ago).
Maybe option 1 would work okay for you in light of this info: When I
look in the openssh source from freebsd 6.4, it appears that while an
rsa hostkey was supported, it would not be added to the server config by
default; it would only be used if you specifically configured it with a
HostKey statement in sshd_config. So maybe you can safely assume that
nobody was ever connecting to your freebsd 6.x machines using an rsa
hostkey.
Now for The Big Caveat: All of the above is based on code inspection.
I haven't tested anything, including the attached patch.
-- Ian
--=-a0c6cJ9uCGd4jRa9ODOg
Content-Description:
Content-Disposition: inline; filename="revkeys.diff"
Content-Type: text/x-patch; name="revkeys.diff"; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Index: crypto/openssh/kex.c
===================================================================
--- crypto/openssh/kex.c (revision 235554)
+++ crypto/openssh/kex.c (working copy)
@@ -371,7 +371,7 @@
static void
choose_hostkeyalg(Kex *k, char *client, char *server)
{
- char *hostkeyalg = match_list(client, server, NULL);
+ char *hostkeyalg = match_list(server, client, NULL);
if (hostkeyalg == NULL)
fatal("no hostkey alg");
k->hostkey_type = key_type_from_name(hostkeyalg);
--=-a0c6cJ9uCGd4jRa9ODOg--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1337698276.1116.28.camel>