On Wed, Dec 09, 2015 at 10:06:32AM +0100, Vincent Lefevre wrote: > On 2015-12-08 20:33:27 -0800, Russ Allbery wrote: > > I think Colin is still working on making sure this change is visible > > enough to everyone it affects, but see the changelog in openssh-client: > > > > - Support for ssh-dss, ssh-dss-cert-* host and user keys is disabled by > > default at run-time. These may be re-enabled using the instructions > > at http://www.openssh.com/legacy.html > > I actually saw this page after googling the error message (not very > easy because with lftp, the error message disappears very quickly, > the part about ssh-dss isn't even visible with a 80-column terminal). > > This should have been put at least in the NEWS.Debian file.
I added a NEWS.Debian file in 1:7.1p1-2, currently waiting in NEW. > > It sounds like the remote host to which you're trying to connect only > > offers ssh-dss keys, which are no longer supported by default (following > > upstream) because they're not very secure. > > This from is a SSH server for Android (and the user doesn't seem > to have a choice for the type of the host key). Please report this to the maintainers of that server. In the meantime you'll have to use legacy options. > > This is unrelated to host key checking or IP checking. It's about the > > type of underlying crypto being used to secure the connection. > > According to what is documented, this appears to be related to > host key checking: the error mesage is "no matching *host key* > type found" and the option name is HostKeyAlgorithms. In what > way it could be insecure in the case where the user doesn't have > the key in the ~/.ssh/known_hosts file? Weak host keys make it easier to conduct man-in-the-middle attacks. This isn't a change I'm going to revert in Debian, I'm afraid, but I hope that the upcoming NEWS.Debian change helps. -- Colin Watson [[email protected]]
