From owner-freebsd-hackers@FreeBSD.ORG Tue May 22 16:59:22 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7D0D91065673 for ; Tue, 22 May 2012 16:59:22 +0000 (UTC) (envelope-from jusher71@yahoo.com) Received: from nm10-vm2.bullet.mail.ne1.yahoo.com (nm10-vm2.bullet.mail.ne1.yahoo.com [98.138.90.158]) by mx1.freebsd.org (Postfix) with SMTP id 328338FC19 for ; Tue, 22 May 2012 16:59:22 +0000 (UTC) Received: from [98.138.90.49] by nm10.bullet.mail.ne1.yahoo.com with NNFMP; 22 May 2012 16:59:16 -0000 Received: from [98.138.89.175] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 22 May 2012 16:59:16 -0000 Received: from [127.0.0.1] by omp1031.mail.ne1.yahoo.com with NNFMP; 22 May 2012 16:59:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 419649.48871.bm@omp1031.mail.ne1.yahoo.com Received: (qmail 96649 invoked by uid 60001); 22 May 2012 16:59:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1337705956; bh=WhoIfq6EaG4rLcNzaRdE58Bpq27wnbhxWI5707TSvuw=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=qxPkxrPBfr3cYWl6kzi8Rh8EUerGesuytw5/ttLUHrVspjQNSe0OLOm8EhLbOSnfyKEKN0K3N3trjQX/6K7VNBZwfEMOibHO/XR/VDFi21jzwrz0kiOYwEe3T5UrOxnAlrhHIM4BVI0TCEcVk31fz2+wq7oB2TvwWmr6Y5pMPtw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=R8eFO2vRg1Dzvxt9JeZdfPaewJd8EQtEsIpUQ+hpBll+eMBK8KaBVMLlBIFlP0IgPS56/yfj3NMlVz8qM8nvcBKJIBT2eBXVK4OsL6blNHmFWSm26HCdBtzzfwXFZa+ykVT8i7bLAkpM+WKvxfHiHaPbTANKbUOTXpDtj+6nN5Q=; X-YMail-OSG: ARmQtKAVM1mPeun2JwKGEfRQOQlekj9LZjgwfeQFFZ37qqO bDisuok_q8INRCV1wABf4sAD98YX1yct9ovAU5U3gYeWWDRtVfLzicwWgrVw 5Y6DBPR34iIe.2Xnrj4tea6UPwYRe6USr8Vd0_zQZEf5eNOYxkPwYOvvbxvp rbPP66L9xGi02KTCFyv3UiWOA3wZqOxhzoklPVsLyle7Kj1HR2vH0YGI97Uv ki45cfg8IBQVdLnrK7r.85i6dXBtvQnQJzmOHDktqURdO83leuTxNXMrGtoN pBb6YTpHpvL8EhrTRos4v.3AO0M_hqObQfh7c_RRCPF86WL9GNZUq4xca32D Fj5iav4ZsePMlKQ9slJLXdSIuVHBC03j.eiFQjklCyWBy6wa4g.AyXSkE9Pm BVQ-- Received: from [173.164.238.34] by web122505.mail.ne1.yahoo.com via HTTP; Tue, 22 May 2012 09:59:16 PDT X-Mailer: YahooMailClassic/15.0.6 YahooMailWebService/0.8.118.349524 Message-ID: <1337705956.52238.YahooMailClassic@web122505.mail.ne1.yahoo.com> Date: Tue, 22 May 2012 09:59:16 -0700 (PDT) From: Jason Usher To: Ian Lepore MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 22 May 2012 18:00:22 +0000 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 16:59:22 -0000 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 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.