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 <free...@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. _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
