[Info-vax] SSH from VMS to 3Par

[Arne Vajhøj]

On 10/12/2021 1:19 PM, Simon Clubley wrote:
> On 2021-10-11, Arne Vajhøj <arne at vajhoej.dk> wrote:
>> On 10/11/2021 2:04 PM, Simon Clubley wrote:
>>> On 2021-10-11, Dave Froble <davef at tsoft-inc.com> wrote:
>>>> Hmmm ...  I was of the opinion the customer was always right?
>>>
>>> No. Sometimes the job of a vendor is to protect a customer from themselves
>>> especially in a litigation crazy country like yours.
>>>
>>> What would you expect the response from a chainsaw vendor to be if
>>> the customer asked for an attachment that would allow them to operate
>>> a chainsaw in a way that the vendor considered to be dangerous ?
>>
>> There is not really a need to use such an analogy.
>>
>> The problem is:
>>
>> debug(10-OCT-2021 16:31:40.82): Ssh2Transport/TRCOMMON.C:2142: Algorithm
>> negotiation failed for c_to_s_mac: client list:
>> hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96 vs. server list :
>> hmac-sha2-512-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512,hmac-sha2-256
>> debug(10-OCT-2021 16:31:40.82): Ssh2Transport/TRCOMMON.C:2142: Algorithm
>> negotiation failed for s_to_c_mac: client list:
>> hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96 vs. server list :
>> hmac-sha2-512-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512,hmac-sha2-256
>>
>> https://www.ssh.com/academy/ssh/sshd_config
>>
>> says:
>>
>> <quote>
>> Message authentication code algorithms are configured using the MACs
>> option. A good value is hmac-sha2-256,hmac-sha2-512,hmac-sha1.
>>
>> We have included the sha-1 algorithm in the above sets only for
>> compatibility. Its use is questionable from a security perspective. If
>> it is not needed for compatibility, we recommend disabling it.
>> </quote>
>>
>> The server setup is the recommended setup where compatibility is
>> not an issue. The server setup recommended when compatibility is
>> an issue should have worked.
> 
> In the example lines you quote above Arne, I don't see where hmac-sha1
> or any of the other client options are offered by the server.

That i sort of the point.

> It looks to me like HPE have strictly locked down the server configuration,

They have chose the config for when compatibility is not an issue.

> and, _if_ I am reading it correctly, asking them to unlock it takes us
> back to the chainsaw example of protecting the customer from themselves.

The authors of the software recommend supporting it for compatibility.
But HPE decided to be more strict.

So unless HPE happens to know the software better than the authors
of the software, then they are not being customer friendly.

Arne