[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#807239: marked as done (openssh-client: ssh complains on host key type even when host key checking is disabled)

Your message dated Wed, 9 Dec 2015 15:18:44 +0000
with message-id <[🔎] 20151209151844.GL2181@riva.ucam.org>
and subject line Re: Bug#807239: lftp: can no longer connect with sftp (no matching host key type found)
has caused the Debian Bug report #807239,
regarding openssh-client: ssh complains on host key type even when host key checking is disabled
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
807239: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807239
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: lftp
Version: 4.6.3a-1+b1
Severity: grave
Justification: renders package unusable

After a system upgrade, lftp can no longer connect with sftp.
When I type "dir", I get the error:

`ls' at 0 [Unable to negotiate with 192.168.1.4: no matching host key type found. Their offer: ssh-dss]

4 days ago, I had no problems.

On another machine on the same local network, which hasn't had the
latest upgrades yet, lftp still works (same commands).

-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.2.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lftp depends on:
ii  libc6              2.21-3
ii  libgcc1            1:5.3.1-1
ii  libgnutls-deb0-28  3.3.18-1
ii  libidn11           1.32-3
ii  libreadline6       6.3-8+b4
ii  libstdc++6         5.3.1-1
ii  libtinfo5          6.0+20151024-2
ii  netbase            5.3
ii  zlib1g             1:1.2.8.dfsg-2+b1

lftp recommends no packages.

lftp suggests no packages.

-- no debconf information

--- End Message ---
--- Begin Message --- 
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                                       [cjwatson@debian.org]

--- End Message ---
Reply to: