Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#807239: lftp: can no longer connect with sftp (no matching host key type found)
403 views
Skip to first unread message
Vincent Lefevre
Dec 6, 2015, 11:00:03 AM12/6/15
to
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
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
Russ Allbery
Dec 8, 2015, 11:40:03 PM12/8/15
to
Vincent Lefevre <vin...@vinc17.net> writes:
> no dependencies!).
> First, the error is surprising because I was just using an IP address,
> for which host key checking doesn't make much sense. But even if I set
> both CheckHostIP and StrictHostKeyChecking to "no", I get the error!
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
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 is unrelated to host key checking or IP checking. It's about the
type of underlying crypto being used to secure the connection.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
> On 2015-12-06 16:48:35 +0100, Vincent Lefevre wrote:
>> 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.
> The problem actually comes from openssh-client (on which lftp has
>> 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.
> no dependencies!).
> First, the error is surprising because I was just using an IP address,
> for which host key checking doesn't make much sense. But even if I set
> both CheckHostIP and StrictHostKeyChecking to "no", I get the error!
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
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 is unrelated to host key checking or IP checking. It's about the
type of underlying crypto being used to secure the connection.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Vincent Lefevre
Dec 9, 2015, 4:10:04 AM12/9/15
to
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
> 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
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.
> 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.
to have a choice for the type of the host key).
> This is unrelated to host key checking or IP checking. It's about the
> type of underlying crypto being used to secure the connection.
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?
--
Vincent Lefèvre <vin...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Vincent Lefevre
Dec 9, 2015, 10:50:03 AM12/9/15
to
On 2015-12-09 15:18:44 +0000, Colin Watson wrote:
> you'll have to use legacy options.
I've just sent them a mail.
> > > 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.
My point is that with StrictHostKeyChecking = no and no keys for
the host in ~/.ssh/known_hosts, there is no host authentication,
so that a man-in-the-middle attack is already possible, even if
the server provides a strong key. Thus whether a weak host key
is provided by the server or not in this case shouldn't matter.
> On Wed, Dec 09, 2015 at 10:06:32AM +0100, Vincent Lefevre wrote:
> > 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
> > 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).
>
> you'll have to use legacy options.
I've just sent them a mail.
> > > 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?
>
My point is that with StrictHostKeyChecking = no and no keys for
the host in ~/.ssh/known_hosts, there is no host authentication,
so that a man-in-the-middle attack is already possible, even if
the server provides a strong key. Thus whether a weak host key
is provided by the server or not in this case shouldn't matter.
Colin Watson
Dec 9, 2015, 12:30:03 PM12/9/15
to
On Wed, Dec 09, 2015 at 04:44:31PM +0100, Vincent Lefevre wrote:
> On 2015-12-09 15:18:44 +0000, Colin Watson wrote:
> > On Wed, Dec 09, 2015 at 10:06:32AM +0100, Vincent Lefevre wrote:
> > > 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.
>
> My point is that with StrictHostKeyChecking = no and no keys for
> the host in ~/.ssh/known_hosts, there is no host authentication,
> so that a man-in-the-middle attack is already possible, even if
> the server provides a strong key. Thus whether a weak host key
> is provided by the server or not in this case shouldn't matter.
With StrictHostKeyChecking=yes/ask, it still weakens trust-on-first-use.
> On 2015-12-09 15:18:44 +0000, Colin Watson wrote:
> > On Wed, Dec 09, 2015 at 10:06:32AM +0100, Vincent Lefevre wrote:
> > > 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.
>
> My point is that with StrictHostKeyChecking = no and no keys for
> the host in ~/.ssh/known_hosts, there is no host authentication,
> so that a man-in-the-middle attack is already possible, even if
> the server provides a strong key. Thus whether a weak host key
> is provided by the server or not in this case shouldn't matter.
With StrictHostKeyChecking=no, I can somewhat see your point (although
there would at least be a visual indication if a different host key were
presented); but I doubt that it's worth continuing to support otherwise
obsolescent cryptography just for that case.
Put another way: it'd be quite peculiar and confusing to send different
server_host_key_algorithms in the client's SSH_MSG_KEXINIT packet
depending on the value of StrictHostKeyChecking.
--
Colin Watson [cjwa...@debian.org]
0 new messages