has anybody done this successfully and how?

evidently the ciphers on both systems can't agree and close the connection.
is it doable if I have a key on both systems that I've generated on my pc?
and if so where do I place it on VMS? the 3Par has an add option.

thanks
Paul

On 2021-10-06 15:06:49 +0000, pcoviello@gmail.com said:

> has anybody done this successfully and how?
>
> evidently the ciphers on both systems can't agree and close the
> connection. is it doable if I have a key on both systems that I've
> generated on my pc? and if so where do I place it on VMS? the 3Par has
> an add option.

If you're not on V5.7 ECO5c or higher (ECO5o is current on Itanium, and
ECO5c is per-call on Alpha), get there, and try ssh again.

If things fail then, use ssh -vvvvvv and check the results of the
negotiation for the key exchange and the cipher from what is available
on both ends of whichever version of 3PAR and OpenVMS you're using here.

--
Pure Personal Opinion | HoffmanLabs LLC

On Wednesday, October 6, 2021 at 11:12:30 AM UTC-4, Stephen Hoffman wrote:
> On 2021-10-06 15:06:49 +0000, pcov...@gmail.com said:
>
> > has anybody done this successfully and how?
> >
> > evidently the ciphers on both systems can't agree and close the
> > connection. is it doable if I have a key on both systems that I've
> > generated on my pc? and if so where do I place it on VMS? the 3Par has
> > an add option.
> If you're not on V5.7 ECO5c or higher (ECO5o is current on Itanium, and
> ECO5c is per-call on Alpha), get there, and try ssh again.
>
> If things fail then, use ssh -vvvvvv and check the results of the
> negotiation for the key exchange and the cipher from what is available
> on both ends of whichever version of 3PAR and OpenVMS you're using here.
>
>
> --
> Pure Personal Opinion | HoffmanLabs LLC

thanks I'll look for it, why didn't anyone from VSI recommend this when I called it in. sigh
I'm on VSI I64VMS TCPIP V5.7-13ECO5B
and I have the latest SSH patch too.

On 2021-10-06 16:13:02 +0000, pcoviello@gmail.com said:

> On Wednesday, October 6, 2021 at 11:12:30 AM UTC-4, Stephen Hoffman wrote:
>> On 2021-10-06 15:06:49 +0000, pcov...@gmail.com said:
>>
>>> has anybody done this successfully and how?
>>>
>>> evidently the ciphers on both systems can't agree and close the
>>> connection. is it doable if I have a key on both systems that I've
>>> generated on my pc? and if so where do I place it on VMS? the 3Par has
>>> an add option.
>>
>> If you're not on V5.7 ECO5c or higher (ECO5o is current on Itanium, and
>> ECO5c is per-call on Alpha), get there, and try ssh again.
>>
>> If things fail then, use ssh -vvvvvv and check the results of the
>> negotiation for the key exchange and the cipher from what is available
>> on both ends of whichever version of 3PAR and OpenVMS you're using here.
>
> thanks I'll look for it, why didn't anyone from VSI recommend this when
> I called it in. sigh
> I'm on VSI I64VMS TCPIP V5.7-13ECO5B and I have the latest SSH patch too.

Why doesn't OpenVMS itself notify the system administrator^Wmanager
that the server is down-revision? Sigh. Alas, we all get to track this
manually, or with our own tooling. VSI does have some new tool arriving
here, though details are sparse.

One VSI ssh patch featured an interesting collection of directions, and
the installation instructions were, well, in conflict with the provided
files. That boo-boo won't hit your case here, though.

Fetch ECO5o from the VSI patch server if that's not already installed,
and try ssh again.

Then ssh -vvvvv and check for the details of the negotiation failure,
if an error arises.

--
Pure Personal Opinion | HoffmanLabs LLC

On 06/10/2021 17:26, Stephen Hoffman wrote:
> On 2021-10-06 16:13:02 +0000, pcoviello@gmail.com said:
>
>> On Wednesday, October 6, 2021 at 11:12:30 AM UTC-4, Stephen Hoffman
>> wrote:
>>> On 2021-10-06 15:06:49 +0000, pcov...@gmail.com said:
>>>
>>>> has anybody done this successfully and how?
>>>>
>>>> evidently the ciphers on both systems can't agree and close the
>>>> connection. is it doable if I have a key on both systems that I've
>>>> generated on my pc? and if so where do I place it on VMS? the 3Par
>>>> has an add option.
>>>
>>> If you're not on V5.7 ECO5c or higher (ECO5o is current on Itanium,
>>> and ECO5c is per-call on Alpha), get there, and try ssh again.
>>>
>>> If things fail then, use ssh -vvvvvv and check the results of the
>>> negotiation for the key exchange and the cipher from what is
>>> available on both ends of whichever version of 3PAR and OpenVMS
>>> you're using here.
>>
>> thanks I'll look for it, why didn't anyone from VSI recommend this
>> when I called it in. sigh
>> I'm on VSI I64VMS TCPIP V5.7-13ECO5B  and I have the latest SSH patch
>> too.
>
> Why doesn't OpenVMS itself notify the system administrator^Wmanager that
> the server is down-revision?  Sigh. Alas, we all get to track this
> manually, or with our own tooling. VSI does have some new tool arriving
> here, though details are sparse.
>
> One VSI ssh patch featured an interesting collection of directions, and
> the installation instructions were, well, in conflict with the provided
> files. That boo-boo won't hit your case here, though.
>
> Fetch ECO5o from the VSI patch server if that's not already installed,
> and try ssh again.
>
> Then ssh -vvvvv and check for the details of the negotiation failure, if
> an error arises.
>

I moved my hobbyist Alpha onto TCPWare partially for this. Works for me!

Chris

--
Chris

On 10/6/2021 12:26 PM, Stephen Hoffman wrote:
> On 2021-10-06 16:13:02 +0000, pcoviello@gmail.com said:
>
>> On Wednesday, October 6, 2021 at 11:12:30 AM UTC-4, Stephen Hoffman
>> wrote:
>>> On 2021-10-06 15:06:49 +0000, pcov...@gmail.com said:
>>>
>>>> has anybody done this successfully and how?
>>>>
>>>> evidently the ciphers on both systems can't agree and close the
>>>> connection. is it doable if I have a key on both systems that I've
>>>> generated on my pc? and if so where do I place it on VMS? the 3Par
>>>> has an add option.
>>>
>>> If you're not on V5.7 ECO5c or higher (ECO5o is current on Itanium,
>>> and ECO5c is per-call on Alpha), get there, and try ssh again.
>>>
>>> If things fail then, use ssh -vvvvvv and check the results of the
>>> negotiation for the key exchange and the cipher from what is
>>> available on both ends of whichever version of 3PAR and OpenVMS
>>> you're using here.
>>
>> thanks I'll look for it, why didn't anyone from VSI recommend this
>> when I called it in. sigh
>> I'm on VSI I64VMS TCPIP V5.7-13ECO5B and I have the latest SSH patch
>> too.
>
> Why doesn't OpenVMS itself notify the system administrator^Wmanager that
> the server is down-revision? Sigh. Alas, we all get to track this
> manually, or with our own tooling. VSI does have some new tool arriving
> here, though details are sparse.
>
> One VSI ssh patch featured an interesting collection of directions, and
> the installation instructions were, well, in conflict with the provided
> files. That boo-boo won't hit your case here, though.
>
> Fetch ECO5o from the VSI patch server if that's not already installed,
> and try ssh again.

After applying ECO5O I was able to access via SFTP systems with the
latest encryption. At least for a couple of weeks until newer stuff
gets used.

:-)

> Then ssh -vvvvv and check for the details of the negotiation failure, if
> an error arises.
>
>
>

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On Wednesday, October 6, 2021 at 3:19:25 PM UTC-4, Dave Froble wrote:
> On 10/6/2021 12:26 PM, Stephen Hoffman wrote:
> > On 2021-10-06 16:13:02 +0000, pcov...@gmail.com said:
> >
> >> On Wednesday, October 6, 2021 at 11:12:30 AM UTC-4, Stephen Hoffman
> >> wrote:
> >>> On 2021-10-06 15:06:49 +0000, pcov...@gmail.com said:
> >>>
> >>>> has anybody done this successfully and how?
> >>>>
> >>>> evidently the ciphers on both systems can't agree and close the
> >>>> connection. is it doable if I have a key on both systems that I've
> >>>> generated on my pc? and if so where do I place it on VMS? the 3Par
> >>>> has an add option.
> >>>
> >>> If you're not on V5.7 ECO5c or higher (ECO5o is current on Itanium,
> >>> and ECO5c is per-call on Alpha), get there, and try ssh again.
> >>>
> >>> If things fail then, use ssh -vvvvvv and check the results of the
> >>> negotiation for the key exchange and the cipher from what is
> >>> available on both ends of whichever version of 3PAR and OpenVMS
> >>> you're using here.
> >>
> >> thanks I'll look for it, why didn't anyone from VSI recommend this
> >> when I called it in. sigh
> >> I'm on VSI I64VMS TCPIP V5.7-13ECO5B and I have the latest SSH patch
> >> too.
> >
> > Why doesn't OpenVMS itself notify the system administrator^Wmanager that
> > the server is down-revision? Sigh. Alas, we all get to track this
> > manually, or with our own tooling. VSI does have some new tool arriving
> > here, though details are sparse.
> >
> > One VSI ssh patch featured an interesting collection of directions, and
> > the installation instructions were, well, in conflict with the provided
> > files. That boo-boo won't hit your case here, though.
> >
> > Fetch ECO5o from the VSI patch server if that's not already installed,
> > and try ssh again.
> After applying ECO5O I was able to access via SFTP systems with the
> latest encryption. At least for a couple of weeks until newer stuff
> gets used.
>
> :-)
> > Then ssh -vvvvv and check for the details of the negotiation failure, if
> > an error arises.
> >
> >
> >
>
>
> --
> David Froble Tel: 724-529-0450
> Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
> DFE Ultralights, Inc.
> 170 Grimplin Road
> Vanderbilt, PA 15486

PRODUCT KIT TYPE OPERATION VAL DATE
------------------------------------ ----------- ----------- --- -----------
VSI I64VMS TCPIP_PAT V5.7-ECO5O Patch Install Val 10-OCT-2021

installed the latest and same results sigh

$ ssh 3paradm@10.128.20.13
warning: Authentication failed.
Disconnected; key exchange or algorithm negotiation failed (Algorithm negotiation failed.).

$ ssh 3paradm@10.128.20.13 -v
debug(10-OCT-2021 16:31:40.80): Connecting to 10.128.20.13, port 22... (SOCKS not used)
debug(10-OCT-2021 16:31:40.80): Ssh2/SSH2.C:2897: Entering event loop.
debug(10-OCT-2021 16:31:40.81): Ssh2Client/SSHCLIENT.C:1666: Creating transport protocol.
debug(10-OCT-2021 16:31:40.81): SshAuthMethodClient/SSHAUTHMETHODC.C:104: Added "hostbased" to usable methods.
debug(10-OCT-2021 16:31:40.81): SshAuthMethodClient/SSHAUTHMETHODC.C:104: Added "publickey" to usable methods.
debug(10-OCT-2021 16:31:40.81): SshAuthMethodClient/SSHAUTHMETHODC.C:104: Added "password" to usable methods.
debug(10-OCT-2021 16:31:40.81): Ssh2Client/SSHCLIENT.C:1707: Creating userauth protocol.
debug(10-OCT-2021 16:31:40.81): client supports 3 auth methods: 'hostbased,publickey,password'
debug(10-OCT-2021 16:31:40.81): SshUnixTcp/SSHUNIXTCP.C:1758: using local hostname facst1.ccsusa.com
debug(10-OCT-2021 16:31:40.81): Ssh2Common/SSHCOMMON.C:541: local ip = 10.128.18.15, local port = 49182
debug(10-OCT-2021 16:31:40.81): Ssh2Common/SSHCOMMON.C:543: remote ip = 10.128.20.13, remote port = 22
debug(10-OCT-2021 16:31:40.81): SshConnection/SSHCONN.C:2601: Wrapping...
debug(10-OCT-2021 16:31:40.81): SshReadLine/SSHREADLINE.C:3662: Initializing ReadLine...
debug(10-OCT-2021 16:31:40.81): Remote version: SSH-2.0-OpenSSH_7.5p1 Debian-5
debug(10-OCT-2021 16:31:40.81): OpenSSH: Major: 7 Minor: 5 Revision: 0
debug(10-OCT-2021 16:31:40.81): Ssh2Transport/TRCOMMON.C:1876: All versions of OpenSSH handle kex guesses incorrectly.
debug(10-OCT-2021 16:31:40.81): Ssh2Transport/TRCOMMON.C:1954: Using Client order for common key exchange algorithms.
debug(10-OCT-2021 16:31:40.81): Ssh2Transport/TRCOMMON.C:3631: local kexinit: kex algs = diffie-hellman-group14-sha1,diffie-hellman-
group1-sha1
debug(10-OCT-2021 16:31:40.82): Ssh2Transport/TRCOMMON.C:1154: Sending packet with type 2 to connection
debug(10-OCT-2021 16:31:40.82): Ssh2Transport/TRCOMMON.C:1154: Sending packet with type 20 to connection
debug(10-OCT-2021 16:31:40.82): Ssh2Transport/TRCOMMON.C:2854: >TR packet_type=20
debug(10-OCT-2021 16:31:40.82): Ssh2Transport/TRCOMMON.C:2197: Computing algorithms from key exchange.
debug(10-OCT-2021 16:31:40.82): Ssh2Transport/TRCOMMON.C:2260: client: kex = diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,
hk_alg = ssh-dss,ssh-rsa,x509v3-sign-dss,x509v3-sign-rsa
debug(10-OCT-2021 16:31:40.82): Ssh2Transport/TRCOMMON.C:2262: server: kex = diffie-hellman-group-exchange-sha256, hk_alg = ssh-rsa,
rsa-sha2-512,rsa-sha2-256
debug(10-OCT-2021 16:31:40.82): Ssh2Transport/TRCOMMON.C:2142: Algorithm negotiation failed for c_to_s_mac: client list: hmac-sha1,h
mac-sha1-96,hmac-md5,hmac-md5-96 vs. server list : hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sh
a2-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,h
mac-sha1-96,hmac-md5,hmac-md5-96 vs. server list : hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sh
a2-256
debug(10-OCT-2021 16:31:40.82): Ssh2Transport/TRCOMMON.C:2413: lang s to c: `', lang c to s: `'
debug(10-OCT-2021 16:31:40.82): Ssh2Transport/TRCOMMON.C:2429: Couldn't agree on kex or hostkey alg. (chosen_kex = NULL, chosen_host
_key = ssh-rsa)
debug(10-OCT-2021 16:31:40.82): Ssh2Transport/TRCOMMON.C:1154: Sending packet with type 2 to connection
debug(10-OCT-2021 16:31:40.82): Ssh2Transport/TRCOMMON.C:1154: Sending packet with type 1 to connection
debug(10-OCT-2021 16:31:40.82): Ssh2Common/SSHCOMMON.C:180: DISCONNECT received: Algorithm negotiation failed.
debug(10-OCT-2021 16:31:40.82): SshReadLine/SSHREADLINE.C:3728: Uninitializing ReadLine...
warning: Authentication failed.
debug(10-OCT-2021 16:31:40.82): Ssh2/SSH2.C:331: locally_generated = TRUE
Disconnected; key exchange or algorithm negotiation failed (Algorithm negotiation failed.).

debug(10-OCT-2021 16:31:40.82): Ssh2Client/SSHCLIENT.C:1742: Destroying client.
debug(10-OCT-2021 16:31:40.82): SshConfig/SSHCONFIG.C:2949: Freeing pki. (host_pki != NULL, user_pki = NULL)
debug(10-OCT-2021 16:31:40.82): SshConnection/SSHCONN.C:2653: Destroying SshConn object.
debug(10-OCT-2021 16:31:40.82): Ssh2Client/SSHCLIENT.C:1810: Destroying client completed.
debug(10-OCT-2021 16:31:40.82): SshAuthMethodClient/SSHAUTHMETHODC.C:109: Destroying authentication method array.
debug(10-OCT-2021 16:31:40.82): SshAppCommon/SSHAPPCOMMON.C:326: Freeing global SshRegex context.
debug(10-OCT-2021 16:31:40.82): SshConfig/SSHCONFIG.C:2949: Freeing pki. (host_pki = NULL, user_pki = NULL)

$

Den 2021-10-10 kl. 22:40, skrev pcoviello@gmail.com:
> On Wednesday, October 6, 2021 at 3:19:25 PM UTC-4, Dave Froble wrote:
>> On 10/6/2021 12:26 PM, Stephen Hoffman wrote:
>>> On 2021-10-06 16:13:02 +0000, pcov...@gmail.com said:
>>>
>>>> On Wednesday, October 6, 2021 at 11:12:30 AM UTC-4, Stephen Hoffman
>>>> wrote:
>>>>> On 2021-10-06 15:06:49 +0000, pcov...@gmail.com said:
>>>>>
>>>>>> has anybody done this successfully and how?
>>>>>>
>>>>>> evidently the ciphers on both systems can't agree and close the
>>>>>> connection. is it doable if I have a key on both systems that I've
>>>>>> generated on my pc? and if so where do I place it on VMS? the 3Par
>>>>>> has an add option.
>>>>>
>>>>> If you're not on V5.7 ECO5c or higher (ECO5o is current on Itanium,
>>>>> and ECO5c is per-call on Alpha), get there, and try ssh again.
>>>>>
>>>>> If things fail then, use ssh -vvvvvv and check the results of the
>>>>> negotiation for the key exchange and the cipher from what is
>>>>> available on both ends of whichever version of 3PAR and OpenVMS
>>>>> you're using here.
>>>>
>>>> thanks I'll look for it, why didn't anyone from VSI recommend this
>>>> when I called it in. sigh
>>>> I'm on VSI I64VMS TCPIP V5.7-13ECO5B and I have the latest SSH patch
>>>> too.
>>>
>>> Why doesn't OpenVMS itself notify the system administrator^Wmanager that
>>> the server is down-revision? Sigh. Alas, we all get to track this
>>> manually, or with our own tooling. VSI does have some new tool arriving
>>> here, though details are sparse.
>>>
>>> One VSI ssh patch featured an interesting collection of directions, and
>>> the installation instructions were, well, in conflict with the provided
>>> files. That boo-boo won't hit your case here, though.
>>>
>>> Fetch ECO5o from the VSI patch server if that's not already installed,
>>> and try ssh again.
>> After applying ECO5O I was able to access via SFTP systems with the
>> latest encryption. At least for a couple of weeks until newer stuff
>> gets used.
>>
>> :-)
>>> Then ssh -vvvvv and check for the details of the negotiation failure, if
>>> an error arises.
>>>
>>>
>>>
>>
>>
>> --
>> David Froble Tel: 724-529-0450
>> Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
>> DFE Ultralights, Inc.
>> 170 Grimplin Road
>> Vanderbilt, PA 15486
>
> PRODUCT KIT TYPE OPERATION VAL DATE
> ------------------------------------ ----------- ----------- --- -----------
> VSI I64VMS TCPIP_PAT V5.7-ECO5O Patch Install Val 10-OCT-2021
>
> installed the latest and same results sigh
>
> $ ssh 3paradm@10.128.20.13
> warning: Authentication failed.
> Disconnected; key exchange or algorithm negotiation failed (Algorithm negotiation failed.).
>
>
>
> $ ssh 3paradm@10.128.20.13 -v
> debug(10-OCT-2021 16:31:40.80): Connecting to 10.128.20.13, port 22... (SOCKS not used)
> debug(10-OCT-2021 16:31:40.80): Ssh2/SSH2.C:2897: Entering event loop.
> debug(10-OCT-2021 16:31:40.81): Ssh2Client/SSHCLIENT.C:1666: Creating transport protocol.
> debug(10-OCT-2021 16:31:40.81): SshAuthMethodClient/SSHAUTHMETHODC.C:104: Added "hostbased" to usable methods.
> debug(10-OCT-2021 16:31:40.81): SshAuthMethodClient/SSHAUTHMETHODC.C:104: Added "publickey" to usable methods.
> debug(10-OCT-2021 16:31:40.81): SshAuthMethodClient/SSHAUTHMETHODC.C:104: Added "password" to usable methods.
> debug(10-OCT-2021 16:31:40.81): Ssh2Client/SSHCLIENT.C:1707: Creating userauth protocol.
> debug(10-OCT-2021 16:31:40.81): client supports 3 auth methods: 'hostbased,publickey,password'
> debug(10-OCT-2021 16:31:40.81): SshUnixTcp/SSHUNIXTCP.C:1758: using local hostname facst1.ccsusa.com
> debug(10-OCT-2021 16:31:40.81): Ssh2Common/SSHCOMMON.C:541: local ip = 10.128.18.15, local port = 49182
> debug(10-OCT-2021 16:31:40.81): Ssh2Common/SSHCOMMON.C:543: remote ip = 10.128.20.13, remote port = 22
> debug(10-OCT-2021 16:31:40.81): SshConnection/SSHCONN.C:2601: Wrapping...
> debug(10-OCT-2021 16:31:40.81): SshReadLine/SSHREADLINE.C:3662: Initializing ReadLine...
> debug(10-OCT-2021 16:31:40.81): Remote version: SSH-2.0-OpenSSH_7.5p1 Debian-5
> debug(10-OCT-2021 16:31:40.81): OpenSSH: Major: 7 Minor: 5 Revision: 0
> debug(10-OCT-2021 16:31:40.81): Ssh2Transport/TRCOMMON.C:1876: All versions of OpenSSH handle kex guesses incorrectly.
> debug(10-OCT-2021 16:31:40.81): Ssh2Transport/TRCOMMON.C:1954: Using Client order for common key exchange algorithms.
> debug(10-OCT-2021 16:31:40.81): Ssh2Transport/TRCOMMON.C:3631: local kexinit: kex algs = diffie-hellman-group14-sha1,diffie-hellman-
> group1-sha1
> debug(10-OCT-2021 16:31:40.82): Ssh2Transport/TRCOMMON.C:1154: Sending packet with type 2 to connection
> debug(10-OCT-2021 16:31:40.82): Ssh2Transport/TRCOMMON.C:1154: Sending packet with type 20 to connection
> debug(10-OCT-2021 16:31:40.82): Ssh2Transport/TRCOMMON.C:2854: >TR packet_type=20
> debug(10-OCT-2021 16:31:40.82): Ssh2Transport/TRCOMMON.C:2197: Computing algorithms from key exchange.
> debug(10-OCT-2021 16:31:40.82): Ssh2Transport/TRCOMMON.C:2260: client: kex = diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,
> hk_alg = ssh-dss,ssh-rsa,x509v3-sign-dss,x509v3-sign-rsa
> debug(10-OCT-2021 16:31:40.82): Ssh2Transport/TRCOMMON.C:2262: server: kex = diffie-hellman-group-exchange-sha256, hk_alg = ssh-rsa,
> rsa-sha2-512,rsa-sha2-256
> debug(10-OCT-2021 16:31:40.82): Ssh2Transport/TRCOMMON.C:2142: Algorithm negotiation failed for c_to_s_mac: client list: hmac-sha1,h
> mac-sha1-96,hmac-md5,hmac-md5-96 vs. server list : hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sh
> a2-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,h
> mac-sha1-96,hmac-md5,hmac-md5-96 vs. server list : hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sh
> a2-256
> debug(10-OCT-2021 16:31:40.82): Ssh2Transport/TRCOMMON.C:2413: lang s to c: `', lang c to s: `'
> debug(10-OCT-2021 16:31:40.82): Ssh2Transport/TRCOMMON.C:2429: Couldn't agree on kex or hostkey alg. (chosen_kex = NULL, chosen_host
> _key = ssh-rsa)
> debug(10-OCT-2021 16:31:40.82): Ssh2Transport/TRCOMMON.C:1154: Sending packet with type 2 to connection
> debug(10-OCT-2021 16:31:40.82): Ssh2Transport/TRCOMMON.C:1154: Sending packet with type 1 to connection
> debug(10-OCT-2021 16:31:40.82): Ssh2Common/SSHCOMMON.C:180: DISCONNECT received: Algorithm negotiation failed.
> debug(10-OCT-2021 16:31:40.82): SshReadLine/SSHREADLINE.C:3728: Uninitializing ReadLine...
> warning: Authentication failed.
> debug(10-OCT-2021 16:31:40.82): Ssh2/SSH2.C:331: locally_generated = TRUE
> Disconnected; key exchange or algorithm negotiation failed (Algorithm negotiation failed.).
>
> debug(10-OCT-2021 16:31:40.82): Ssh2Client/SSHCLIENT.C:1742: Destroying client.
> debug(10-OCT-2021 16:31:40.82): SshConfig/SSHCONFIG.C:2949: Freeing pki. (host_pki != NULL, user_pki = NULL)
> debug(10-OCT-2021 16:31:40.82): SshConnection/SSHCONN.C:2653: Destroying SshConn object.
> debug(10-OCT-2021 16:31:40.82): Ssh2Client/SSHCLIENT.C:1810: Destroying client completed.
> debug(10-OCT-2021 16:31:40.82): SshAuthMethodClient/SSHAUTHMETHODC.C:109: Destroying authentication method array.
> debug(10-OCT-2021 16:31:40.82): SshAppCommon/SSHAPPCOMMON.C:326: Freeing global SshRegex context.
> debug(10-OCT-2021 16:31:40.82): SshConfig/SSHCONFIG.C:2949: Freeing pki. (host_pki = NULL, user_pki = NULL)
>
> $
>

Just asking...
What is the reason that you *need* to access the 3Par system from VMS?
Cannot the 3Par system be accessed directly from your desktop system?

On 2021-10-10 20:40:49 +0000, pcoviello@gmail.com said:

Here's the error:

> 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@openssh.com,hmac-sha2-256etm@openssh.com,hmac-sha2-512,hmac-sha2-256
>

V5.7 ECO5o MAC support is too archaic for the 3PAR ssh server.

Contact VSI, and escalate.

Pending a fix for MAC support or pending the availability of the VSI
OpenSSH port for OpenVMS, use some other box to contact the 3PAR box.
Or see if there's a way to widen the tolerance for archaic MACs on the
3PAR server.

--
Pure Personal Opinion | HoffmanLabs LLC

Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>On 2021-10-10 20:40:49 +0000, pcoviello@gmail.com said:
>
>Here's the error:
>
>> 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@openssh.com,hmac-sha2-256etm@openssh.com,hmac-sha2-512,hmac-sha2-256
>>
>
>V5.7 ECO5o MAC support is too archaic for the 3PAR ssh server.
>
>Contact VSI, and escalate.

My bet is that you could probably edit the sshd_conf file on the 3PAR
to force it to accept hmac-sha1-96. I wouldn't want to do that on anything
touching the outside world and I might be a little nervous about doing that
on something touching a corporate network, but if it's a private net I don't
see why not to do it.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

In article <sjvkcl$1kr$3@dont-email.me>,
=?UTF-8?Q?Jan-Erik_S=c3=b6derholm?= <jan-erik.soderholm@telia.com>
writes:

> Just asking...
> What is the reason that you *need* to access the 3Par system from VMS?
> Cannot the 3Par system be accessed directly from your desktop system?

Maybe VMS is the desktop system? Maybe there is no desktop system?
Maybe there is the expectation that VMS should have up-to-date SSH?

Den 2021-10-11 kl. 07:44, skrev Phillip Helbig (undress to reply):
> In article <sjvkcl$1kr$3@dont-email.me>,
> =?UTF-8?Q?Jan-Erik_S=c3=b6derholm?= <jan-erik.soderholm@telia.com>
> writes:
>
>> Just asking...
>> What is the reason that you *need* to access the 3Par system from VMS?
>> Cannot the 3Par system be accessed directly from your desktop system?
>
> Maybe VMS is the desktop system?

Now, with an 3Par in the picture, I do not expect this to be a cellar
hobbyist environment. And I expect some professional guy at the desktop.

> Maybe there is no desktop system?

Highly unlikely.

> Maybe there is the expectation that VMS should have up-to-date SSH?

Sure! But maybe that expectation is not fullfilled. So what do you do?
Coninue fighting the windmills or take the easy route?

On Monday, October 11, 2021 at 2:17:26 AM UTC-4, Jan-Erik Söderholm wrote:
> Den 2021-10-11 kl. 07:44, skrev Phillip Helbig (undress to reply):
> > In article <sjvkcl$1kr$3...@dont-email.me>,
> > =?UTF-8?Q?Jan-Erik_S=c3=b6derholm?= <jan-erik....@telia.com>
> > writes:
> >
> >> Just asking...
> >> What is the reason that you *need* to access the 3Par system from VMS?
> >> Cannot the 3Par system be accessed directly from your desktop system?
> >
> > Maybe VMS is the desktop system?
> Now, with an 3Par in the picture, I do not expect this to be a cellar
> hobbyist environment. And I expect some professional guy at the desktop.
> > Maybe there is no desktop system?
> Highly unlikely.
> > Maybe there is the expectation that VMS should have up-to-date SSH?
> Sure! But maybe that expectation is not fullfilled. So what do you do?
> Coninue fighting the windmills or take the easy route?

ok I hope I capture all the questions and comments with my replies.

Steve, VSI's response was they were at the standard and 3Par was above. there is a SSH patch in test right now.

Scott if I knew where to find it and was able to edit the sshd_conf file I would.

Jan-Erik the reason I need access is that I'm running Cache on here and I freeze my DB's and take snapshots then thaw out the DB's and mount the snaps and then do the backups.

as soon as I figure out how to login without the password yes I can use an intermediary system and run it all in batch vs. manual

let me know if I missed something or you have more questions

thanks
Paul

pcoviello@gmail.com <pcoviello@gmail.com> wrote:
>Scott if I knew where to find it and was able to edit the sshd_conf file I =
>would.

It's in /etc/ssh/sshd_config. If you do a man on sshd, it will explain
how the daemon works and how it is configured. If you do a man on sshd_config
it will explain the configuration for different encryption algorithms although
of course they need to be built into the binary for you to enable them.
I am very surprised the 3par people have not suggested this.

All of this stuff is configurable! You don't have to use the defaults although
it's often wise to do so.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On Monday, October 11, 2021 at 9:58:00 AM UTC-4, Scott Dorsey wrote:
> pcov...@gmail.com <pcov...@gmail.com> wrote:
> >Scott if I knew where to find it and was able to edit the sshd_conf file I =
> >would.
>
> It's in /etc/ssh/sshd_config. If you do a man on sshd, it will explain
> how the daemon works and how it is configured. If you do a man on sshd_config
> it will explain the configuration for different encryption algorithms although
> of course they need to be built into the binary for you to enable them.
> I am very surprised the 3par people have not suggested this.
>
> All of this stuff is configurable! You don't have to use the defaults although
> it's often wise to do so.
> --scott
> --
> "C'est un Nagra. C'est suisse, et tres, tres precis."
thanks though I don't recall having access to that level.

HPE wanted no part of downgrading the ciphers or a work around for this.

On Monday, October 11, 2021 at 9:58:00 AM UTC-4, Scott Dorsey wrote:
> pcov...@gmail.com <pcov...@gmail.com> wrote:
> >Scott if I knew where to find it and was able to edit the sshd_conf file I =
> >would.
>
> It's in /etc/ssh/sshd_config. If you do a man on sshd, it will explain
> how the daemon works and how it is configured. If you do a man on sshd_config
> it will explain the configuration for different encryption algorithms although
> of course they need to be built into the binary for you to enable them.
> I am very surprised the 3par people have not suggested this.
>
> All of this stuff is configurable! You don't have to use the defaults although
> it's often wise to do so.
> --scott
> --
> "C'est un Nagra. C'est suisse, et tres, tres precis."

well this is what I thought.

FACSSAN1 cli% pwd
/ FACSSAN1 cli% cd /etc/ssh
couldn't change working directory to "/etc/ssh": no such file or directory
FACSSAN1 cli% cd /etc
FACSSAN1 cli% pwd
/etc
FACSSAN1 cli% ls
invalid command name "ls"
FACSSAN1 cli% dir
invalid command name "dir"
FACSSAN1 cli% cd ssh
couldn't change working directory to "ssh": no such file or directory
FACSSAN1 cli%

On Monday, October 11, 2021 at 10:48:43 AM UTC-4, pcoviello@gmail.com wrote:
> On Monday, October 11, 2021 at 9:58:00 AM UTC-4, Scott Dorsey wrote:
> > pcov...@gmail.com <pcov...@gmail.com> wrote:
> > >Scott if I knew where to find it and was able to edit the sshd_conf file I =
> > >would.
> >
> > It's in /etc/ssh/sshd_config. If you do a man on sshd, it will explain
> > how the daemon works and how it is configured. If you do a man on sshd_config
> > it will explain the configuration for different encryption algorithms although
> > of course they need to be built into the binary for you to enable them.
> > I am very surprised the 3par people have not suggested this.
> >
> > All of this stuff is configurable! You don't have to use the defaults although
> > it's often wise to do so.
> > --scott
> > --
> > "C'est un Nagra. C'est suisse, et tres, tres precis."
> well this is what I thought.
>
> FACSSAN1 cli% pwd
> /
> FACSSAN1 cli% cd /etc/ssh
> couldn't change working directory to "/etc/ssh": no such file or directory
> FACSSAN1 cli% cd /etc
> FACSSAN1 cli% pwd
> /etc
> FACSSAN1 cli% ls
> invalid command name "ls"
> FACSSAN1 cli% dir
> invalid command name "dir"
> FACSSAN1 cli% cd ssh
> couldn't change working directory to "ssh": no such file or directory
> FACSSAN1 cli%

also this is what I'm being told is what is in test right now.

Here is the list of supported encryptions on OpenSSH for OpenVMS:

debug2: ciphers ctos: chacha20-poly1305@openssh.com, aes128-ctr,aes192-ctr,aes256-ctr, aes128-gcm@openssh.com, aes256-gcm@openssh.com

debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diff
ie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-he
llman-group14-sha1,diffie-hellman-group1-sha1,ext-info-c

debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac
-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1

On 10/11/2021 2:17 AM, Jan-Erik Söderholm wrote:
> Den 2021-10-11 kl. 07:44, skrev Phillip Helbig (undress to reply):
>> In article <sjvkcl$1kr$3@dont-email.me>,
>> =?UTF-8?Q?Jan-Erik_S=c3=b6derholm?= <jan-erik.soderholm@telia.com>
>> writes:
>>
>>> Just asking...
>>> What is the reason that you *need* to access the 3Par system from VMS?
>>> Cannot the 3Par system be accessed directly from your desktop system?
>>
>> Maybe VMS is the desktop system?
>
> Now, with an 3Par in the picture, I do not expect this to be a cellar
> hobbyist environment. And I expect some professional guy at the desktop.
>
>> Maybe there is no desktop system?
>
> Highly unlikely.
>
>> Maybe there is the expectation that VMS should have up-to-date SSH?
>
> Sure! But maybe that expectation is not fullfilled. So what do you do?
> Coninue fighting the windmills or take the easy route?

Oh, Jan-Erik, Phillip will forever be fighting windmills.

:-)

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 2021-10-11 14:45:24 +0000, pcoviello@gmail.com said:

> thanks though I don't recall having access to that level.
>
> HPE wanted no part of downgrading the ciphers or a work around for this.

From what HPE has published for this change (HPE 3PAR OS 3.3.1 GA
Release Notes, pages 14 and 15, HPE Issue IDs 146489, 146490) (and
technical writing errors in that HPE doc aside), there is no published
ssh negotiation downgrade procedure.

Symptoms: SSH access to the array may be impacted when using clients
which were used with prior versions of HPE 3PAR OS.
Conditions of occurrence: Updating to 3.3.1GA or later and attempting
to use an older SSH cypher.
Impact: High
Customer circumvention: None
Customer recovery steps: SSH Client update or configuration.

That "none" there doesn't give me much hope for circumvention; for
KEX/cipher/MAC downgrades.

Pending VSI changes to OpenVMS ssh or the VSI OpenSSH port, you're
seemingly left using a different ssh client and quite possibly from a
different host, or finding an alternative path for whatever 3PAR
storage management access or reconfiguration you're here seeking. Maybe
via cURL and HTTPS, for instance? Or learning about and possibly
reverse-engineering 3PAR sufficiently to find whether the ssh KEX,
Ciphers, and MAC can be user-configured, though I'm not particularly
hopeful there.

A quick search of the 3PAR CLI manual was not promising.

While it does not discuss ssh downgrades, the following does discuss
how HPE implements 3PAR StorageServ security, including "HPE 3PAR
Central": https://www.hpe.com/psnow/doc/4AA3-7592ENW.pdf

--
Pure Personal Opinion | HoffmanLabs LLC

On 10/11/2021 10:45 AM, pcoviello@gmail.com wrote:
> On Monday, October 11, 2021 at 9:58:00 AM UTC-4, Scott Dorsey wrote:
>> pcov...@gmail.com <pcov...@gmail.com> wrote:
>>> Scott if I knew where to find it and was able to edit the sshd_conf file I =
>>> would.
>>
>> It's in /etc/ssh/sshd_config. If you do a man on sshd, it will explain
>> how the daemon works and how it is configured. If you do a man on sshd_config
>> it will explain the configuration for different encryption algorithms although
>> of course they need to be built into the binary for you to enable them.
>> I am very surprised the 3par people have not suggested this.
>>
>> All of this stuff is configurable! You don't have to use the defaults although
>> it's often wise to do so.
>> --scott
>> --
>> "C'est un Nagra. C'est suisse, et tres, tres precis."
> thanks though I don't recall having access to that level.
>
> HPE wanted no part of downgrading the ciphers or a work around for this.
>

Hmmm ... I was of the opinion the customer was always right?

Then there is HPe, "give us your money, but don't expect anything for
it". Perhaps the next time you're purchasing anything, want no part of HPe?

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 2021-10-11 13:36:02 +0000, pcoviello@gmail.com said:

> Steve, VSI's response was they were at the standard and 3Par was above.
> there is a SSH patch in test right now.

The nice thing about standards is that there are so many to choose
from, as the joke goes.

OpenVMS ssh has been reactive and not proactive for the last decade or
two, and—prior to the OpenSSH work presently underway—updates are
implemented only after something breaks.

Both KEX and Cipher lists have previously caused ssh outages as other
major platforms have updated their requirements. MAC breakage was
near-inevitable.

SSL/TLS support has been following a similarly reactive update pattern,
both within OpenVMS, and within the Apache HTTP server SSL/TLS support.

I expect VSI SSL300 will become available within the next ~two years
for instance, and hopefully sooner.

Make no mistake: maintaining an operating system is a large effort, and
maintaining compatibility yet larger, and implementing
feature-competitiveness far larger still.

> ...the reason I need access is that I'm running Cache on here and I
> freeze my DB's and take snapshots then thaw out the DB's and mount the
> snaps and then do the backups.

That much was obvious. For now and pending MAC updates and/or OpenSSH
port availability, maybe setting up certificates and HTTPS and cURL, or
a rather precarious trip through some other platform and ssh client.
Though I haven't looked at remote-automation options available for
3PAR. HPE tends to like web management interfaces and RedFish DMTF
"RESTful" interfaces, too. OpenVMS hasn't done much in that area.

--
Pure Personal Opinion | HoffmanLabs LLC

On 2021-10-11, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
> Den 2021-10-11 kl. 07:44, skrev Phillip Helbig (undress to reply):
>> In article <sjvkcl$1kr$3@dont-email.me>,
>> =?UTF-8?Q?Jan-Erik_S=c3=b6derholm?= <jan-erik.soderholm@telia.com>
>> writes:
>>
>>> Just asking...
>>> What is the reason that you *need* to access the 3Par system from VMS?
>>> Cannot the 3Par system be accessed directly from your desktop system?
>>
>> Maybe VMS is the desktop system?
>

Tell me Phillip, what is the weather like on your planet ? :-)

> Now, with an 3Par in the picture, I do not expect this to be a cellar
> hobbyist environment. And I expect some professional guy at the desktop.
>
>> Maybe there is no desktop system?
>
> Highly unlikely.
>
>> Maybe there is the expectation that VMS should have up-to-date SSH?
>
> Sure! But maybe that expectation is not fullfilled. So what do you do?
> Coninue fighting the windmills or take the easy route?

Both. You use a Linux/Unix/Windows system to get over the immediate
problem (and probably for the immediate future as well). Longer-term,
you ask VSI to fix this because it could become a problem elsewhere.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2021-10-11, Dave Froble <davef@tsoft-inc.com> wrote:
> On 10/11/2021 10:45 AM, pcoviello@gmail.com wrote:
>> On Monday, October 11, 2021 at 9:58:00 AM UTC-4, Scott Dorsey wrote:
>>> pcov...@gmail.com <pcov...@gmail.com> wrote:
>>>> Scott if I knew where to find it and was able to edit the sshd_conf file I =
>>>> would.
>>>
>>> It's in /etc/ssh/sshd_config. If you do a man on sshd, it will explain
>>> how the daemon works and how it is configured. If you do a man on sshd_config
>>> it will explain the configuration for different encryption algorithms although
>>> of course they need to be built into the binary for you to enable them.
>>> I am very surprised the 3par people have not suggested this.
>>>
>>> All of this stuff is configurable! You don't have to use the defaults although
>>> it's often wise to do so.
>>> --scott
>>> --
>>> "C'est un Nagra. C'est suisse, et tres, tres precis."
>> thanks though I don't recall having access to that level.
>>
>> HPE wanted no part of downgrading the ciphers or a work around for this.
>>

Given how important this hardware is, that's actually something I'm
inclined to give HPE the benefit of the doubt when they came to that
decision.

>
> 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 ?

> Then there is HPe, "give us your money, but don't expect anything for
> it". Perhaps the next time you're purchasing anything, want no part of HPe?
>

Companies are routinely forced to move away from insecure versions
of protocols. Giving HPE the benefit of the doubt, this may be no
different.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 10/11/2021 2:04 PM, Simon Clubley wrote:
> On 2021-10-11, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 10/11/2021 10:45 AM, pcoviello@gmail.com wrote:
>>> On Monday, October 11, 2021 at 9:58:00 AM UTC-4, Scott Dorsey wrote:
>>>> pcov...@gmail.com <pcov...@gmail.com> wrote:
>>>>> Scott if I knew where to find it and was able to edit the sshd_conf file I =
>>>>> would.
>>>>
>>>> It's in /etc/ssh/sshd_config. If you do a man on sshd, it will explain
>>>> how the daemon works and how it is configured. If you do a man on sshd_config
>>>> it will explain the configuration for different encryption algorithms although
>>>> of course they need to be built into the binary for you to enable them.
>>>> I am very surprised the 3par people have not suggested this.
>>>>
>>>> All of this stuff is configurable! You don't have to use the defaults although
>>>> it's often wise to do so.
>>>> --scott
>>>> --
>>>> "C'est un Nagra. C'est suisse, et tres, tres precis."
>>> thanks though I don't recall having access to that level.
>>>
>>> HPE wanted no part of downgrading the ciphers or a work around for this.
>>>
>
> Given how important this hardware is, that's actually something I'm
> inclined to give HPE the benefit of the doubt when they came to that
> decision.
>
>>
>> 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.

Of course "Mr Security" would say something like that.

> 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 ?

No! But we're not discussing chain saws.

>> Then there is HPe, "give us your money, but don't expect anything for
>> it". Perhaps the next time you're purchasing anything, want no part of HPe?
>>
>
> Companies are routinely forced to move away from insecure versions
> of protocols. Giving HPE the benefit of the doubt, this may be no
> different.

Customers need things to work. What good are they, if they don't do
what the customer needs?

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 10/11/2021 11:35 AM, Dave Froble wrote:
> On 10/11/2021 10:45 AM, pcoviello@gmail.com wrote:
>> HPE wanted no part of downgrading the ciphers or a work around for this.
>
> Hmmm ...  I was of the opinion the customer was always right?
>
> Then there is HPe, "give us your money, but don't expect anything for
> it".  Perhaps the next time you're purchasing anything, want no part of
> HPe?

It seems to be happening.

old HPhad annual revenue around 112 B$

HPE has anual revenue around 27 B$

HP Inc has annual revenue around 57 B$

(of course numbers are not fully comparable,
HPE sold business to DXC and Micro Focus and
acquired SGI and Cray)

Arne