From owner-freebsd-hackers@FreeBSD.ORG Tue May 22 14:52:25 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 479051065688 for ; Tue, 22 May 2012 14:52:25 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id 255598FC1F for ; Tue, 22 May 2012 14:52:25 +0000 (UTC) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta09.emeryville.ca.mail.comcast.net with comcast id D1AB1j0031u4NiLA92rKoh; Tue, 22 May 2012 14:51:19 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta21.emeryville.ca.mail.comcast.net with comcast id D2rJ1j0044NgCEG8h2rJN1; Tue, 22 May 2012 14:51:19 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q4MEpG5B003421; Tue, 22 May 2012 08:51:16 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Jason Usher In-Reply-To: <1337635587.57757.YahooMailClassic@web122503.mail.ne1.yahoo.com> References: <1337635587.57757.YahooMailClassic@web122503.mail.ne1.yahoo.com> Content-Type: multipart/mixed; boundary="=-a0c6cJ9uCGd4jRa9ODOg" Date: Tue, 22 May 2012 08:51:16 -0600 Message-ID: <1337698276.1116.28.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-hackers@freebsd.org Subject: Re: Need to revert behavior of OpenSSH to the old key order ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 14:52:25 -0000 --=-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 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--