Problem connecting OpenVMS to linux via ssh

[Joukj]

Hi all,

Due to a recent update of OpenSSH on my linux systems I'm not able to
connect to them from my VMS systems using ssh.
We located the problem to this error on the server (linux) side:

Dec 12 16:22:50 csardas.nano.tudelft.nl sshd[18994]: Protocol major
versions dif
fer for 131.180.121.86 port 54477: SSH-2.0-OpenSSH_7.6 vs.
SSH-1.99-3.2.0 SSH Op
enVMS V5.5 VMS_sftp_version 3


By sending "SSH-1.99-3.2.0 the server side seems to think that it is
ssh1, which seems to be dropped in OpenSSH7.6.
The other comment I got that 1.99 was only intended for servers and not
for clients: so that surely is a bug.

Are there patches/newer-versions than the TCP/IP services I run now
(5.7 ECO5), which may solve this problem?


Regards
Jouk

[Joukj]

It also looks there is a bug in OpenSSH7.6 for not accepting 1.99.


Regards
Jouk

[Neil Rieck]

I do not recall anything after ECO5 (which was released in 2014) so I'll check the official patch offering when I'm at work today.

But on a related note, if you updated OpenSSH on your Linux box (or any box for that matter) you may find that the default config for that machine is now more restrictive "for security reasons". The standard server config usually disables SSH while enabling SSH2. You may also discover that SSH2 is not properly configured (client-side) on your OpenVMS box. (need to generate an ssh2 host key; need to have proper client folders with the correct folder privs)

To move forward, I would suggest trying to use SSH2 to connect from Linux back to your OpenVMS box (or OpenVMS to OpenVMS).

Here are a few tips (with a few problems I have seen over the years)
http://neilrieck.net/docs/openvms_notes_ssh2.html

Neil Rieck
Waterloo, Ontario, Canada.

[Jan-Erik Soderholm]

Also try to find the thread(s) where David Froble had some issues with
similar things. I cannot say that it was exactly the same scenario, but
it sounds very familiar to what I remember from that thread.

In davids case I think it was about secure file transfer (FTP?), but the
underlaying issue was that the VMS SSH (or SSL) version was not accepted
on the other side. I *think* that was solved by using a intermediate
(non-VMS) server that had an accepted SSH (or SSL) version...

[BlackCat]

>>> Are there patches/newer-versions than the TCP/IP services I run now (5.7 ECO5), which may solve this problem?

This is the latest that I'm aware of, supplied by HPE:
ssh_575j_i64.zip;1
contains:
DSA110:[IA64.OPENVMS.TCPIP.V057.ECO5J]TCPIP$SSH_SCP2.EXE;1
"V5.7-ECO5J"
26-AUG-2016 13:46:09.92
OpenVMS IA64
DSA110:[IA64.OPENVMS.TCPIP.V057.ECO5J]TCPIP$SSH_SFTP-SERVER2.EXE;1
"V5.7-ECO5J"
26-AUG-2016 13:46:11.24
OpenVMS IA64
DSA110:[IA64.OPENVMS.TCPIP.V057.ECO5J]TCPIP$SSH_SFTP2.EXE;1
"V5.7-ECO5J"
26-AUG-2016 13:46:10.57
OpenVMS IA64
DSA110:[IA64.OPENVMS.TCPIP.V057.ECO5J]TCPIP$SSH_SSH-ADD2.EXE;1
"V5.7-ECO5J"
26-AUG-2016 13:46:14.07
OpenVMS IA64
DSA110:[IA64.OPENVMS.TCPIP.V057.ECO5J]TCPIP$SSH_SSH-AGENT2.EXE;1
"V5.7-ECO5J"
26-AUG-2016 13:46:14.77
OpenVMS IA64
DSA110:[IA64.OPENVMS.TCPIP.V057.ECO5J]TCPIP$SSH_SSH-KEYGEN2.EXE;1
"V5.7-ECO5J"
26-AUG-2016 13:46:13.35
OpenVMS IA64
DSA110:[IA64.OPENVMS.TCPIP.V057.ECO5J]TCPIP$SSH_SSH-SIGNER2.EXE;1
"V5.7-ECO5J"
26-AUG-2016 13:46:15.46
OpenVMS IA64
DSA110:[IA64.OPENVMS.TCPIP.V057.ECO5J]TCPIP$SSH_SSH2.EXE;1
"V5.7-ECO5J"
26-AUG-2016 13:46:11.90
OpenVMS IA64
DSA110:[IA64.OPENVMS.TCPIP.V057.ECO5J]TCPIP$SSH_SSHD2.EXE;1
"V5.7-ECO5J"
26-AUG-2016 13:46:12.64
OpenVMS IA64

[Joukj]

Up to now (with OpenSSH7.5 as server it worked OK when some "old
Ciphers/KEX/MACS were enabled at the server side. It seems that my ssh2
generated a directory [.ssh2] in my home directory with all the
necesarry files.

[Joukj]

Probably a different issue, since this one was introduced when upgrading
to OpenSSH7.6 which was released only very recently.

[Joukj]

My last version is ECO5A so this one is definitely newer.

[Jan-Erik Soderholm]

Well, depends on what you was upgrading *from*, I guess... :-)

That might have been "old enough" to accept the VMS SSH/SSL version.

Even if the versions differ, the description is very similar.



>
>

[BlackCat]

>   Up to now (with OpenSSH7.5 as server it worked OK when some "old Ciphers/KEX/MACS were enabled at the server side. It seems that
> my ssh2 generated a directory [.ssh2] in my home directory with all the necesarry files.

Maybe this is relevant:
Hence, the OpenVMS TCPIP SSH has implemented new key exchange algorithm i.e. "diffie-hellman-group14-sha1". The usage of both
"diffie-hellman-group1-sha1" and "diffie-hellman-group14-sha1" key exchange algorithm for SSH is specified in RFC 4253 "The Secure
Shell (SSH) Transport Layer Protocol".

[Stephen Hoffman]

That's the most recent ssh problem that folks have been encountering
with connections into and from OpenVMS, yes. The older key exchange
support available in many OpenVMS configurations is incompatible with
the expectations of newer ssh clients and servers.

The earlier connectivity problems were around upgraded encryption
support on other systems and the general deprecation of CBC.

An earlier discussion of the key exchange "fun", and some related pages:

https://groups.google.com/d/msg/comp.os.vms/WE9Ci7R6xAU/4v0_o5zAAwAJ
https://groups.google.com/d/msg/comp.os.vms/WE9Ci7R6xAU/vY2n0ZRTBAAJ
https://superuser.com/q/744816
https://www.openssh.com/legacy.html

Usual approach: either downgrade the settings on the more secure end of
the connection to allow the weaker implementation, or patch the weaker
implementation to upgrade its security. Ring up HPE support or VSI
support and ask for a more current patch, if you're already on TCP/IP
Services V5.7 ECO5. The VSI IP stack should also address this, but
there'll inevitably be a treadmill of patches and security upgrades
here irrespective of HPE or VSI or any other vendor of security-related
software; that's the way of the world.


--
Pure Personal Opinion | HoffmanLabs LLC

[David Froble]

Actually, we purchased Multinet SSH and things worked. The old stuff supplied
with HP's TCP/IP is, well, old. Seems some of the non-VMS people out there do
some things such as remove older protocols, without regard to what it may do to
users. Some may cite security. I cite arrogance. But that's just me.

[Stephen Hoffman]

On 2017-12-13 17:45:51 +0000, David Froble said:

> Actually, we purchased Multinet SSH and things worked. The old stuff
> supplied with HP's TCP/IP is, well, old. Seems some of the non-VMS
> people out there do some things such as remove older protocols, without
> regard to what it may do to users. Some may cite security. I cite
> arrogance. But that's just me.

Would y'all rather the vendors and the researchers kept shtum about the
problems in the existing protocols and implementations? And the
ensuing attacks, because some folks will inevitably know about those
vulnerabilities.

If that's not desirable, we're left with the option to bring most of
the folks forward, and to ensure the rest realize they have security
shortfalls and now have to opt-in to maintain their desired degree of
insecurity.

The existing network protocol designs have made moving forward much
easier than it used to be, too. That's what the key exchanges and the
encryption algorithm negotiation implementations in SSL and ssh provide.

Yes, there are incompatibilities here, but that's also due to the lack
of abstraction. That same set of simple tools and the ensuing and
often bespoke implementations has its downside. OpenVMS lacks a
networking framework that makes lower-level API changes less disruptive
to app developers. It'll be years before most folks move to any new
VSI frameworks, and some other folks will (try to) lock down changes
until the incompatibilities become intolerable and intractable, and
some others will port.

As for where we are now and where we're headed? Helping folks
maintain and upgrade their servers and their security is part of VSI's
job. If VSI follows the current common path, there'll be some few
selected cases of app breakage on OpenVMS, if OpenVMS to maintain its
claimed stature as "the most secure operating system on the planet".
We're moving out of the "we can run this forever" era, and OpenVMS will
either follow folks forward and will selectively break some
compatibility and to establish newer abstractions to help reduce that
disruption, or OpenVMS will remain forever compatible and inevitably
fade into the roke.

[David Froble]

I find the practice of forcing others to "do as they are told" to be rather
arrogant. YMMD.

There are of course some things where an "intrusion" can be very bad. We all
must be aware of such, and maintain eternal vigilance. I can accept such.

There are situations where it really isn't much of an issue. I'm not too
worried if someone can steal a few gaskets for a lawn mower. In such
situations, much more harm is done if some production activity suddenly gets
broken. Much more harm.

In the case of the SSH problem, it would have been reasonable, from my
perspective, to document the problems with the older stuff, while still allowing
their use. Hopefully, everyone would address the issue. We all know that for
some, that just isn't going to happen. Regardless, is it the task of some to
force the actions of others? I say it's not.

Consider why we got Donald Trump. It was because the Democratic leadership
decided that they should choose who to run for president, the voting public
didn't need to have any say. Nor did they remember that Republicans are also US
citizens. Really think about that for a moment. How much different, in theory,
from that idiot would be dictator in Venezuela, right? To preserve democracy,
Donald HAD to happen. Perhaps now the US voters will understand they have some
responsibility to make good choices.

You might think I've gone way off topic. I have not. It is the same concept
that some use to "remove older parts of SSH because we don't want them there and
the users have no say". "So what if their stuff stops working?"

You also use the term "bespoke". From the usage, I think it means "stuff I do
myself". Is that correct?

While some things are just too complex, I know that when I write some code, I'm
in charge of whether it continues to work, with the exception of things outside
my control. Maybe "bespoke" isn't such a bad idea after all?

I'll stop there, but, I could have written a multi-volume series of books.

:-)

[Stephen Hoffman]

On 2017-12-13 19:37:44 +0000, David Froble said:

> I find the practice of forcing others to "do as they are told" to be
> rather arrogant. YMMD.
>
> There are of course some things where an "intrusion" can be very bad.
> We all must be aware of such, and maintain eternal vigilance. I can
> accept such.
>
> There are situations where it really isn't much of an issue. I'm not
> too worried if someone can steal a few gaskets for a lawn mower. In
> such situations, much more harm is done if some production activity
> suddenly gets broken. Much more harm.
>
> In the case of the SSH problem, it would have been reasonable, from my
> perspective, to document the problems with the older stuff, while still
> allowing their use

How much advanced notice would you like? With OpenSSH, there was
about a year and a half for the migration window. In the case of this
particular OpenSSH key exchange issue, the notification that this key
exchange was being deprecated was propagated in July of 2015. A path
to re-enable the deprecated key exchange was provided with the
then-next OpenSSH V7.0 release, too.
http://www.openssh.com/legacy.html As part of the migration, better
alternatives (including Curve25519) had been made available and made
default (when both ends support it) in OpenSSH since the release back
at the beginning of 2014. NIST also provided vendor guidance back in
early 2015 with recommendations for longer key-exchange lengths.
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57Pt3r1.pdf


ssh and TLS both support connection negotiation, allowing clients and
servers to negotiate support within the connection including the key
exchange and the cipher selected, meaning that there's a both
transition window and there's no ordering required for the upgrades.
Clients and servers can be upgraded independently, and connectivity can
be maintained. In this and various other cases, deprecated key
exchanges and deprecated ciphers can all be manually re-enabled after
they're no longer available by default.

It then takes a while for the upgrades to cycle through the
distribution channels and the installed bases of the various platforms,
certainly. The OpenSSH V7.0 release arrived in August of 2015, and
it's only just starting to show up at various sites such as Joukj's.
OpenSSH 6.9 was the one that disabled CBC ciphers by default. and
notice of that was provided earlier.

End-users aren't usually reading these details, but vendors definitely
need to be at least reading the notifications and release notes from
the major related products. We're not operating OpenVMS systems in
isolation. We're also increasingly forced into faster patch cycles,
particularly due to vulnerabilities. But in this case, there was
notice.

This is why I've suggested that developers and operations folks working
with security-related requirements get themselves onto security-related
notification lists.

Sitting on older protocol implementations works. Until it doesn't.
Or until your servers are newly featured in https://haveibeenpwned.com
or elsewhere, or worse. Given its origins, the VSI IP appears very
likely to do better here than the HPE TCP and ssh implementations, too.
But this treadmill does not and will not end. The best of the
vendors will make the treadmill easier to stay on. With frameworks
that abstract otherwise incompatible differences, easier and faster
patching, and other mechanisms and approaches of which I've previously
ranted...


From https://www.openssh.com/releasenotes.html

> ...
> OpenSSH 6.9/6.9p1 (2015-07-01)
> OpenSSH 6.9 has just been released. It will be available from the
> mirrors listed at http://www.openssh.com/ shortly.
>
> OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0
> implementation and includes sftp client and server support.
>
> Once again, we would like to thank the OpenSSH community for their
> continued support of the project, especially those who contributed
> code or patches, reported bugs, tested snapshots or donated to the
> project. More information on donations may be found at:
> http://www.openssh.com/donations.html
>
> Future Deprecation Notice
> =========================
>
> The 7.0 release of OpenSSH, due for release in late July, will
> deprecate several features, some of which may affect compatibility
> or existing configurations. The intended changes are as follows:
>
> * The default for the sshd_config(5) PermitRootLogin option will
> change from "yes" to "no".
>
> * Support for the legacy version 1.x of the SSH protocol will be
> disabled at compile time by default.
>
> * Support for the 1024-bit diffie-hellman-group1-sha1 key exchange
> will be run-time disabled by default.
>
> * Support for ssh-dss, ssh-dss-cert-* host and user keys will be
> run-time disabled by default.
>
> * Support for the legacy v00 cert format will be removed
>
> * Several ciphers will be disabled by default: blowfish-cbc,
> cast128-cbc, all arcfour variants and the rijndael-cbc aliases
> for AES
>
> * Refusing all RSA keys smaller than 1024 bits (the current minimum
> is 768 bits)
> ...

[TonyMcG]

Ah, this looks familiar, I've been bitten by an SSH-1.99 issue before.
Is this the same issue described here : https://community.hpe.com/t5/Operating-System-OpenVMS/Reconfigure-SSH-client-to-be-SSH-2-0/td-p/5245572

The simple solution was to define a logical
$ DEFINE /SYSTEM /EXEC TCPIP$SSH_AIX_PATCH 1

Cheers from Down Under,
Tony

[David Froble]

Stephen Hoffman wrote:
> On 2017-12-13 19:37:44 +0000, David Froble said:
>
>> I find the practice of forcing others to "do as they are told" to be
>> rather arrogant. YMMD.
>>
>> There are of course some things where an "intrusion" can be very bad.
>> We all must be aware of such, and maintain eternal vigilance. I can
>> accept such.
>>
>> There are situations where it really isn't much of an issue. I'm not
>> too worried if someone can steal a few gaskets for a lawn mower. In
>> such situations, much more harm is done if some production activity
>> suddenly gets broken. Much more harm.
>>
>> In the case of the SSH problem, it would have been reasonable, from my
>> perspective, to document the problems with the older stuff, while
>> still allowing their use
>
>
> How much advanced notice would you like?

As much as I need ???

In my opinion, you totally missed, or choose to ignore, my point.

The HP product was in use. If there was anyone who dropped the ball, it was HP.
Of course we all know how much they cared for, and paid attention to, VMS.
Regardless, it was the end user who was inconvenienced.

Those developing OpenSSH could have left the old stuff in there. They choose to
dictate to others. Advance notice has nothing to do with it.

> End-users aren't usually reading these details, but vendors definitely
> need to be at least reading the notifications and release notes from the
> major related products. We're not operating OpenVMS systems in
> isolation. We're also increasingly forced into faster patch cycles,
> particularly due to vulnerabilities. But in this case, there was notice.

There was notice, but HP didn't care. I agree that the vendors should be on top
of such things. Not all vendors are reliable. HP sure wasn't.

What was really bad was that I didn't have a clue as to the problem. No, I'm
not going to read all the security stuff. Not enough hours in the day, and night.

> This is why I've suggested that developers and operations folks working
> with security-related requirements get themselves onto security-related
> notification lists.

Agreed.

[terry-...@glaver.org]

On Wednesday, December 13, 2017 at 2:37:48 PM UTC-5, David Froble wrote:
> I find the practice of forcing others to "do as they are told" to be rather
> arrogant. YMMD.

And it is sometimes unsuspecting end users who bear the brunt of this unexpected "friendly fire". While oriented more toward SSL, which has similarly been deprecating protocols left and right, folks might find my blog post "Is no crypto always better than bad crypto?" at https://www.glaver.org/blog/?p=853 from 2 years ago informative. As an example, from that article:

"This leads to an unfortunate game of “whack-a-mole”, where a browser will change its behavior, a company will implement new software to deal with that new behavior, but by the time the software has gone through testing and is released, the browser has changed its behavior again and the updated software is useless. A number of vendors have just given up supporting their older products because of this – they have finite resources and they choose to allocate them to new products.

The browser authors seem to feel that this is just fine and that users should either turn encryption off or throw away the device and buy a new one. Since the “device” is often a management function embedded in an expensive piece of hardware, that simply isn’t practical. A home user may not feel that replacing a working device is necessary and a business likely won’t replace a device until the end of its depreciation cycle (often 3 or 5 years)."

[Stephen Hoffman]

On 2017-12-14 02:20:43 +0000, David Froble said:


> Those developing OpenSSH could have left the old stuff in there.

The OpenBSD OpenSSH team did leave the old support there. It's still
there. It's no longer part of the default. The OpenSSH team also
provided a compatible upgrade path and a migration path.

OpenVMS sites may or may not be able to force OpenSSH connections to
downgrade their security, too.

> They choose to dictate to others.

The OpenBSD team has a focus on system and network security.

As for dictating choices? All product teams have opinions. All make
choices for their users. Whether those opinions and those choices and
the associated trade-offs and compromises and abstractions work for
current and are sufficiently appealing to potential customers is the
basis of business. Because most any meaningful design choice involves
making trade-offs and compromises.

> Advance notice has nothing to do with it.

The HPE folks had the opportunity to keep their ssh implementation
current and compatible with other platforms, but the HPE folks made
different choices and accepted the resulting trade-offs.

VSI has a whole lot of work ahead of them — and an ever-increasing pile
of trade-offs — around what they can work on, what they can defer, and
what they will have to ignore. If the VSI folks are going to target
security as one of their areas, that involves updates to some
combination of ssh, TLS, random number generation, pledge, sandboxes or
jails, and/or a whole pile of other areas. While also providing and
updating the features that sell the platform. And that work will
almost inherently break specific ABIs and APIs.

Get used to old and insecure APIs getting deprecated too, as ABIs and
APIs sometimes and necessarily get deprecated and migrated and
eventually removed, and get used to the need to apply upgrades and
patches.

As OpenVMS users and ISVs and VSI for that matter, we've all got two
choices. Insecurity and marketing folderol and increasing complexity
in a bootless and futile quest for ABI stability and API compatibility,
or a platform and tools that gets patched and updated, and with ABIs
and APIs that very occasionally have to break. Of complete ABI and
API compatibility, or of reasonable API designs and of staying secure
and current. Hopefully the latter approach and with a migration path
available that reduces the need to break any related ABI or API again
in the near future, too.

Why the choice? Because there are cases where you can't have it both
ways with an existing design; where the existing design is just
irreparable. Fundamentally broken. Or where you're left with the
choice to leave insecure defaults. Or with ever-more-complex and
awkward and arcane APIs.

There are also an increasing number of cases where you cannot and do
not control the entire environment and configuration, and cannot
dictate the entire computing and networking configuration. Where you
have to interoperate with OpenSSH or TLSv1.3 or Windows 10 or whatever;
with platforms and protocols that are inherently newer and increasingly
secure. And yes, cases where you have to downgrade your existing
OpenVMS and app security and get a security waiver documented and then
risk the use DECnet or telnet or SSLv3 or Windows 2000 or whatever.

But we aren't getting off the upgrade and the patch treadmills. Our
servers and apps aren't going to survive with insecure or bad defaults,
either. All VSI and any other operating system vendor can do is to
try to ease the effort involved with staying on the treadmill.

I'd like what you want here, too. But what DEC taught folks to want
with OpenVMS ABI and API upward-compatibility is fundamentally
impossible to maintain over non-trivial time and over non-trivial
upgrades. It's still a great goal. It's just not achievable in all
cases.

[Joukj]

Thanks, that solves my problem.

Jouk

[Neil Rieck]

Same with my OpenVMS sites. We started with mixture of "TCPware" and "TCPIP Services" but are now down to just "MultiNet".

While on this topic, more than a decade ago I was forced to jump into the SSH/SSH2 world with no previous knowledge in this subject (we were instructed to push files from OpenVMS to UNIX; no arguments allowed - just a salute). I purchased an O'Reilly book on the subject ("SSH, The Secure Shell: The Definitive Guide") which was okay but didn't serve my needs (often times it appears that security software is kept deliberately confusing).

Then I read the "SSH" and "SSH2" chapters from the TCPware manager's manual and that's when I was hit with the metaphorical beam of light. They are very well written and, presented in two different chapters because "SSH" and "SSH2" are two different products.

http://process.com/docs/tcpware6_0/html/manage/Chapter%2025.htm (SSH)
http://process.com/docs/tcpware6_0/html/manage/Chapter%2026.htm (SSH2)

Since that time I have used knowledge gained from those TCPware manuals to setup SSH/SSH2 on other systems (VMS, OpenVMS, Unix, Linux, Windows). If any of your systems ever supported TCPware then you probably have the paper manuals on your bookshelf. Don't ever throw them out.

Neil Rieck
Waterloo, Ontario, Canada.

http://neilrieck.net/

[John Nebel]

VSI OpenVMS Alpha 8.4-2L2 SSH with patch V0507-ECO5D-4 will connect to
SSH v6 and v7 and vice versa, I used OS X for testing as it incorporates
a more recent sshd than does the Linux on hand, RHEL6, OpenSSH_5.3p1
OpenSSL 1.0.1e-fips.

OpenVMS to/from both of these functions normally as it does with the
older SSH supported on RHEL6.

EL Capitan

OpenSSH_6.9p1, LibreSSL 2.1.8

Sierra

OpenSSH_7.4p1, LibreSSL 2.5.0

Note: With the default OSX configuration, connecting from OpenSSH_7.4p1
to OpenVMS will fail without a RSA hostkey on OpenVMS which key may be
generated with tcpip$config. "Unable to negotiate with w.x.y.z port 22:
no matching host key type found. Their offer: ssh-dss." OpenVMS will
connect error free once the DSA hostkey is deleted and an RSA key generated.

[Craig A. Berry]

On 12/14/17 5:32 PM, John Nebel wrote:
>
> VSI OpenVMS Alpha 8.4-2L2 SSH with patch V0507-ECO5D-4 will connect to
> SSH v6 and v7 and vice versa, I used OS X for testing as it incorporates
> a more recent sshd than does the Linux on hand, RHEL6, OpenSSH_5.3p1
> OpenSSL 1.0.1e-fips.
>
> OpenVMS to/from both of these functions normally as it does with the
> older SSH supported on RHEL6.

It doesn't for me. According to PROD SHOW HIST I have "VSI AXPVMS TCPIP
V5.7-13ECO5F" and last time I checked F is later than D. ssh to macOS
Sierra from this fails with "Algorithm negotiation failed." Verbose
output says:

debug(15-DEC-2017 07:28:12.14): Ssh2Transport/TRCOMMON.C:1935: Using
Client order for common key exchange algorithms.
debug(15-DEC-2017 07:28:12.14): Ssh2Transport/TRCOMMON.C:1139: Sending
packet with type 2 to connection
debug(15-DEC-2017 07:28:12.14): Ssh2Transport/TRCOMMON.C:1139: Sending
packet with type 20 to connection
debug(15-DEC-2017 07:28:12.14): Ssh2Transport/TRCOMMON.C:2832: >TR
packet_type=20
debug(15-DEC-2017 07:28:12.14): Ssh2Transport/TRCOMMON.C:2394: lang s to
c: `', lang c to s: `'
debug(15-DEC-2017 07:28:12.14): Ssh2Transport/TRCOMMON.C:2410: Couldn't
agree on kex or hostkey alg. (chosen_kex = NUL
L, chosen_host_key = ssh-rsa)
debug(15-DEC-2017 07:28:12.15): Ssh2Transport/TRCOMMON.C:1139: Sending
packet with type 2 to connection
debug(15-DEC-2017 07:28:12.15): Ssh2Transport/TRCOMMON.C:1139: Sending
packet with type 1 to connection
debug(15-DEC-2017 07:28:12.15): Ssh2Common/SSHCOMMON.C:180: DISCONNECT
received: Algorithm negotiation failed.

To go from macOS to VMS I have to do something like this in ~/.ssh/config:

Host <vmshost>
KexAlgorithms +diffie-hellman-group1-sha1
HostKeyAlgorithms +ssh-dss

Putting the equivalent in [.ssh2]ssh2_config on the VMS side has no
effect on the VMS-to-macOS connection and I find nothing in the docs
indicating any way to specify the key exchange algorithm.

> EL Capitan
>
> OpenSSH_6.9p1, LibreSSL 2.1.8
>
> Sierra
>
> OpenSSH_7.4p1, LibreSSL 2.5.0
>
> Note: With the default OSX configuration, connecting from OpenSSH_7.4p1
> to OpenVMS will fail without a RSA hostkey on OpenVMS which key may be
> generated with tcpip$config. "Unable to negotiate with w.x.y.z port 22:
> no matching host key type found. Their offer: ssh-dss." OpenVMS will
> connect error free once the DSA hostkey is deleted and an RSA key
> generated.

You could be right, but it's also possible you just need to change the
host key algorithm as in my example above and not the host key itself.

[Dennis Boone]

> Putting the equivalent in [.ssh2]ssh2_config on the VMS side has no
> effect on the VMS-to-macOS connection and I find nothing in the docs
> indicating any way to specify the key exchange algorithm.

You would have to reconfigure sshd on the macOS side to accept those
algorithms. There's an sshd_config somewhere, and statements that
go therein: HostKeyAlgorithms and/or KexAlgorithms, depending on what
all you need to "downgrade".

De

[Craig A. Berry]

What's described here:

<https://www.digitalocean.com/community/questions/server-does-not-support-diffie-hellman-group1-sha1-for-keyexchange>

would probably do it, though I'm reluctant to downgrade the security of
macOS in this way.

[John Nebel]

Craig,

The TCPIP version is indeed TCPIP V5.7-13ECO5F as you wrote, however, the SSH patch is
named TCPIP_SSH_PAT V5.7-ECO5D and is in the 8.4-2L2 distribution iso as well as VSI's
site (think I saw it there). The defaults AnyCipher/AnyMac on OpenVMS seem fine. The Macs
are also at their defaults.

John

Dionysus:~ johnnebel$ ssh -v ananke
OpenSSH_7.4p1, LibreSSL 2.5.0
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to ananke [198.80.11.13] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /Users/johnnebel/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/johnnebel/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/johnnebel/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/johnnebel/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/johnnebel/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/johnnebel/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/johnnebel/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/johnnebel/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4
debug1: Remote protocol version 2.0, remote software version 3.2.0 SSH OpenVMS V5.5
VMS_sftp_version 3
debug1: no match: 3.2.0 SSH OpenVMS V5.5 VMS_sftp_version 3
debug1: Authenticating to ananke:22 as 'johnnebel'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: diffie-hellman-group14-sha1
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha1 compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha1 compression: none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Server host key: ssh-rsa SHA256:KjvdMkj3azaYmqT8syb/WNCggcC8EqYo3NrZjz8U4ds
The authenticity of host 'ananke (198.80.11.13)' can't be established.
RSA key fingerprint is SHA256:KjvdMkj3azaYmqT8syb/WNCggcC8EqYo3NrZjz8U4ds.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'ananke,198.80.11.13' (RSA) to the list of known hosts.
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_SERVICE_ACCEPT received

@sys$manager:sysannounce.dat
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/johnnebel/.ssh/id_rsa
debug1: Authentications that can continue: password
debug1: Next authentication method: password
johnnebel@ananke's password:

> _______________________________________________
> Info-vax mailing list
> Info...@rbnsn.com
> http://rbnsn.com/mailman/listinfo/info-vax_rbnsn.com

[Craig A. Berry]

On 12/15/17 7:54 PM, John Nebel wrote:
> Craig,
>
> The TCPIP version is indeed TCPIP V5.7-13ECO5F as you wrote, however,
> the SSH patch is named TCPIP_SSH_PAT V5.7-ECO5D and is in the 8.4-2L2
> distribution iso as well as VSI's site (think I saw it there). The
> defaults AnyCipher/AnyMac on OpenVMS seem fine. The Macs are also at
> their defaults.

Thanks, John. I eventually found it and an NFS patch on the base distro
(volume label ALPHA0842L1) under this directory:

$ dir/col=1

Directory DQA0:[KITS.TCPIP_ALPHA_V0507-13ECO5F_KIT]

VSI-AXPVMS-TCPIP-V0507-13ECO5F-1.PCSI$COMPRESSED;1
VSI-AXPVMS-TCPIP-V0507-13ECO5F-1.PCSI$COMPRESSED_VNC;1
VSI-AXPVMS-TCPIP_NFS_PAT-V0507-ECO5A-4.PCSI$COMPRESSED;1
VSI-AXPVMS-TCPIP_NFS_PAT-V0507-ECO5A-4.PCSI$COMPRESSED_VNC;1
VSI-AXPVMS-TCPIP_SSH_PAT-V0507-ECO5D-4.PCSI$COMPRESSED;1
VSI-AXPVMS-TCPIP_SSH_PAT-V0507-ECO5D-4.PCSI$COMPRESSED_VNC;1

Total of 6 files.

The SSH patch does indeed get the key exchange algorithm working. Not
sure why these things weren't installed automatically when I upgraded to
VSI VMS.

[dgordo...@gmail.com]

On Friday, December 15, 2017 at 10:32:53 PM UTC-5, Craig A. Berry wrote:

> Thanks, John. I eventually found it and an NFS patch on the base distro
> (volume label ALPHA0842L1) under this directory:
>
> $ dir/col=1
>
> Directory DQA0:[KITS.TCPIP_ALPHA_V0507-13ECO5F_KIT]
>
> VSI-AXPVMS-TCPIP-V0507-13ECO5F-1.PCSI$COMPRESSED;1
> VSI-AXPVMS-TCPIP-V0507-13ECO5F-1.PCSI$COMPRESSED_VNC;1
> VSI-AXPVMS-TCPIP_NFS_PAT-V0507-ECO5A-4.PCSI$COMPRESSED;1
> VSI-AXPVMS-TCPIP_NFS_PAT-V0507-ECO5A-4.PCSI$COMPRESSED_VNC;1
> VSI-AXPVMS-TCPIP_SSH_PAT-V0507-ECO5D-4.PCSI$COMPRESSED;1
> VSI-AXPVMS-TCPIP_SSH_PAT-V0507-ECO5D-4.PCSI$COMPRESSED_VNC;1
>
> Total of 6 files.
>
> The SSH patch does indeed get the key exchange algorithm working. Not
> sure why these things weren't installed automatically when I upgraded to
> VSI VMS.

The upgrade listed them as patches supplied on the installation medium before the upgrade menu was displayed and you had to carriage return to keep going. One of the upgrade menu options allows you to install patches supplied with the kit.

[Stephen Hoffman]

On 2017-12-18 15:21:19 +0000, dgordo...@gmail.com said:

> The upgrade listed them as patches supplied on the installation medium
> before the upgrade menu was displayed and you had to carriage return to
> keep going. One of the upgrade menu options allows you to install
> patches supplied with the kit.

At the risk of asking an obvious question, why doesn't the installation
load all of the current patches by default, rather than requiring the
installer manually build the most current and secure configuration?

If there are consequences that might preclude a default installation of
specific patches, that should be clearly called out, or the issue or
bug or incompatibility in the patch resolved to allow the patch to be
installed on all systems by default.

Sure, the installation and patch processes and PCSI itself are in
aggregate rather less than great at providing that capability, and
overhauling or replacing the installation and patch processes are
undoubtedly future work items.

Default OpenVMS installs should always be current, patch-complete and
should not seek to introduce a long list of permutations and complexity
for the end-user, for VSI, and for ISVs.

Why "the most secure operating system on the planet" would not
automatically install the current security-related algorithms and
support is simply unfathomable, of course.

[dgordo...@gmail.com]

On Monday, December 18, 2017 at 12:19:44 PM UTC-5, Stephen Hoffman wrote:
>
> At the risk of asking an obvious question, why doesn't the installation
> load all of the current patches by default, rather than requiring the
> installer manually build the most current and secure configuration?
>

Reality is not always as perfect as things are in Hoffland.

All I can say is there was a legitimate reason for the choice made at the time it was made.

[Stephen Hoffman]

On 2017-12-18 17:51:03 +0000, dgordo...@gmail.com said:

> On Monday, December 18, 2017 at 12:19:44 PM UTC-5, Stephen Hoffman wrote:
>>
>> At the risk of asking an obvious question, why doesn't the installation
>> load all of the current patches by default, rather than requiring the
>> installer manually build the most current and secure configuration?
>>
>
> Reality is not always as perfect as things are in Hoffland.

Imperfect realities do arise even around here. What follows is an example.

...
Execution phase starting ...

The following products will be installed to destinations:
VSI AXPVMS AVAIL_MAN_BASE V8.4-2L1 DISK$ALPHASYS:[VMS$COMMON.]
VSI AXPVMS CDSA V2.4-320A DISK$ALPHASYS:[VMS$COMMON.]
VSI AXPVMS DECNET_OSI V8.4-D DISK$ALPHASYS:[VMS$COMMON.]
VSI AXPVMS DWMOTIF V1.7-F DISK$ALPHASYS:[VMS$COMMON.]
VSI AXPVMS DWMOTIF_SUPPORT V8.4-2L1 DISK$ALPHASYS:[VMS$COMMON.]
VSI AXPVMS HPBINARYCHECKER V1.1-A DISK$ALPHASYS:[VMS$COMMON.]
VSI AXPVMS KERBEROS V3.1-152A DISK$ALPHASYS:[VMS$COMMON.]
VSI AXPVMS OPENVMS V8.4-2L1 DISK$ALPHASYS:[VMS$COMMON.]
VSI AXPVMS SSL V1.4-502A DISK$ALPHASYS:[VMS$COMMON.]
VSI AXPVMS SSL1 V1.0-2JA DISK$ALPHASYS:[VMS$COMMON.]
VSI AXPVMS TCPIP V5.7-13ECO5F DISK$ALPHASYS:[VMS$COMMON.]
VSI AXPVMS TDC_RT V2.3-1220 DISK$ALPHASYS:[VMS$COMMON.]
VSI AXPVMS VMS V8.4-2L1 DISK$ALPHASYS:[VMS$COMMON.]

Portion done: 0%...10%

%PCSI-E-OPENOUT, error opening
DISK$ALPHASYS:[VMS$COMMON.][SYSHLP]HELPLIB.HLB; as output
-RMS-E-FNF, file not found
%PCSI-E-OPFAILED, operation failed
Terminating is strongly recommended. Do you want to terminate? [YES]
%PCSI-E-CANCEL_WIP, termination resulted in an incomplete modification
to the system
%PCSI-E-S_OPCAN, operation cancelled by request
%PCSIUI-E-ABORT, operation terminated due to an unrecoverable error condition


Installation has been aborted.

The installation has not completed normally.


Repeatable, too. Checked the prompts and the release notes.
Probably missed some documentation somewhere else, though. Off to try
one of the more obvious work-arounds.

> All I can say is there was a legitimate reason for the choice made at
> the time it was made.

Undoubtedly.

[Robert A. Brooks]

On 12/18/2017 9:26 PM, Stephen Hoffman wrote:
> On 2017-12-18 17:51:03 +0000, dgordo...@gmail.com said:
>
>> On Monday, December 18, 2017 at 12:19:44 PM UTC-5, Stephen Hoffman wrote:
>>>
>>> At the risk of asking an obvious question, why doesn't the installation
>>> load all of the current patches by default, rather than requiring the
>>> installer manually build the most current and secure configuration?
>>>
>>
>> Reality is not always as perfect as things are in Hoffland.
>
> Imperfect realities do arise even around here.   What follows is an example.
>
> ...
> Execution phase starting ...
>
> The following products will be installed to destinations:
>    VSI AXPVMS AVAIL_MAN_BASE V8.4-2L1     DISK$ALPHASYS:[VMS$COMMON.]

Was this an installation or upgrade?

We documented the fact that -2L1 can only be an upgrade.

We fixed that for -2L2, which can be a fresh install.

--
-- Rob

[David Froble]

I'm curious. Why was this done? I'd think that all distribution media would
have followed the practice of allowing upgrade or install. Or is it just
another of those pesky bugs?

[Robert A. Brooks]

I was not clear; what I said above was specific to Alpha

There was a pesky issue with fresh installations on Alpha,
and while some time was spent trying to fix it, the expectation
was that the vast majority of customers would be upgrading
existing systems, so we deferred working on it.

However, it was solved prior to -2L2 going out the door, so the
restriction was lifted.


--

-- Rob

[David Froble]

Robert A. Brooks wrote:
> On 12/19/2017 11:06 AM, David Froble wrote:
>> Robert A. Brooks wrote:
>>> On 12/18/2017 9:26 PM, Stephen Hoffman wrote:
>>>> On 2017-12-18 17:51:03 +0000, dgordo...@gmail.com said:
>
>>>>> Reality is not always as perfect as things are in Hoffland.
>>>>
>>>> Imperfect realities do arise even around here. What follows is
>>>> an example.
>>>>
>>>> ... Execution phase starting ...
>>>>
>>>> The following products will be installed to destinations: VSI
>>>> AXPVMS AVAIL_MAN_BASE V8.4-2L1 DISK$ALPHASYS:[VMS$COMMON.]
>
>>> Was this an installation or upgrade?
>>> We documented the fact that -2L1 can only be an upgrade. We fixed
>>> that for -2L2, which can be a fresh install.
>
>> I'm curious. Why was this done? I'd think that all distribution
>> media would have followed the practice of allowing upgrade or
>> install. Or is it just another of those pesky bugs?
>
> I was not clear; what I said above was specific to Alpha

Yes, I understood that.

> There was a pesky issue with fresh installations on Alpha,
> and while some time was spent trying to fix it, the expectation
> was that the vast majority of customers would be upgrading
> existing systems, so we deferred working on it.

Sometimes I like to do a fresh install. Of course, my environment is rather
simple. I use EDT and the compilers.

> However, it was solved prior to -2L2 going out the door, so the
> restriction was lifted.

So, would new distributions of -2L1 still have the restriction? My
understanding is that -2L2 is just compiler switches to take advantage of EV6.
So I'd think the install and upgrade stuff would be the same?

[Robert A. Brooks]

On 12/19/2017 6:27 PM, David Froble wrote:

> So, would new distributions of -2L1 still have the restriction?  My
> understanding is that -2L2 is just compiler switches to take advantage of EV6.

There is no "new distributions of -2L1...". That is, we did not rebuild
the -2L1 kit once we fixed it for -2L2.

> So I'd think the install and upgrade stuff would be the same?

Yes, that's largely true. But since the fix was not made until
after -2L1 was released, we're not going to go back and remaster
a 2nd distribution, especially since any Alpha system made since 1998 (or
thereabouts) can run -2L2, which we expect is the vast majority of our customer
base.

If you've got an older system, then yes, you'll need to run -2L1.

--
-- Rob

[Stephen Hoffman]

On 2017-12-19 04:12:57 +0000, Robert A. Brooks said:

> On 12/18/2017 9:26 PM, Stephen Hoffman wrote:
>>
>> Imperfect realities do arise even around here.   What follows is an example.
>>
>> ...
>> Execution phase starting ...
>>
>> The following products will be installed to destinations:
>>    VSI AXPVMS AVAIL_MAN_BASE V8.4-2L1     DISK$ALPHASYS:[VMS$COMMON.]
>
> Was this an installation or upgrade?

Install.

> We documented the fact that -2L1 can only be an upgrade.

I'd thought that was the case for some of the VSI releases, but looking
around couldn't find that listed anywhere, and the install-or-preserve
was there as was typical.

I'd looked around for doc and skimmed through (and searched for
"install" in)
https://www.vmssoftware.com/pdfs/VSI_OpenVMS_V842L1_CLRN.pdf

There's not all that much 2L1 documentation posted around, but I've
probably missed reading a PDF in the deluge of PDF files that this
project has involved.

If y'all do this have this restriction again, please tie off the
"install or upgrade" section?

Not that the whole of the installation and upgrade processing couldn't
benefit from a re-think and a simplification, but that's fodder for
another era.

> We fixed that for -2L2, which can be a fresh install.

Good.

A wonderful little round of hardware and software and disk parity
errors later, and maybe this old server boots anew.