On Mon, May 21, 2012 at 02:26:27PM -0700, Jason Usher wrote: > > > --- On Mon, 5/21/12, Garance A Drosehn <g...@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 ?
The problem to me seems to be on the client end. Where the new ssh installation is attempting RSA authentication first rather than DSA and your ssh server has just now caught up to the clients. If I were you, I would just make an announcement providing the host fingerprints to clients and asking them to update known_hosts appropriately, rather than creating a virtual fix for sshd that you will have to maintain yourself. -- - (2^(N-1)) _______________________________________________ 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"
