Date: Tue, 22 May 2012 09:59:16 -0700 (PDT) From: Jason Usher <jusher71@yahoo.com> To: Ian Lepore <freebsd@damnhippie.dyndns.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Need to revert behavior of OpenSSH to the old key order ... Message-ID: <1337705956.52238.YahooMailClassic@web122505.mail.ne1.yahoo.com>
next in thread | raw e-mail | index | archive | help
Hi Ian,=0A=0AThank you very much for taking a look at this, and for underst= anding what I'm talking about here.=0A=0AComments inline, below...=0A=0A=0A= --- On Tue, 5/22/12, Ian Lepore <freebsd@damnhippie.dyndns.org> wrote:=0A= =0A> >=A0 =0A> > >=A0 =A0 But have you tried it in this order=0A> ?=0A> > >= =0A> > >=A0 =A0 HostKey=0A> /usr/local/etc/ssh/ssh_host_key=0A> > >=A0 =A0= HostKey=0A> > > /usr/local/etc/ssh/ssh_host_dsa_key=0A> > >=A0 =A0 HostKey= =0A> > > /usr/local/etc/ssh/ssh_host_rsa_key=0A> > >=A0 =A0 HostKey=0A> > >= /usr/local/etc/ssh/ssh_host_ecdsa_key=0A> > > =0A> > > Which is to say, ha= ve your sshd_config file list=0A> multiple=0A> > > hostkey's, and then rest= art sshd after making that=0A> change?=0A> > > I tried a similar change and= it seemed to have=0A> some effect=0A> > > on what clients saw when connect= ing, but I can't=0A> tell if=0A> > > it has the effect that you want.=0A> >= =0A> > =0A> > The order of HostKey directives in sshd_config does not=0A> = change the actual order.=A0 In newer implementations, RSA=0A> is provided f= irst, no matter how you configure the=0A> sshd_config.=0A> > =0A> > As I me= ntioned before, removing RSA completely is sort=0A> of a fix, but I can't d= o that because some people might=0A> actually be explicitly using RSA, and = they would all break.=0A> > =0A> > Anyone ?=0A> =0A> After poking through t= he sshd code a bit, it looks to me=0A> like this is=0A> working as designed= and it's the clients that are=0A> broken.=A0 For host key=0A> algorithm, a= nd other things where both the server and the=0A> client side=0A> have a li= st of possibilities and have to agree on a match=0A> from those=0A> lists, = the client side is completely in control of=0A> precedence, by=0A> design.= =0A=0A=0AOK.=A0 That's bad news, as I have no influence on the clients at a= ll.=0A=0A=0A=0A> In your case it appears that the client sends "rsa,dsa" as= =0A> the host key=0A> algorithm list.=A0 The server has=0A> "dsa,rsa,maybe,= other,stuff" and since=0A> rsa is the client's first choice and exists in t= he server=0A> list, it gets=0A> used.=A0 Then the client rejects the rsa ke= y because it=0A> was really only=0A> ever going to be happy with a dsa key.= =A0 IMO, this is a=0A> client-side bug;=0A> if it's only going to accept ds= a (because that's the only=0A> thing in the=0A> known_hosts file) then it s= hould only ask for that.=0A=0A=0AExactly.=A0 It would be nice if the client= at least tried the other algorithm to see if that does indeed match up wit= h the public key it is sitting on ... breaking automation out in the field = is really problematic.=0A=0A=0A=0A>=A0 1) Only offer a dsa key.=A0 It appea= rs the right way to=0A> do this would be=0A> to have just one HostKey state= ment in the sshd config file=0A> that names=0A> your dsa key file.=A0 The p= resence of at least one=0A> HostKey statement will=0A> prevent the code fro= m adding the default keyfile names=0A> internally, so=0A> you should end up= with only a dsa key being offered.=0A=0A=0AOk, I did this - I explicitly d= efined a HostKey in sshd_config that happens to be my DSA key:=0A=0A#HostKe= y for protocol version 1=0A#HostKey /etc/ssh/ssh_host_key=0A#HostKeys for p= rotocol version 2=0AHostKey /etc/ssh/ssh_host_dsa_key=0A=0A(note the last l= ine is uncommented)=0A=0Aand sshd does indeed just present the DSA key (to = clients that were previously negotiating the RSA key, after the upgrade).= =0A=0ASo this is great... I was originally wary of forcing DSA only like th= is, since there might be clients out in the world that had somehow negotiat= ed an RSA key, but based on your further comments, it sounds like that is n= ot the case.=0A=0ASo if everyone has DSA keys (we'll find out ...) then we = are all set.=0A=0AThank you very much for examining this issue - I hope the= archives of this conversation will help others in the future.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1337705956.52238.YahooMailClassic>