I have an issue with data transmission from one computer to another.

An example of the issue is doing "scp" to copy a file between the
computers. 1 time out of 10 it just hangs, and eventually times out,
with this message:

"ssh_exchange_identification: read: Connection timed out
lost connection"

This is an example of the issue. I am doing other things between the two
computers, and it also times out.

What could be the problem? What could I do to diagnose the issue? Things
have been working for 6 months, now suddenly today it has stopped working.

On 03/08/2022 19:20, Max wrote:
> I have an issue with data transmission from one computer to another.
>
> An example of the issue is doing "scp" to copy a file between the
> computers. 1 time out of 10 it just hangs, and eventually times out,
> with this message:
>
> "ssh_exchange_identification: read: Connection timed out
> lost connection"
>
> This is an example of the issue. I am doing other things between the two
> computers, and it also times out.
>
> What could be the problem? What could I do to diagnose the issue? Things
> have been working for 6 months, now suddenly today it has stopped working.

A recent update of OpenSSL/OpenSSH at either end can do this, when it
gets too "new".

If you run "scp" with "-vvv" it will tell you a lot about what is going on.

Solving it without updating the offending end is not an easy problem.

At $ORK I am currently dealing with the problem of accessing Solaris
11.4 and RedHat 9 machines from ancient systems where the owners of said
ancient systems are culturally incapable of accepting the need to
update. Sigh.

Cheers,
Gary B-)

Gary R. Schmidt <grschmidt@acm.org> wrote:
> On 03/08/2022 19:20, Max wrote:
>> I have an issue with data transmission from one computer to another.
>>
>> An example of the issue is doing "scp" to copy a file between the
>> computers. 1 time out of 10 it just hangs, and eventually times out,
>> with this message:
>>
>> "ssh_exchange_identification: read: Connection timed out
>> lost connection"
>>
>> This is an example of the issue. I am doing other things between the two
>> computers, and it also times out.
>>
>> What could be the problem? What could I do to diagnose the issue? Things
>> have been working for 6 months, now suddenly today it has stopped working.
>
> A recent update of OpenSSL/OpenSSH at either end can do this, when it
> gets too "new".

One time out of ten? That's not a problem that I've encountered.
Errors such as "no matching cipher found" are the usual result of
trying to connect an old client to an up-to-date SSH server, but
this will by definition happen every time it is attempted between
the same two computers, not just occasionally.

Of course Max is bound to just be trolling anyway, I expect he's
never scp'ed a file in his life and has just picked this out of a
web forum somewhere. The problem itself is probably to do with a
dodgy network connection or a network adapter driver issue.
Especially if the scp problem is just one "example of the issue"
of the problems communicating between these two computers.

> If you run "scp" with "-vvv" it will tell you a lot about what is going on.
>
> Solving it without updating the offending end is not an easy problem.

That depends on the software and just how old the client is of
course, but with OpenSSH it can often be pretty easy to fix just
by editing the settings in the configuration file. This is a
security risk of course, but the defaults may be overly
conservative for some usage cases.

> At $ORK I am currently dealing with the problem of accessing Solaris
> 11.4 and RedHat 9 machines from ancient systems where the owners of said
> ancient systems are culturally incapable of accepting the need to
> update. Sigh.

Many ways and means around that depending on the circumstances. I'm
posting from a Pentium 1 PC right now and am familiar with most of
them.

--
__ __
#_ < |\| |< _#

On 04/08/2022 09:13, Computer Nerd Kev wrote:
> Gary R. Schmidt <grschmidt@acm.org> wrote:
[SNIP]
>
>> At $ORK I am currently dealing with the problem of accessing Solaris
>> 11.4 and RedHat 9 machines from ancient systems where the owners of said
>> ancient systems are culturally incapable of accepting the need to
>> update. Sigh.
>
> Many ways and means around that depending on the circumstances. I'm
> posting from a Pentium 1 PC right now and am familiar with most of
> them.
>
Not even vaguely equivalent to the problem of people who intend to run,
for example, Solaris 8 on SPARC hardware, until it collapses into rust.

And when I say, "incapable of accepting the need to update", I mean,
never, ever, ever been patched.

Despite having a full support contract with SUN-as-was and Oracle-as-is,
and accepting (eventually) us supplying a new binary, shared object,
shell script, or the like, for our applications, any change to the base
OS is not going to happen. Including configuration changes.

And these ancient boxes run in data centres right next to the latest
systems from the various Intel and AMD purveyors, as well as the latest
SPARC64 and AIX and other systems, all owned by the same customers[1].

Our customers aren't in Oz, anything you think you might know about
supporting "difficult" customers is just not relevant. It took me years
to adjust to the attitude, I have now developed the skill of saying,
"That cannot happen", in a variety of polite ways. (Then I go outside
and scream!!) :-)

Cheers,
Gary B-)

1 - FSOV "owned". Leasing is often a preferred option at this level.

Gary R. Schmidt <grschmidt@acm.org> wrote:
> On 04/08/2022 09:13, Computer Nerd Kev wrote:
>> Gary R. Schmidt <grschmidt@acm.org> wrote:
> [SNIP]
>>
>>> At $ORK I am currently dealing with the problem of accessing Solaris
>>> 11.4 and RedHat 9 machines from ancient systems where the owners of said
>>> ancient systems are culturally incapable of accepting the need to
>>> update. Sigh.
>>
>> Many ways and means around that depending on the circumstances. I'm
>> posting from a Pentium 1 PC right now and am familiar with most of
>> them.
>>
> Not even vaguely equivalent to the problem of people who intend to run,
> for example, Solaris 8 on SPARC hardware, until it collapses into rust.
>
> And when I say, "incapable of accepting the need to update", I mean,
> never, ever, ever been patched.
>
> Despite having a full support contract with SUN-as-was and Oracle-as-is,
> and accepting (eventually) us supplying a new binary, shared object,
> shell script, or the like, for our applications, any change to the base
> OS is not going to happen. Including configuration changes.

As I mentioned one option may be to edit the configuration of the
OpenSSL client/server(/s) that connect _to_ the Solaris 8 system,
so that some of the older encryption/authentication methods
remain enabled for the newer client/server in spite of changed
defaults. But if the idea is to avoid compromising the security of
the other system/s, or it's/their configuration is outside your
control, that won't suit. Then you'd need to have some other system
that the older system connects to via old/unencrypted methods (eg.
Telnet instead of SSH) and the newer system runs the
newer/encrypted software to allow secure communication to/from it.
The old/unencrypted connection needs to be over a secure network of
course (it might even be practical to run it in an emulated system
on the same hardware, though I've never tried that).

--
__ __
#_ < |\| |< _#

On 4/08/2022 9:13 am, Computer Nerd Kev wrote:
> Gary R. Schmidt <grschmidt@acm.org> wrote:
>> On 03/08/2022 19:20, Max wrote:
>>> I have an issue with data transmission from one computer to another.
>>>
>>> An example of the issue is doing "scp" to copy a file between the
>>> computers. 1 time out of 10 it just hangs, and eventually times out,
>>> with this message:
>>>
>>> "ssh_exchange_identification: read: Connection timed out
>>> lost connection"
>>>
>>> This is an example of the issue. I am doing other things between the two
>>> computers, and it also times out.
>>>
>>> What could be the problem? What could I do to diagnose the issue? Things
>>> have been working for 6 months, now suddenly today it has stopped working.
>>
>> A recent update of OpenSSL/OpenSSH at either end can do this, when it
>> gets too "new".
>
> One time out of ten? That's not a problem that I've encountered.
> Errors such as "no matching cipher found" are the usual result of
> trying to connect an old client to an up-to-date SSH server, but
> this will by definition happen every time it is attempted between
> the same two computers, not just occasionally.
>
> Of course Max is bound to just be trolling anyway, I expect he's
> never scp'ed a file in his life and has just picked this out of a
> web forum somewhere. The problem itself is probably to do with a
> dodgy network connection or a network adapter driver issue.
> Especially if the scp problem is just one "example of the issue"
> of the problems communicating between these two computers.
>

Would a dodgy network connection or driver cause intermittent problems?
Roughly about 1 in every 5 attempts at "scp" brings about the problem.

The systems administrator will be restarting the problem server, so
we'll see how that goes.

I asked this question on a web forum and someone said that it might be a
firewall problem. Again, I would ask why the problem happens only
intermittently and not all the time.

>> If you run "scp" with "-vvv" it will tell you a lot about what is going on.
>>
>> Solving it without updating the offending end is not an easy problem.
>
> That depends on the software and just how old the client is of
> course, but with OpenSSH it can often be pretty easy to fix just
> by editing the settings in the configuration file. This is a
> security risk of course, but the defaults may be overly
> conservative for some usage cases.
>
>> At $ORK I am currently dealing with the problem of accessing Solaris
>> 11.4 and RedHat 9 machines from ancient systems where the owners of said
>> ancient systems are culturally incapable of accepting the need to
>> update. Sigh.
>
> Many ways and means around that depending on the circumstances. I'm
> posting from a Pentium 1 PC right now and am familiar with most of
> them.
>

On Thu, 4 Aug 2022 18:40:01 +1000, Max <max@val.morgan> wrote:

>On 4/08/2022 9:13 am, Computer Nerd Kev wrote:
>> Gary R. Schmidt <grschmidt@acm.org> wrote:
>>> On 03/08/2022 19:20, Max wrote:
>>>> I have an issue with data transmission from one computer to another.
>>>>
>>>> An example of the issue is doing "scp" to copy a file between the
>>>> computers. 1 time out of 10 it just hangs, and eventually times out,
>>>> with this message:
>>>>
>>>> "ssh_exchange_identification: read: Connection timed out
>>>> lost connection"
>>>>
>>>> This is an example of the issue. I am doing other things between the two
>>>> computers, and it also times out.
>>>>
>>>> What could be the problem? What could I do to diagnose the issue? Things
>>>> have been working for 6 months, now suddenly today it has stopped working.
>>>
>>> A recent update of OpenSSL/OpenSSH at either end can do this, when it
>>> gets too "new".
>>
>> One time out of ten? That's not a problem that I've encountered.
>> Errors such as "no matching cipher found" are the usual result of
>> trying to connect an old client to an up-to-date SSH server, but
>> this will by definition happen every time it is attempted between
>> the same two computers, not just occasionally.
>>
>> Of course Max is bound to just be trolling anyway, I expect he's
>> never scp'ed a file in his life and has just picked this out of a
>> web forum somewhere. The problem itself is probably to do with a
>> dodgy network connection or a network adapter driver issue.
>> Especially if the scp problem is just one "example of the issue"
>> of the problems communicating between these two computers.
>>
>
>Would a dodgy network connection or driver cause intermittent problems?
> Roughly about 1 in every 5 attempts at "scp" brings about the problem.
>
>The systems administrator will be restarting the problem server, so
>we'll see how that goes.
>
>I asked this question on a web forum and someone said that it might be a
>firewall problem. Again, I would ask why the problem happens only
>intermittently and not all the time.
>
What's the operating system?
>
>>> If you run "scp" with "-vvv" it will tell you a lot about what is going on.
>>>
>>> Solving it without updating the offending end is not an easy problem.
>>
>> That depends on the software and just how old the client is of
>> course, but with OpenSSH it can often be pretty easy to fix just
>> by editing the settings in the configuration file. This is a
>> security risk of course, but the defaults may be overly
>> conservative for some usage cases.
>>
>>> At $ORK I am currently dealing with the problem of accessing Solaris
>>> 11.4 and RedHat 9 machines from ancient systems where the owners of said
>>> ancient systems are culturally incapable of accepting the need to
>>> update. Sigh.
>>
>> Many ways and means around that depending on the circumstances. I'm
>> posting from a Pentium 1 PC right now and am familiar with most of
>> them.
>>
--
Petzl
If voting made any difference,
They wouldn't let us do it- Mark Twain