Discussion:
SSH from VMS to 3Par
Add Reply
p***@gmail.com
2021-10-06 15:06:49 UTC
Reply
Permalink
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
Stephen Hoffman
2021-10-06 15:12:28 UTC
Reply
Permalink
Post by p***@gmail.com
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
p***@gmail.com
2021-10-06 16:13:02 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by p***@gmail.com
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.
Stephen Hoffman
2021-10-06 16:26:15 UTC
Reply
Permalink
Post by p***@gmail.com
Post by Stephen Hoffman
Post by p***@gmail.com
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
Chris Townley
2021-10-06 16:59:30 UTC
Reply
Permalink
Post by p***@gmail.com
Post by Stephen Hoffman
Post by p***@gmail.com
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
Dave Froble
2021-10-06 19:16:55 UTC
Reply
Permalink
Post by p***@gmail.com
Post by Stephen Hoffman
Post by p***@gmail.com
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: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
p***@gmail.com
2021-10-10 20:40:49 UTC
Reply
Permalink
Post by Dave Froble
Post by p***@gmail.com
Post by Stephen Hoffman
Post by p***@gmail.com
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
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 ***@10.128.20.13
warning: Authentication failed.
Disconnected; key exchange or algorithm negotiation failed (Algorithm negotiation failed.).



$ ssh ***@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-***@openssh.com,hmac-sha2-256-***@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-***@openssh.com,hmac-sha2-256-***@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)

$
Jan-Erik Söderholm
2021-10-10 21:02:12 UTC
Reply
Permalink
Post by p***@gmail.com
Post by Dave Froble
Post by p***@gmail.com
Post by Stephen Hoffman
Post by p***@gmail.com
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
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
warning: Authentication failed.
Disconnected; key exchange or algorithm negotiation failed (Algorithm negotiation failed.).
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
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
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?
Phillip Helbig (undress to reply)
2021-10-11 05:44:03 UTC
Reply
Permalink
Post by Jan-Erik Söderholm
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?
Jan-Erik Söderholm
2021-10-11 06:17:21 UTC
Reply
Permalink
Post by Phillip Helbig (undress to reply)
Post by Jan-Erik Söderholm
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.
Post by Phillip Helbig (undress to reply)
Maybe there is no desktop system?
Highly unlikely.
Post by Phillip Helbig (undress to reply)
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?
p***@gmail.com
2021-10-11 13:36:02 UTC
Reply
Permalink
Post by Jan-Erik Söderholm
Post by Phillip Helbig (undress to reply)
Post by Jan-Erik Söderholm
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.
Post by Phillip Helbig (undress to reply)
Maybe there is no desktop system?
Highly unlikely.
Post by Phillip Helbig (undress to reply)
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
Scott Dorsey
2021-10-11 13:57:58 UTC
Reply
Permalink
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."
p***@gmail.com
2021-10-11 14:45:24 UTC
Reply
Permalink
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.
Stephen Hoffman
2021-10-11 15:32:15 UTC
Reply
Permalink
Post by p***@gmail.com
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
Dave Froble
2021-10-11 15:35:32 UTC
Reply
Permalink
Post by p***@gmail.com
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: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Dave Froble
2021-10-11 18:47:30 UTC
Reply
Permalink
Post by Dave Froble
Post by p***@gmail.com
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.
Post by Dave Froble
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.
Post by Dave Froble
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: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2021-10-12 17:08:26 UTC
Reply
Permalink
Post by Dave Froble
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?
Customers can work just fine in this case.

They just use another operating system with the required security
functionality until VMS gets updated with that same functionality.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2021-10-12 18:28:45 UTC
Reply
Permalink
Post by Simon Clubley
Post by Dave Froble
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?
Customers can work just fine in this case.
They just use another operating system with the required security
functionality until VMS gets updated with that same functionality.
Simon.
Real easy to tell others what they should do. But perhaps it is not
that simple. As one example, automating things from VMS.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2021-10-12 00:04:50 UTC
Reply
Permalink
Post by p***@gmail.com
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
Arne Vajhøj
2021-10-12 00:22:25 UTC
Reply
Permalink
Post by Dave Froble
Post by p***@gmail.com
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.
Post by Dave Froble
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-***@openssh.com,hmac-sha2-256-***@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-***@openssh.com,hmac-sha2-256-***@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.

Arne
Simon Clubley
2021-10-12 17:19:12 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Dave Froble
Post by p***@gmail.com
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.
Post by Dave Froble
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.
debug(10-OCT-2021 16:31:40.82): Ssh2Transport/TRCOMMON.C:2142: Algorithm
debug(10-OCT-2021 16:31:40.82): Ssh2Transport/TRCOMMON.C:2142: Algorithm
https://www.ssh.com/academy/ssh/sshd_config
<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.
Arne
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.

It looks to me like HPE have strictly locked down the server configuration,
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.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Arne Vajhøj
2021-10-12 17:34:23 UTC
Reply
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
Post by Dave Froble
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.
debug(10-OCT-2021 16:31:40.82): Ssh2Transport/TRCOMMON.C:2142: Algorithm
debug(10-OCT-2021 16:31:40.82): Ssh2Transport/TRCOMMON.C:2142: Algorithm
https://www.ssh.com/academy/ssh/sshd_config
<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.
Post by Simon Clubley
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.
Post by Simon Clubley
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
Bill Gunshannon
2021-10-12 18:11:50 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Simon Clubley
Post by Arne Vajhøj
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.
debug(10-OCT-2021 16:31:40.82): Ssh2Transport/TRCOMMON.C:2142: Algorithm
debug(10-OCT-2021 16:31:40.82): Ssh2Transport/TRCOMMON.C:2142: Algorithm
https://www.ssh.com/academy/ssh/sshd_config
<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.
Post by Simon Clubley
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.
Post by Simon Clubley
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.
When was the last time HPE was ever friendly to customers in the
VMS world?

bill
Arne Vajhøj
2021-10-12 18:20:18 UTC
Reply
Permalink
Post by Bill Gunshannon
Post by Arne Vajhøj
Hmmm ...  I was of the opinion the customer was always right?
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.
When was the last time HPE was ever friendly to customers in the
VMS world?
I think that was also sort of where Dave was going ...

:-)

Arne
Dave Froble
2021-10-12 20:57:45 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Bill Gunshannon
Post by Arne Vajhøj
Post by Dave Froble
Hmmm ... I was of the opinion the customer was always right?
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.
When was the last time HPE was ever friendly to customers in the
VMS world?
I think that was also sort of where Dave was going ...
:-)
Arne
Not quite. Dave was going "when was the FIRST time HPe was ever
friendly to customers in the VMS world". Hint, does not exist.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2021-10-13 17:17:26 UTC
Reply
Permalink
Post by Dave Froble
Not quite. Dave was going "when was the FIRST time HPe was ever
friendly to customers in the VMS world". Hint, does not exist.
Well, they gave us an extra year on the final hobbyist licences. :-)

Apart from that, I can't think of anything other than VMS coming
out on top of the disaster-proof video (although that was the same
organisation but by a different earlier name).

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2021-10-12 18:30:45 UTC
Reply
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
Post by Dave Froble
Post by p***@gmail.com
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.
Post by Dave Froble
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.
debug(10-OCT-2021 16:31:40.82): Ssh2Transport/TRCOMMON.C:2142: Algorithm
debug(10-OCT-2021 16:31:40.82): Ssh2Transport/TRCOMMON.C:2142: Algorithm
https://www.ssh.com/academy/ssh/sshd_config
<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.
Arne
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.
It looks to me like HPE have strictly locked down the server configuration,
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.
Simon.
If one considers a chainsaw dangerous, perhaps don't use one. But if
someone needs a tree cut down ????????
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2021-10-13 17:25:02 UTC
Reply
Permalink
Post by Dave Froble
Post by Simon Clubley
It looks to me like HPE have strictly locked down the server configuration,
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.
If one considers a chainsaw dangerous, perhaps don't use one. But if
someone needs a tree cut down ????????
Chainsaws are fine provided you use them correctly (although given the
way things appear to be going in parts of your country, I would not be
surprised to see them outlawed in parts of your country unless you pass
an exam and pay for a licence to operate one. :-) :-))

On a more serious note, my example was about the customer asking for
what the vendor would consider to be a dangerous attachment to the chainsaw.
That directly maps to reducing security on a vendor product at customer
request.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
p***@gmail.com
2021-10-11 14:48:42 UTC
Reply
Permalink
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%
p***@gmail.com
2021-10-11 15:25:24 UTC
Reply
Permalink
Post by p***@gmail.com
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-***@openssh.com, aes128-ctr,aes192-ctr,aes256-ctr, aes128-***@openssh.com, aes256-***@openssh.com

debug2: KEX algorithms: curve25519-sha256,curve25519-***@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-***@openssh.com,umac-128-***@openssh.com,hmac-sha2-256-***@openssh.com,hmac-sha2-512-***@openssh.com,hmac
-sha1-***@openssh.com,umac-***@openssh.com,umac-***@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
Lawrence D’Oliveiro
2021-10-12 00:20:43 UTC
Reply
Permalink
Post by p***@gmail.com
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%
Is that supposed to be some kind of *nixish shell? If there is no ls command, maybe shell wildcard expansion will still work. Try

    echo /etc/*

to see what’s in /etc.
Scott Dorsey
2021-10-12 01:47:07 UTC
Reply
Permalink
FACSSAN1 cli% pwd=20
/=20
Is that supposed to be some kind of *nixish shell? If there is no ls comman=
d, maybe shell wildcard expansion will still work. Try
It used to be that you logged into a Solaris machine and then you typed
"cli" to get into the cli from bash. It looks to me like he is directly
in cli and not in a Unix shell at all. But it has been a few years since
I have used any 3PAR gear.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
p***@gmail.com
2021-10-12 14:18:04 UTC
Reply
Permalink
Post by Scott Dorsey
FACSSAN1 cli% pwd=20
/=20
Is that supposed to be some kind of *nixish shell? If there is no ls comman=
d, maybe shell wildcard expansion will still work. Try
It used to be that you logged into a Solaris machine and then you typed
"cli" to get into the cli from bash. It looks to me like he is directly
in cli and not in a Unix shell at all. But it has been a few years since
I have used any 3PAR gear.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
FACSSAN1 cli% echo /etc/*
/etc/*
Stephen Hoffman
2021-10-11 15:55:38 UTC
Reply
Permalink
Post by p***@gmail.com
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.
Post by p***@gmail.com
...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
Dave Froble
2021-10-11 15:31:04 UTC
Reply
Permalink
Post by Jan-Erik Söderholm
Post by Phillip Helbig (undress to reply)
Post by Jan-Erik Söderholm
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.
Post by Phillip Helbig (undress to reply)
Maybe there is no desktop system?
Highly unlikely.
Post by Phillip Helbig (undress to reply)
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: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2021-10-11 17:47:43 UTC
Reply
Permalink
Post by Jan-Erik Söderholm
Post by Phillip Helbig (undress to reply)
Post by Jan-Erik Söderholm
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 ? :-)
Post by Jan-Erik Söderholm
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.
Post by Phillip Helbig (undress to reply)
Maybe there is no desktop system?
Highly unlikely.
Post by Phillip Helbig (undress to reply)
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, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Stephen Hoffman
2021-10-10 21:45:48 UTC
Reply
Permalink
client list: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96
vs.
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
Scott Dorsey
2021-10-10 22:09:07 UTC
Reply
Permalink
Post by Stephen Hoffman
client list: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96
vs.
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."
Loading...