latest openssh can not connect to older server

[Brian Inglis]

On 2020-04-20 04:11, Thomas Wolff wrote:
> Am 19.04.2020 um 14:31 schrieb Sharuzzaman Ahmat Raslan via Cygwin:
>> On Sun, 19 Apr 2020, 8:13 pm David Balažic via Cygwin, wrote:
>>> I tried to backup some files from my server with scp and failed:
>>> $ scp  -v  root@the.server:/root/a.file  .
>>> Executing: program /usr/bin/ssh host the.server, user root, command
>>> scp -v -f /root/a.file
>>> OpenSSH_8.2p1, OpenSSL 1.1.1f  31 Mar 2020
>>> debug1: Connecting to the.server [192.168.1.11] port 22.
>>> debug1: Connection established.
>>> debug1: identity file /home/stein/.ssh/id_rsa type -1
>>> debug1: identity file /home/stein/.ssh/id_rsa-cert type -1
>>> debug1: identity file /home/stein/.ssh/id_dsa type -1
>>> debug1: identity file /home/stein/.ssh/id_dsa-cert type -1
>>> debug1: identity file /home/stein/.ssh/id_ecdsa type -1
>>> debug1: identity file /home/stein/.ssh/id_ecdsa-cert type -1
>>> debug1: identity file /home/stein/.ssh/id_ecdsa_sk type -1
>>> debug1: identity file /home/stein/.ssh/id_ecdsa_sk-cert type -1
>>> debug1: identity file /home/stein/.ssh/id_ed25519 type -1
>>> debug1: identity file /home/stein/.ssh/id_ed25519-cert type -1
>>> debug1: identity file /home/stein/.ssh/id_ed25519_sk type -1
>>> debug1: identity file /home/stein/.ssh/id_ed25519_sk-cert type -1
>>> debug1: identity file /home/stein/.ssh/id_xmss type -1
>>> debug1: identity file /home/stein/.ssh/id_xmss-cert type -1
>>> debug1: Local version string SSH-2.0-OpenSSH_8.2
>>> debug1: Remote protocol version 2.0, remote software version
>>> dropbear_2011.54
>>> debug1: no match: dropbear_2011.54
>>> debug1: Authenticating to the.server:22 as 'root'
>>> debug1: SSH2_MSG_KEXINIT sent
>>> debug1: SSH2_MSG_KEXINIT received
>>> debug1: kex: algorithm: (no match)
>>> Unable to negotiate with 192.168.1.11 port 22: no matching key
>>> exchange method found. Their offer:
>>> diffie-hellman-group1-sha1,diffie-hellman-group14-sha1
>>> I tried OpenSSH_8.0p1-2 which is still available in the cygwin
>>> setup-x86_64.exe wizard and that version works fine.
>>> (the version above is 8.2.p1-1 in the setup wizard)
>> New OpenSSH client will not connect to server that use SHA1.
>> Please refer to this: https://www.openssh.com/legacy.html
>> You should configure your old server to use more modern cipher

> This isn't always a feasible approach. I access a WD MybookLive NAS storage
> via ssh. It still works with current openssh (8.2) but I wouldn't know how to
> find out the methods supported by my server and wouldn't like to risk the
> adventure to upgrade such a device. Therefore I'd suggest to configure in
> "legacy" methods in the cygwin openssh package as mentioned under the link
> above, to avoid such trouble.
Many corps maintain legacy applications on legacy systems using legacy devices,
and not everyone can afford (especially nowadays) the money or the effort or the
expertise, nor should they ever be forced (remember freedom) to upgrade legacy
devices, systems, or applications, as the vendor and/or code may be long gone.

When browsers and security libraries decided to incompatibly totally drop all
support for legacy SSL, rather than make continued use configurable on a per
site basis, I had to quickly reconfigure my recently purchased (and still CVE
free) router to downgrade from HTTPS to HTTP local port access to be able to
continue having access to it.
I could perhaps have tried to keep a legacy copy of some browser around, but
parallel releases are unsupported, and package upgrades try hard to ensure old
releases are eliminated.

[ToWo: From WD support, your NAS is EoL and unsupported, and the forums indicate
you may have a bigger problem (soon?) as Windows appears to be dropping support
for SMB1 required to access your NAS.
For OpenSSH, your best approach may be to get sources for it and its library
dependencies, and ensure that you can build them with cygport, so if all support
is dropped from OpenSSH as I would expect, you still have access. The advantage
of freedom!]

-- 
-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.