VMS SSH2 experts, journaymen, hackers, and just about anyone else

[David Froble]

I've got a customer who uses SFTP from a VMS system to a trading partner. The
procedure was working until sometime early in February, 2016. At that time if
failed with "failed to authenticate". It also mumbles about possibly a too old
version of SSH2.

This is an itanic, running VMS V8.3-1h1.

Not sure what that means concerning SSH and SFTP.

Nothing has changed on the VMS side. I've made inquiries about possible changes
on the other side. Hoping to hear back soon.

What I'm wondering about is possible problems with newer versions of SSH.
Currently the client cert is from July, 2011, and dsa 1024.

Since just about everyone knows more about SSH than I do, possibly some helpful
comments might appear?

[abrsvc]

I seem to recall a discussion on this forum about a newer version of SSH that may resolve the problem. However, in order to avoid the "old" versions that appear on OpenVMS systems, I usually transfer files to a "local" Windows system and SFTP from the Windows system. While not my first choice, it was the easiest to implement at the time given the we regularly used SFTP from the Windows systems anyway. Why maintain 2 different SFTP clients...

Dan

[Stephen Hoffman]

On 2016-03-02 00:08:59 +0000, David Froble said:

> I've got a customer who uses SFTP from a VMS system to a trading
> partner. The procedure was working until sometime early in February,
> 2016. At that time if failed with "failed to authenticate". It also
> mumbles about possibly a too old version of SSH2.

Find out what happened at the remote end, and what the ssh server
implementation and version might be. Could well be a system or
security update, for instance.

But it's quite possible that the OpenVMS ssh (sftp) bits needs an
upgrade, as there's a decent shot that a system running fossil OpenVMS
I64 is also running fossil ssh. Down-revision ssh is increasingly
blocked, as it should be.

Related: http://labs.hoffmanlabs.com/node/1897

For the connection itself, use ssh -vvv or sftp -vvv and see what's
happening within the negotiation sequence. That'll tell you what's
been tried.


--
Pure Personal Opinion | HoffmanLabs LLC

[Bob Gezelter]

David,

As Hoff has noted, there was a widely deployed Linux ssh update which disabled several deprecated cipher and signature algorithms.

The best answer is to update the OpenVMS SSH to a current version.

- Bob Gezelter, http://www.rlgsc.com

[Craig A. Berry]

On 3/1/16 6:42 PM, Bob Gezelter wrote:

> As Hoff has noted, there was a widely deployed Linux ssh update

> whichdisabled several deprecated cipher and signature algorithms.

>
> The best answer is to update the OpenVMS SSH to a current version.

This would be good advice if there were such a thing as a current
version on OpenVMS. Even with TCP/IP 5.7 ECO5, sftp from VMS to a system
with up-to-date OpenSSH is going to get kicked to the curb. I admit,
however, that I have not explored disabling ciphers or other non-default
configurations on the VMS side.

The only thing I've found to work reliably is to pull from the VMS box
using scp, but most scp implementations won't work either. The pcsp that
comes with PuTTY does work, and can be built from source on most unixen.

curl might work, though it appears to support ftps and not sftp.

[David Froble]

Yeah, I thought I had read some stuff about older SSH being blocked or such.
That's sort of what I was looking for while waiting to hear what the other side
did, if anything.

Further research, using the -vvv switch, says that the file SSH2_CONFIG is
missing. I'm not sure that this file ever existed. But, never trust the
customers, who knows what they might do ....

If required, where do I get, or build, this file?

Some of the diagnostics:

debug( 2-MAR-2016 01:03:15.40): SshConfig/SSHCONFIG.C:3364: Unable to open
/DISK0/codis_ssh/ssh2/ssh2_config
debug( 2-MAR-2016 01:03:15.40): Connecting to vftp.fidelitone.com, port 22...
(SOCKS not used)
debug( 2-MAR-2016 01:03:15.40): Ssh2/SSH2.C:2881: Entering event loop.
warning: Connecting to vftp.fidelitone.com failed: No address associated to the name

ssh_sigchld_real_callbackpecific error condition
ssh_sigchld_process_pid: calling handler pid 1320600 code 178
Warning: child process (/sys$system/tcpip$ssh_ssh2) exited with code 178.
SshReadLine/SSHREADLINE.C:3728: Uninitializing ReadLine...


%TCPIP-E-SSH_FC_ERROR, error in ssh file transfer operation

I'm still guessing it's best to wait and find out what the other side might have
done.

[David Froble]

<begin rant>

Well, I've provided services on VMS that allow inventory inquiry and placing
orders. Most of the trading partners really like them and have made use of
them. But, you're always, sooner or later, going to run into the trading
partner that declares, "this is the way we do things, and the only way we will
do things". Their solution is that my customer must use SFTP to pull quote
requests and purchase orders from their server, and use SFTP to send back the
quotes, ASNs, and invoices.

Well, it's not all bad. The customer wants to do the business. So every time
there is a problem, we get to spend time looking at it, and charge the customer
the "big bucks". Works for me ...

</end rant>

[David Froble]

A bit more data. The VMS system is using TCPIP V5.6 ECO5. I'm wondering if an
upgrade to TCPIP V5.7 ECO5 might solve the problem, if indeed the trading
partner has upgraded their system to a newer version of SSH which blocks
connections with the old SSH?

Then I must ask, can TCPIP V5.7 ECO5 be used on VMS V8.3?

[Bob Gezelter]

David,

There were several ciphers retired due to security issues (see http://www.openssh.com/txt/release-6.7 for the list for OpenSSH). OpenVMS does not use SSH, but the partner system being accessed likely does. I have been told that OpenVMS TCP/IP 5.7 ECO5 contains the new cipher suite.

However, in your posted connection log, I note:

debug( 2-MAR-2016 01:03:15.40): SshConfig/SSHCONFIG.C:3364: Unable to open
/DISK0/codis_ssh/ssh2/ssh2_config
debug( 2-MAR-2016 01:03:15.40): Connecting to vftp.fidelitone.com, port 22...
(SOCKS not used)
debug( 2-MAR-2016 01:03:15.40): Ssh2/SSH2.C:2881: Entering event loop.
warning: Connecting to vftp.fidelitone.com failed: No address associated to the name

The missing configuration file is one thing (without a configuration file you will get defaults, YMMV). I also note the "no address associated" message. Are you sure that DNS is working correctly?

[li...@openmailbox.org]

It's not only Linux. OpenBSD (OpenBSD developers maintain OpenSSH and host
the project) also removed ciphers in several recent releases.

> The best answer is to update the OpenVMS SSH to a current version.

Normally it is probably a bad policy upgrade when something stops working.
But in this case (SSH) I strongly agree with you for two reasons. One, the
SSH updates did break compatibility so there is very good reason to
believe upgrading will fix the problem. Two, bug fixes are happening all
too frequently with SSH. Since we're talking about security it is good to
have the best copy available. This is used heavily and OpenBSD users get
the updates before they spread to the world at large and so have another
layer of testing. By the time non-OpenBSD systems get the code it is
normally in good shape.

Not so with OpenSSL where new code is not necessarily better than old...

[li...@openmailbox.org]

On Tue, 01 Mar 2016 19:08:59 -0500
David Froble via Info-vax <info...@rbnsn.com> wrote:

> What I'm wondering about is possible problems with newer versions of SSH.
> Currently the client cert is from July, 2011, and dsa 1024.

That is too weak. They should be using _at least_ 2048 and 4096 would be
better so they don't have to do this again in a couple of years.

[li...@openmailbox.org]

On Wed, 02 Mar 2016 01:10:36 -0500

David Froble via Info-vax <info...@rbnsn.com> wrote:

> Further research, using the -vvv switch, says that the file SSH2_CONFIG
> is missing. I'm not sure that this file ever existed. But, never trust
> the customers, who knows what they might do ....

I have never seen this file not be present when SSH is working.

> If required, where do I get, or build, this file?

You should download the code for the version they're running and extract
the config. You'll have to go over it, of course. The defaults may not be
suitable. But it would be better to upgrade to the latest stable version.

> Some of the diagnostics:
>
> debug( 2-MAR-2016 01:03:15.40): SshConfig/SSHCONFIG.C:3364: Unable to
> open /DISK0/codis_ssh/ssh2/ssh2_config
> debug( 2-MAR-2016 01:03:15.40): Connecting to vftp.fidelitone.com, port
> 22... (SOCKS not used)
> debug( 2-MAR-2016 01:03:15.40): Ssh2/SSH2.C:2881: Entering event loop.
> warning: Connecting to vftp.fidelitone.com failed: No address associated
> to the name

DNS failure, too?

[li...@openmailbox.org]

On Wed, 2 Mar 2016 07:01:48 +0000
lists--- via Info-vax <info...@rbnsn.com> wrote:

> On Tue, 01 Mar 2016 19:08:59 -0500

> David Froble via Info-vax <info...@rbnsn.com> wrote:
>

> > What I'm wondering about is possible problems with newer versions of
> > SSH. Currently the client cert is from July, 2011, and dsa 1024.
>

> That is too weak. They should be using _at least_ 2048 and 4096 would be
> better so they don't have to do this again in a couple of years.

I should have mentioned they should use RSA keys rather than DSA. DSA has
built in size limitations for software compatibility reasons (not
technical ones). DSA/1024 is really not safe to use and has not been for
several years.

[Steven Schweda]

> warning: Connecting to vftp.fidelitone.com failed: No
> address associated to the name

I'd worry about that (DNS?) before I started looking for
more exotic trouble. The failure which I assume is related
to a too-new SSH server might look more like this:

alp $ ssh -vvv pro3 ! (A Mac.)
debug( 2-MAR-2016 01:25:05.97): Connecting to pro3, port
22... (SOCKS not used)
debug( 2-MAR-2016 01:25:05.97): Ssh2/SSH2.C:2881: Entering
event loop.
debug( 2-MAR-2016 01:25:06.00): Ssh2Client/SSHCLIENT.C:1655:
Creating transport protocol.
debug( 2-MAR-2016 01:25:06.00):
SshAuthMethodClient/SSHAUTHMETHODC.C:104: Added
"hostbased" to usable methods.
[...]
debug( 2-MAR-2016 01:25:06.02): Remote version:
SSH-2.0-OpenSSH_6.9
debug( 2-MAR-2016 01:25:06.02): OpenSSH: Major: 6 Minor: 9
Revision: 0
debug( 2-MAR-2016 01:25:06.02):
Ssh2Transport/TRCOMMON.C:1857: All versions of OpenSSH
handle kex guesses incorrectly.
debug( 2-MAR-2016 01:25:06.02):
Ssh2Transport/TRCOMMON.C:1935: Using Client order for common
key exchange algorithms.
debug( 2-MAR-2016 01:25:06.02):
Ssh2Transport/TRCOMMON.C:1139: Sending packet with type 2 to
connection
debug( 2-MAR-2016 01:25:06.03):
Ssh2Transport/TRCOMMON.C:1139: Sending packet with type 20
to connection
debug( 2-MAR-2016 01:25:06.03):
Ssh2Transport/TRCOMMON.C:2832: >TR packet_type=20
debug( 2-MAR-2016 01:25:06.03):
Ssh2Transport/TRCOMMON.C:2394: lang s to c: `',
lang c to s: `'
debug( 2-MAR-2016 01:25:06.03):
Ssh2Transport/TRCOMMON.C:2410: Couldn't agree on
kex or hostkey alg. (chosen_kex = NULL, chosen_host_key =
ssh-dss)
debug( 2-MAR-2016 01:25:06.03):
Ssh2Transport/TRCOMMON.C:1139: Sending packet with type 2 to
connection
debug( 2-MAR-2016 01:25:06.03):
Ssh2Transport/TRCOMMON.C:1139: Sending packet with type 1 to
connection
debug( 2-MAR-2016 01:25:06.03): Ssh2Common/SSHCOMMON.C:180:
DISCONNECT received:
Algorithm negotiation failed.
debug( 2-MAR-2016 01:25:06.03):
SshReadLine/SSHREADLINE.C:3728: Uninitializing ReadLine...
warning: Authentication failed.
debug( 2-MAR-2016 01:25:06.04): Ssh2/SSH2.C:327:
locally_generated = TRUE
Disconnected; key exchange or algorithm negotiation failed
(Algorithm negotiation failed.).
[...]

ALP $ tcpip show vers

HP TCP/IP Services for OpenVMS Alpha Version V5.7 - ECO 5
on a COMPAQ Professional Workstation XP1000 running OpenVMS V8.4

So I wouldn't get my hopes up if your problem extends beyond
bad name resolution.

[Joukj]

I do not think the ciphers are included. Also with ECO5, I had to change
the configuration on my linux-systems to enable the "obsolete" ciphers

i.e. in /etc/ssh/sshd_config I had to add:
Ciphers
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@opensr

MACs
umac-...@openssh.com,umac-1...@openssh.com,hmac-sha2-256-etm@openssh6

KexAlgorithms
curve255...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp381


Jouk

[Craig A. Berry]

On 3/2/16 1:34 AM, Steven Schweda wrote:

> debug( 2-MAR-2016 01:25:06.02):
> Ssh2Transport/TRCOMMON.C:1935: Using Client order for common
> key exchange algorithms.

. . .

> debug( 2-MAR-2016 01:25:06.03):
> Ssh2Transport/TRCOMMON.C:2410: Couldn't agree on
> kex or hostkey alg. (chosen_kex = NULL, chosen_host_key =
> ssh-dss)

. . .

> Disconnected; key exchange or algorithm negotiation failed
> (Algorithm negotiation failed.).

I get the same thing. Oddly, ssh-dss does not appear in the list of
supported ciphers on the VMS side (nor, of course, on the OpenSSH server
side). So the "client order" that causes it to try to connect with a
deprecated cipher is something not chosen from the list of available
ciphers. It looks like TCP/IP Services did upgrade its list of ciphers,
but uses some other list for what to try when connecting.

Wonderful.

For documentation on downgrading your OpenSSH installation to match what
VMS is doing, see:

<http://www.openssh.com/legacy.html>

Page 14 of:

<http://h20565.www2.hpe.com/hpsc/doc/public/display?docId=emr_na-c04622264>

has some info on configuration files on the VMS side. The template file
has a line that says "Ciphers AnyCipher". Perhaps some other value
instead of AnyCipher would do the trick. Or perhaps simply installing
the default configuration file would override whatever hard-coded
defaults are in the ssh client.

I will try to experiment later and post results, but hopefully by then
one of you will have found the magic button that tells the VMS ssh
client to attempt connections using ciphers it has rather than ciphers
it doesn't have.

[John E. Malmberg]

On 3/2/2016 4:57 AM, Joukj wrote:
> Bob Gezelter wrote:
>> On Wednesday, March 2, 2016 at 1:27:21 AM UTC-5, David Froble wrote:
>>> Stephen Hoffman wrote:
>>>>
>>> A bit more data. The VMS system is using TCPIP V5.6 ECO5. I'm
>>> wondering if an upgrade to TCPIP V5.7 ECO5 might solve the problem,
>>> if indeed the trading partner has upgraded their system to a newer
>>> version of SSH which blocks connections with the old SSH?
>>>
>>> Then I must ask, can TCPIP V5.7 ECO5 be used on VMS V8.3?

There should be an SPD for it somewhere that can answer that question.

>> There were several ciphers retired due to security issues (see
>> http://www.openssh.com/txt/release-6.7 for the list for OpenSSH).
>> OpenVMS does not use SSH, but the partner system being accessed likely
>> does. I have been told that OpenVMS TCP/IP 5.7 ECO5 contains
>> the new cipher suite.
>>
> I do not think the ciphers are included. Also with ECO5, I had to change
> the configuration on my linux-systems to enable the "obsolete" ciphers
>
> i.e. in /etc/ssh/sshd_config I had to add:
> Ciphers
> aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@opensr
>
> MACs
> umac-...@openssh.com,umac-1...@openssh.com,hmac-sha2-256-etm@openssh6
>
> KexAlgorithms
> curve255...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp381

For OpenSSH 6.7 on Cygwin, I had to add the following line to get
OpenVMS/IA64 8.4, TCPIP ECO 5 to work:

# jem: Need to downgrade KexAlgorithm for compatibilty with
# OpenVMS

KexAlgorithms
curve255...@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256,diffie-hellman-group1-sha1

(Above is one long line)

It did not work for OpenVMS/Alpha 8.4, TCP/IP 5.7 ECO 4.

I just recently downloaded TCP/IP 5.7 ECO 5 for Alpa under the Hobby
program. I will try that later along with your changes.

I tried using 2048 bit DSA keys, which VMS TCP/IP 5.7 will generate. I
discovered that the SSH program current for one of Fedora Core 22 or
Ubuntu 14.04 knows positively that DSA keys are 1024 bits and refuse to
deal with the 2048 bit DSA keys.

And David, the "[.ssh2]ssh2_config" file is optional. It is used to add
default options for outgoing SSH commands. SSH from the DCL command
line will always use it if present. SSH from inside other programs may
or may not.

Regards,
-John
wb8...@qsl.network

[li...@openmailbox.org]

On Wed, 2 Mar 2016 07:26:58 -0600
"John E. Malmberg via Info-vax" <info...@rbnsn.com> wrote:

> I tried using 2048 bit DSA keys, which VMS TCP/IP 5.7 will generate. I
> discovered that the SSH program current for one of Fedora Core 22 or
> Ubuntu 14.04 knows positively that DSA keys are 1024 bits and refuse to
> deal with the 2048 bit DSA keys.

Yeah, I mentioned that upthread:

> On Wed, 2 Mar 2016 07:01:48 +0000
> lists--- via Info-vax <info...@rbnsn.com> wrote:
>

>> > What I'm wondering about is possible problems with newer versions of
>> > SSH. Currently the client cert is from July, 2011, and dsa 1024.
>>

> That is too weak. They should be using _at least_ 2048 and 4096 would be
> better so they don't have to do this again in a couple of years.
>
> I should have mentioned they should use RSA keys rather than DSA. DSA has
> built in size limitations for software compatibility reasons (not
> technical ones). DSA/1024 is really not safe to use and has not been for
> several years.

> And David, the "[.ssh2]ssh2_config" file is optional. It is used to add
> default options for outgoing SSH commands. SSH from the DCL command
> line will always use it if present. SSH from inside other programs may
> or may not.

That sounds ok actually on second thought. A missing sshd_config on the
other hand is not a good idea. Recent copies might have reasonable defaults
but one thing that was very bad until recently was allowing root logins by
default. Not sure how that plays out on VMS though. There is also the
roaming issue that can be fixed in code or via changing the config. You
ought to at least set UseRoaming No in your ssh_config if you don't have
newish copy of SSH and if indeed roaming is supported in your
version/implementation of SSH.

[Steven Schweda]

> >>> Then I must ask, can TCPIP V5.7 ECO5 be used on VMS V8.3?
>
> There should be an SPD for it somewhere that can answer that
> question.

Around here, SYS$HELP:TCPIP057.RELEASE_NOTES says:
[...]
________________________ Note ________________________

TCP/IP Services Version 5.7 is supported on OpenVMS
Alpha and OpenVMS for Integrity servers systems only.
On VAX systems, use TCP/IP Services Version 5.3.

To use TCP/IP Services Version 5.7, you must upgrade
to OpenVMS Version 8.4 or higher.

______________________________________________________
[...]

ECO5 is a complete-product kit, so it could be more
permissive, but I'd guess not.

[David Froble]

That was one of my first questions. Yes, the DNS name service is working, for
that specific URL, on the system in question. At least NSLOOKUP says it's working.

[David Froble]

Well, we're talking lawn mower parts, not money. Nor does my customer care much
about security. (Not saying I agree with them, but there are the 2 rules about
customers.)

What causes me some problems with the whole idea of breaking something that
previously worked is, did any such new distribution include the information
"using this new version may cause some production procedures to stop working"?

Now I'm aware that some "geeks" don't really care about "production". Going on
about such isn't really productive, so I'll drop that subject.

But, yes, thanks for the info and suggestions. I'm still waiting to see if the
trading partner has indeed started using newer SSH.

[Bob Gezelter]

David,

I have had cipher negotiation failures. "No address associated with <name>" is something I have not seen with a negotiation failure (as I believe Steve noted). Some experimentation with connecting back to oneself via a name might be in order.

[Stephen Hoffman]

TCP/IP Services V5.7 is supported with OpenVMS I64 V8.3-1H1 and V8.4,
per the SPD.
http://h71000.www7.hp.com/doc/spdtcpip57.pdf

OpenVMS I64 V8.3-1H1 has fallen off of new-patch support, however.
Nothing on VAX and nothing prior to V8.4 has new-patch support. Alpha
has less than a year of new-patch support.
http://hp.com/go/openvms/roadmap

On 2016-03-02 10:57:55 +0000, Joukj said:

> I do not think the ciphers are included.

The current ECO5 patch includes three "new" ciphers; aes128-ctr,
aes192-ctr and aes256-ctr. The entire list of ciphers from ECO4 and
prior are considered insecure, however.

If connection security is an issue, it's usually most appropriate to
upgrade to ECO5 everywhere, and disable everything prior to CTR on
those servers.

[Stephen Hoffman]

On 2016-03-02 06:10:36 +0000, David Froble said:

> warning: Connecting to vftp.fidelitone.com failed: No address
> associated to the name

This reeks of a DNS or networking problem. Could be either a DNS cache
corruption local to the originating host, or bad data from some or all
of a pool of DNS servers, or (unlikely, but possible) malicious
activity.

[Kerry Main]

If this is the case, then this is likely a good example of not keeping
current with changing security standards. While many think this means
only for when they have external clients, it is important to note that
most security groups today are much more worried about internal issues.

As the world continues to move to a more "connected" universe, keeping
current with various standards (esp security) is going to become a much
bigger issue in the future.

[yes, I know some times our hands are tied, but the clients need to
understand that not keeping current with minimum security standards
is like receiving a mandatory safety recall fix for their car, but then
choosing to ignore it.]

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[Bob Gezelter]

David,

A small suggestion: Use a Linux/Windows station/laptop to attempt an SSH connection to the trading partner's SSH server (with the debugging traces enabled). Whether the connection succeeds or not is besides the issue, the differential trace output can be illuminating.

[li...@openmailbox.org]

On Wed, 2 Mar 2016 15:08:33 +0000
Kerry Main via Info-vax <info...@rbnsn.com> wrote:

> [yes, I know some times our hands are tied, but the clients need to
> understand that not keeping current with minimum security standards
> is like receiving a mandatory safety recall fix for their car, but then
> choosing to ignore it.]

We're all going to see this again at some point when they finally
acknowlege ECC is backdoored/unsafe and flip that off in an update release.
I turned it off on all my boxes when I figured out the previous
musical ciphers fiasco.

[li...@openmailbox.org]

On Wed, 02 Mar 2016 09:41:50 -0500

David Froble via Info-vax <info...@rbnsn.com> wrote:

> li...@openmailbox.org wrote:
> > On Wed, 2 Mar 2016 07:01:48 +0000
> > lists--- via Info-vax <info...@rbnsn.com> wrote:
> >
> >> On Tue, 01 Mar 2016 19:08:59 -0500
> >> David Froble via Info-vax <info...@rbnsn.com> wrote:
> >>
> >>> What I'm wondering about is possible problems with newer versions of
> >>> SSH. Currently the client cert is from July, 2011, and dsa 1024.
> >> That is too weak. They should be using _at least_ 2048 and 4096 would
> >> be better so they don't have to do this again in a couple of years.
> >
> > I should have mentioned they should use RSA keys rather than DSA. DSA
> > has built in size limitations for software compatibility reasons (not
> > technical ones). DSA/1024 is really not safe to use and has not been for
> > several years.
> >
> >
>
> Well, we're talking lawn mower parts, not money. Nor does my customer
> care much about security. (Not saying I agree with them, but there are
> the 2 rules about customers.)

If they have anything else on that box, like accounting info etc. they're
asking for trouble using DSA keys.

> What causes me some problems with the whole idea of breaking something
> that previously worked is, did any such new distribution include the
> information "using this new version may cause some production procedures
> to stop working"?
>
> Now I'm aware that some "geeks" don't really care about "production".
> Going on about such isn't really productive, so I'll drop that subject.

I agree with you. This was a screwup and fortunately it's rare with these
guys. They should have deprecated the ciphers and key exchange methods they
wanted to discontinue and issued nastygrams for a couple of releases. They
just turned them off. Oh, I'm sure if anybody read the doc they could have
found this mentioned somewhere but a lot of people got nailed by this. I had
several boxes on my network that went AWOL after the update and I read
similar things here a few months after that. I'm have a number of OpenBSD
machines running -stable (patch branch) so I get the advantage (yeah,
sortof) of the updates earlier than people running other OS or only
-release.

[Steven Schweda]

> [...] the DNS name service is working, for that specific URL, on the

> system in question. At least NSLOOKUP says it's working.

URL? (Host name?) It's possible for nslookup to work
even if the name resolution is misconfigured. As usual,
showing actual commands with their actual output can be more
helpful than vague descriptions or interpretations.

For what it's worth, when I tried:
ssh -vvv vftp.fidelitone.com
I got no complaint about name resolution, but I did get the
(now usual, depressing):

debug( 2-MAR-2016 09:42:10.23):

Ssh2Transport/TRCOMMON.C:2410: Couldn't agree on
kex or hostkey alg. (chosen_kex = NULL, chosen_host_key =
ssh-dss)

From the Mac, I got a bunch of "debug2:
kex_parse_kexinit:" messages with lists of algorithms,
followed by what looked like a successful key exchange.
Also:

debug1: Local version string SSH-2.0-OpenSSH_6.9
debug1: Remote protocol version 2.0, remote software version
CrushFTPSSHD

http://www.crushftp.com/ suggests that their products
might get updates more frequently than anything on VMS.

[li...@openmailbox.org]

I'm not replying to your message (hence, unattributed) but I don't have the
relevant post and this is as good as any so:

> I got no complaint about name resolution, but I did get the
> (now usual, depressing):
>
> debug( 2-MAR-2016 09:42:10.23):
> Ssh2Transport/TRCOMMON.C:2410: Couldn't agree on
> kex or hostkey alg. (chosen_kex = NULL, chosen_host_key =
> ssh-dss)

dss is ok. That's the DSA key. The problem in this debug info is lack of
agreement on Key Exchange algorithms. That is something that is based on
the client's ssh_config and the host's sshd_config.

David, maybe print out both of those and take a look. You might not see
anything, unfortunately because the defaults are not present in the
*_configs- unlike many other SSH defaults that _are_ shown in the configs
but commented-out. If you find the doc for the releases you are using on the
client and server the defaults for key exchange methods should be
documented under the KexAlgorithms parameter. If there is not at least one
in common there is going to be a problem.

[Stephen Hoffman]

On 2016-03-02 15:08:33 +0000, Kerry Main said:

> If this is the case, then this is likely a good example of not keeping
> current with changing security standards.

Yes, upgrading off of anything prior to OpenVMS V8.4 and getting to
"current" versions and patches is important. But as for changing
security standards? This is HPE OpenVMS. Which — off the top —
features down-revision OpenSSL. Down-revision Apache. Down-revision
ssh. Down-revision NTP. Down-revision Tomcat. Down-revision Java.
Down-revision ISC BIND. Utterly unsupported CDSA as the "security"
infrastructure, and which apparently led HPE to roll their own private
replacement for the CDSA kit-signing infrastructure. A brand-new
SMTP server that defaults to an open relay. Rather than one digital
certificate infrastructure, OpenVMS has at least three completely
disjoint and incomplete and manually-maintained and arcane digital
certificate infrastructures. There's no full-disk encryption
support. The patch infrastructure is manual, and multi-step, and with
no integrated notifications.

Need I keep going? Because I can...

The security world does not work at the classic OpenVMS software
development and deployment cycles, either. You're getting scanned for
vulnerabilities before the patches are ready. The attackers have
automated, and can scan the whole of the active IPv4 internet — from a
single host — in about four minutes. The scans are faster than that,
from a botnet. But I digress.

Yes, VSI has more than a little fodder for enhancements and upgrades here.

[David Froble]

What I read on the HP site included V8.3, but, I'm leaning toward updates to
"latest everything".

[David Froble]

Well, on a bit of a side track, someone with the trading partner mentioned:

"There has been no change to our server and we use a Windows based software
CrushFTP."

Now, when on the trading partner's system, the directory and file names are CASE
SENSITIVE! Not that I get out much, but, I didn't think weendoze systems were
case sensitive?

This is getting weird ....

[Steven Schweda]

> Now, when on the trading partner's system, the directory
> and file names are CASE SENSITIVE! Not that I get out much,
> but, I didn't think weendoze systems were case sensitive?
>
> This is getting weird ....

Probably not so weird. You're talking to an FTP server,
not to the file system. (I assume, having only your vague
description of what you did, and your interpretation of what
happened when you did it.) It's easy to write a
case-sensitive program over a case-insensitive file system.
(Especially when it's "an extremely powerful, easy to use
solution that runs on almost everything: OS X 10.5 - 10.9+,
WinXP - Win2012+, Linux, Solaris, BSD, Unix, etc!" There may
be a case-sensitive file system or two in there.)

> "There has been no change to our server [...]"

In the land of Windows Update, changes may occur which may
be noticed by not everyone.

[Phillip Helbig (undress to reply)]

In article <nb5ap6$d6o$1...@dont-email.me>, David Froble

<da...@tsoft-inc.com> writes:

> Nothing has changed on the VMS side. I've made inquiries about possible changes
> on the other side.

I've seen this.

[David Froble]

Yes, that is how I figure it.

But, one mystery cleared up, the previous server, which we stopped using in Nov
2015, was indeed Linux, and of course case sensitive.

[johnwa...@yahoo.co.uk]

Depends on the file system in use on the Window box. You need to
get out more.

If NTFS is in use (as is likely on a modern system since maybe
the mid 1990s), then the file system itself will happily accept
File.txt
FILE.txt
file.txt
and in principle they will be distinct files. This functionality was
needed (and was bodged in) to support POSIX compliance which at one
time was a claimed selling point for Windows NT.
See e.g. https://support.microsoft.com/en-us/kb/100625

Windows being a modern operating system, the case dependency wasn't
architected in, and worse still it doesn't propagate as far as the
user, so the user of standard Win32 tools can only see one of those
three files (according to the MS article above, and according to my
dim and distant past experience of things failing in mysterious ways).

This kind of thing makes life quite interesting if people attempt
to use a Window box to host files for a world which expects upper
and lower case versions of the same file to be properly distinct.

Or something like that.

Does it help at all?

[Jan-Erik Soderholm]

Den 2016-03-02 kl. 18:25, skrev David Froble:

>
> Well, on a bit of a side track, someone with the trading partner mentioned:
>
> "There has been no change to our server and we use a Windows based software
> CrushFTP."
>

OK, then I'd try to setup a test environment where you have full
conotrol on both ends of the link. I guess you already have a
VMS environment that is like your customers, so you only
have to fix a Windows box with that CrushFTP tool.

http://www.crushftp.com/

You can download free for 30 days or pay $40 for the "smallest"
license...

[Craig A. Berry]

On 3/2/16 10:29 AM, li...@openmailbox.org wrote:
> I'm not replying to your message (hence, unattributed) but I don't have the
> relevant post and this is as good as any so:
>
>> I got no complaint about name resolution, but I did get the
>> (now usual, depressing):
>>
>> debug( 2-MAR-2016 09:42:10.23):
>> Ssh2Transport/TRCOMMON.C:2410: Couldn't agree on
>> kex or hostkey alg. (chosen_kex = NULL, chosen_host_key =
>> ssh-dss)
>
> dss is ok. That's the DSA key. The problem in this debug info is lack of
> agreement on Key Exchange algorithms. That is something that is based on
> the client's ssh_config and the host's sshd_config.

Right, sort of. ssh-dss as a host key algorithm is considered weak and
is disabled on OpenSSH 7.0 and later, but it doesn't look like that is
(yet) the issue here since it's the key exchange algorithm (chosen_kex)
that isn't getting selected.

I misspoke earlier in referring to all the various crypto algorithms
involved in ssh negotiation as ciphers. That is only one of about five
different algorithms. Cipher and MAC can be set in the configuration or
on the command line, and even by the VMS client. Key exchange and host
key algorithms can be set by OpenSSH configurations (or on the command
line) but these features do not appear to be available in the VMS ssh
client.

So as far as I can tell, the ciphers were upgraded on TCP/IP Services
v5.7 ECO5, but the key exchange (and possibly host key) algorithms were
not brought up-to-date, and/or there was no provision for configuring to
use more secure algorithms.

> David, maybe print out both of those and take a look. You might not see
> anything, unfortunately because the defaults are not present in the
> *_configs- unlike many other SSH defaults that _are_ shown in the configs
> but commented-out. If you find the doc for the releases you are using on the
> client and server the defaults for key exchange methods should be
> documented under the KexAlgorithms parameter. If there is not at least one
> in common there is going to be a problem.

There are, by default, no configuration files for SSH on VMS. You can
extract templates from the relevant text library, edit them, and put
them in a canonical location by following the documentation to which I
posted a link up-thread. Since so far as I can see there is no
KexAlgorithms parameter in the VMS implementation, there is no way to
select an adequate key exchange algorithm on VMS via any mechanism,
configuration file or otherwise. Do please prove me wrong, as I really
wish this were not true.

[li...@openmailbox.org]

On Wed, 2 Mar 2016 21:14:35 -0600
"Craig A. Berry via Info-vax" <info...@rbnsn.com> wrote:

> On 3/2/16 10:29 AM, li...@openmailbox.org wrote:
> > I'm not replying to your message (hence, unattributed) but I don't have
> > the relevant post and this is as good as any so:
> >
> >> I got no complaint about name resolution, but I did get the
> >> (now usual, depressing):
> >>
> >> debug( 2-MAR-2016 09:42:10.23):
> >> Ssh2Transport/TRCOMMON.C:2410: Couldn't agree on
> >> kex or hostkey alg. (chosen_kex = NULL, chosen_host_key =
> >> ssh-dss)
> >
> > dss is ok. That's the DSA key. The problem in this debug info is lack of
> > agreement on Key Exchange algorithms. That is something that is based on
> > the client's ssh_config and the host's sshd_config.
>
> Right, sort of. ssh-dss as a host key algorithm is considered weak and
> is disabled on OpenSSH 7.0 and later, but it doesn't look like that is
> (yet) the issue here since it's the key exchange algorithm (chosen_kex)
> that isn't getting selected.

Are you vehemently agreeing with me? I can't see any substantive difference
between what I wrote and what you wrote.

[Joukj]

Stephen Hoffman wrote:
>
> TCP/IP Services V5.7 is supported with OpenVMS I64 V8.3-1H1 and V8.4,
> per the SPD.
> http://h71000.www7.hp.com/doc/spdtcpip57.pdf
>
> OpenVMS I64 V8.3-1H1 has fallen off of new-patch support, however.
> Nothing on VAX and nothing prior to V8.4 has new-patch support. Alpha
> has less than a year of new-patch support.
> http://hp.com/go/openvms/roadmap
>
>
>
> On 2016-03-02 10:57:55 +0000, Joukj said:
>
>> I do not think the ciphers are included.
>
> The current ECO5 patch includes three "new" ciphers; aes128-ctr,
> aes192-ctr and aes256-ctr. The entire list of ciphers from ECO4 and
> prior are considered insecure, however.

The problem is that in "modern" OpenSSH even these ciphers are disabled
by default.

[Craig A. Berry]

You said "dss is ok." It's not ok; it's been deprecated because it's too
weak. If there were a way to get the key exchange algorithm working,
this selection of host key algorithm will start failing any day now.

[Stephen Hoffman]

On 2016-03-03 10:01:14 +0000, Joukj said:

> Stephen Hoffman wrote:
>>
>> On 2016-03-02 10:57:55 +0000, Joukj said:
>>
>>> I do not think the ciphers are included.
>>
>> The current ECO5 patch includes three "new" ciphers; aes128-ctr,
>> aes192-ctr and aes256-ctr. The entire list of ciphers from ECO4 and
>> prior are considered insecure, however.
>
> The problem is that in "modern" OpenSSH even these ciphers are disabled
> by default.

According to the OpenSSH docs (and the local BSD box isn't powered up
to confirm this, and the OS X ssh implementation isn't current), the
ssh server is more constrained than the client.

The default cipher list for the OpenSSH server is:

chacha20...@openssh.com, aes128-ctr, aes192-ctr, aes256-ctr,
aes12...@openssh.com, aes25...@openssh.com

According to the OpenSSH ssh client docs, the supported ciphers are:
3des-cbc, aes128-cbc, aes192-cbc, aes256-cbc, aes128-ctr, aes192-ctr,
aes256-ctr, aes12...@openssh.com, aes25...@openssh.com, arcfour,
arcfour128, arcfour256, blowfish-cbc, cast128-cbc and
chacha20...@openssh.com

The default list for the ssh client is: chacha20...@openssh.com,
aes128-ctr, aes192-ctr,aes256-ctr,
aes12...@openssh.com,aes25...@openssh.com, aes128-cbc, aes192-cbc,
aes256-cbc, 3des-cbc

Which includes the three CTR ciphers that are supported by OpenVMS
starting with TCP/IP Services V5.7 ECO5.


TL;DR: OpenVMS should be able to operate with other OpenSSH client and
server hosts — unless the clients and/or servers have been tightened
beyond the OpenSSH defaults, or unless the remote client or server box
isn't running some variant of OpenSSH.

[li...@openmailbox.org]

On Thu, 3 Mar 2016 07:31:27 -0600

"Craig A. Berry via Info-vax" <info...@rbnsn.com> wrote:

> On 3/2/16 11:11 PM, li...@openmailbox.org wrote:
> > On Wed, 2 Mar 2016 21:14:35 -0600
> > "Craig A. Berry via Info-vax" <info...@rbnsn.com> wrote:
> >
> >> On 3/2/16 10:29 AM, li...@openmailbox.org wrote:
>
>
> >>> dss is ok. That's the DSA key. The problem in this debug info is lack
> >>> of agreement on Key Exchange algorithms. That is something that is
> >>> based on the client's ssh_config and the host's sshd_config.
> >>
> >> Right, sort of. ssh-dss as a host key algorithm is considered weak and
> >> is disabled on OpenSSH 7.0 and later, but it doesn't look like that is
> >> (yet) the issue here since it's the key exchange algorithm (chosen_kex)
> >> that isn't getting selected.
> >
> > Are you vehemently agreeing with me? I can't see any substantive
> > difference between what I wrote and what you wrote.
>
> You said "dss is ok." It's not ok;

We were discussing the trace so that's what my comments referred to,
unsurprisingly. I meant ok as "not the problem in this trace," not ok
generally. Everything in context.

> it's been deprecated because it's too weak.

I said that already. Yesterday. Sounds like you're vehemently agreeing with
me again:

--------------------------------------------------------------------------
From: li...@openmailbox.org
Newsgroups: comp.os.vms
Subject: Re: VMS SSH2 experts, journaymen, hackers,

and just about anyone else

Date: Wed, 2 Mar 2016 07:01:48 +0000
Message-ID: <mailman.189.1456902172....@rbnsn.com>
NNTP-Posting-Date: Wed, 2 Mar 2016 07:05:04 +0000 (UTC)

On Tue, 01 Mar 2016 19:08:59 -0500
David Froble via Info-vax <info...@rbnsn.com> wrote:

> What I'm wondering about is possible problems with newer versions of SSH.
> Currently the client cert is from July, 2011, and dsa 1024.

That is too weak. They should be using _at least_ 2048 and 4096 would be
better so they don't have to do this again in a couple of years.

--------------------------------------------------------------------------

> If there were a way to get the key exchange algorithm working, this
> selection of host key algorithm will start failing any day now.

DH/DSS is too weak because of a widespread software implementation
dependence on 1024 bit keys. The algorithm itself is not broken. I
mentioned this yesterday also:

--------------------------------------------------------------------------
From: li...@openmailbox.org Newsgroups: comp.os.vms
Subject: Re: VMS SSH2 experts, journaymen, hackers,

and just about anyone else

Date: Wed, 2 Mar 2016 07:13:30 +0000
Message-ID: <mailman.190.1456902874....@rbnsn.com>

I should have mentioned they should use RSA keys rather than DSA. DSA has
built in size limitations for software compatibility reasons (not
technical ones). DSA/1024 is really not safe to use and has not been for
several years.

--------------------------------------------------------------------------

It remains to be seen if they will allow reasonable DH pubkey sizes or just
dump it. ECC is next on the chopping block...

[Steven Schweda]

> [...] the ssh server is more constrained than the client.

Yup. I can SSH from the Mac (client) to the TCPIP
(Server), but not the reverse.

> [...] the OS X ssh implementation isn't current [...]

It seems to be current enough to refuse to tolerate a
TCPIP V5.7 - ECO 5 client.

And even if HP updates this stuff, how long before it's
made available to hobbyist peons like me? It's not getting
easier to maintain interest in this stuff.

[David Froble]

I doubt the need.

I'm working under the assumption that the trading partner's weendoze system has
indeed changed, most likely automatic updates, which the users may not even know
about.

I have independently verified that they no longer will accept a SFTP connection
from a VMS V8.3, TCP/IP V5.6 system. As of November, 2015, such connections
were successful.

The VMS system has multiple problems. Not up to date, and flawed DNS services.
The wheels are (hopefully) already in motion to upgrade VMS, insure the latest
TCP/IP, and fix the DNS services.

[Stephen Hoffman]

On 2016-03-03 16:20:29 +0000, Steven Schweda said:

>>
>> [...] the ssh server is more constrained than the client.
>
> Yup. I can SSH from the Mac (client) to the TCPIP
> (Server), but not the reverse.
>
>> [...] the OS X ssh implementation isn't current [...]
>
> It seems to be current enough to refuse to tolerate a TCPIP V5.7 -
> ECO 5 client.

IIRC, the usual issue with accessing OS X and OS X Server was a lack of
support in the OpenVMS ssh client for the requisite keyboard access;
for the ssh client prompting support.

OS X Server is fond of using publickey, gssapi-keyex, gssapi-with-mic,
and keyboard-interactive. Not password.

Which means using certificate keys, as the OpenVMS ssh client didn't
have keyboard-interactive last I checked. Only publickey and password.

The OpenVMS ssh server was looking to use publickey,
keyboard-interactive, password.

Versions involved are OpenVMS V8.4 ECO5 and a mix of 10.9 and later OS
X and OS X Server versions.

TL;DR: set up certificates when accessing into OS X or OS X Server?

> And even if HP updates this stuff, how long before it's made
> available to hobbyist peons like me? It's not getting easier to
> maintain interest in this stuff.

Ayup. Which means working with somebody that has full licenses and
patch access, obviously.

Hopefully VSI gets hobbyist, partner and educational licensing sorted,
among the many other tasks inscribed on Grant's Tome.

In this case, I'd also ask HPE about ECO5 access, as that's
increasingly blocking normal usage and they might be willing to allow
that patch for hobbyists. They might go for it?

[Steven Schweda]

> IIRC, the usual issue with accessing OS X and OS X Server was
> a lack of support in the OpenVMS ssh client for the requisite
> keyboard access; for the ssh client prompting support.

That was then. From a 10.10.5 system:

spro:~ sms$ ssh -V
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011

alp $ ssh spro
warning: Authentication failed.
Disconnected; no more authentication methods available (No
further authentication methods available.).

Now (10.11.3), it dies sooner:

pro3$ ssh -V
OpenSSH_6.9p1, LibreSSL 2.1.8

alp $ ssh pro3
warning: Authentication failed.
Disconnected; key exchange or algorithm negotiation failed
(Algorithm negotiation failed.).


> In this case, I'd also ask HPE about ECO5 access, [...]

ALP $ tcpip show version

HP TCP/IP Services for OpenVMS Alpha Version V5.7 - ECO 5
on a COMPAQ Professional Workstation XP1000 running OpenVMS V8.4

That seems to be part of the current package.

[Stephen Hoffman]

On 2016-03-03 19:31:52 +0000, Steven Schweda said:

> Now (10.11.3), it dies sooner:

So -vvv both versions, and see where it's failing. And see if
certificates work.

[Craig A. Berry]

On 3/3/16 2:14 PM, Stephen Hoffman wrote:
> On 2016-03-03 19:31:52 +0000, Steven Schweda said:
>
>> Now (10.11.3), it dies sooner:
>
> So -vvv both versions, and see where it's failing.

As has been mentioned a couple of times up-thread, the current failure
is because the key exchange algorithm selection is unsuccessful. And I
also mentioned that the mechanisms supported elsewhere for specifying a
key exchange algorithm (or host key algorithm) are not available in the
VMS ssh client. At least I couldn't find them.

debug( 3-MAR-2016 14:37:39.58): Ssh2Transport/TRCOMMON.C:2394: lang s to
c: `', lang c to s: `'
debug( 3-MAR-2016 14:37:39.58): Ssh2Transport/TRCOMMON.C:2410: Couldn't

agree on kex or hostkey alg. (chosen_kex = NULL, chosen_host_key = ssh-dss)

debug( 3-MAR-2016 14:37:39.58): Ssh2Transport/TRCOMMON.C:1139: Sending
packet with type 2 to connection
debug( 3-MAR-2016 14:37:39.58): Ssh2Transport/TRCOMMON.C:1139: Sending
packet with type 1 to connection
debug( 3-MAR-2016 14:37:39.58): Ssh2Common/SSHCOMMON.C:180: DISCONNECT
received: Algorithm negotiation failed.

> And see if certificates work.

Surely it has to agree on a key exchange algorithm before it can do
anything about processing that cert?

[Steven Schweda]

> So -vvv both versions, and see where it's failing.

I did. That was the condensed version.

> And see if certificates work.

Ok, fine. spro is my spare-in-the-basement (for pro3,
which is related to its OS being less than current), so I
hadn't set up my home directory properly there, but, with
some basic stuff in ~/.ssh there:

alp $ ssh spro
Authentication successful.

Last login: Thu Mar 3 15:06:57 2016 from pro3.antinode.info
spro$

After the problems I had (and still haven't worked much
on) with the New Desktop on my main Alpha system after the
VMS V8.4 upgrade, I've been instead using the Mac as my main
desktop system, so I mostly do SSH Mac-to-VMS, seldom
VMS-to-Mac. (I'm starting to get accustomed to a modern Web
browser.) So, it took a while to notice that this had
started failing, and, by then, I had only a vague memory of
its having worked both ways before. Now I'm convinced.

[Stephen Hoffman]

On 2016-03-03 21:02:14 +0000, Craig A. Berry said:

> On 3/3/16 2:14 PM, Stephen Hoffman wrote:
>> On 2016-03-03 19:31:52 +0000, Steven Schweda said:
>>
>>> Now (10.11.3), it dies sooner:
>>
>> So -vvv both versions, and see where it's failing.

> ...

> debug( 3-MAR-2016 14:37:39.58): Ssh2Transport/TRCOMMON.C:2394: lang s
> to c: `', lang c to s: `'
> debug( 3-MAR-2016 14:37:39.58): Ssh2Transport/TRCOMMON.C:2410: Couldn't
> agree on kex or hostkey alg. (chosen_kex = NULL, chosen_host_key =
> ssh-dss)
> debug( 3-MAR-2016 14:37:39.58): Ssh2Transport/TRCOMMON.C:1139: Sending
> packet with type 2 to connection
> debug( 3-MAR-2016 14:37:39.58): Ssh2Transport/TRCOMMON.C:1139: Sending
> packet with type 1 to connection
> debug( 3-MAR-2016 14:37:39.58): Ssh2Common/SSHCOMMON.C:180: DISCONNECT
> received: Algorithm negotiation failed.

That's either edited, or it's not -vvv output, or the ssh tool doesn't
have -vvv.

>> And see if certificates work.
>
> Surely it has to agree on a key exchange algorithm before it can do
> anything about processing that cert?

What I'm seeing on OS X 10.10 is different than what's happening on
10.11, then. Not a huge surprise. With what's visible in the 10.10
-vvv logs, certificates should work.

[Stephen Hoffman]

On 2016-03-03 21:18:09 +0000, Steven Schweda said:

>>
>> So -vvv both versions, and see where it's failing.
>
> I did. That was the condensed version.

Condensed? All I've been able to locate here was a one-liner. Not
the -vvv output. But whatever.

[Craig A. Berry]

On 3/3/16 3:38 PM, Stephen Hoffman wrote:
> On 2016-03-03 21:02:14 +0000, Craig A. Berry said:
>
>> On 3/3/16 2:14 PM, Stephen Hoffman wrote:
>>> On 2016-03-03 19:31:52 +0000, Steven Schweda said:
>>>
>>>> Now (10.11.3), it dies sooner:
>>>
>>> So -vvv both versions, and see where it's failing.
>> ...
>> debug( 3-MAR-2016 14:37:39.58): Ssh2Transport/TRCOMMON.C:2394: lang s
>> to c: `', lang c to s: `'
>> debug( 3-MAR-2016 14:37:39.58): Ssh2Transport/TRCOMMON.C:2410:
>> Couldn't agree on kex or hostkey alg. (chosen_kex = NULL,
>> chosen_host_key = ssh-dss)
>> debug( 3-MAR-2016 14:37:39.58): Ssh2Transport/TRCOMMON.C:1139: Sending
>> packet with type 2 to connection
>> debug( 3-MAR-2016 14:37:39.58): Ssh2Transport/TRCOMMON.C:1139: Sending
>> packet with type 1 to connection
>> debug( 3-MAR-2016 14:37:39.58): Ssh2Common/SSHCOMMON.C:180: DISCONNECT
>> received: Algorithm negotiation failed.
>
> That's either edited, or it's not -vvv output, or the ssh tool doesn't
> have -vvv.

It's an excerpt of -vvv output, similar to what SMS showed earlier.
These were the lines indicating failure, so it didn't seem necessary to
include all the others. This failure prevents it from even getting to
the point of worrying about certificates.

>>> And see if certificates work.
>>
>> Surely it has to agree on a key exchange algorithm before it can do
>> anything about processing that cert?
>
> What I'm seeing on OS X 10.10 is different than what's happening on
> 10.11, then. Not a huge surprise. With what's visible in the 10.10
> -vvv logs, certificates should work.

I never had any trouble doing ssh from VMS to OS X under 10.10 but no
longer have any systems at 10.10 to see what it does now.

[Craig A. Berry]

On 3/3/16 3:54 PM, Stephen Hoffman wrote:
> On 2016-03-03 21:18:09 +0000, Steven Schweda said:
>
>>>
>>> So -vvv both versions, and see where it's failing.
>>
>> I did. That was the condensed version.
>
> Condensed? All I've been able to locate here was a one-liner. Not
> the -vvv output. But whatever.

Perhaps the trouble here is that -vvv doesn't do on the VMS ssh client
what it does on OpenSSH. Apparently -d4 (for debug level 4) comes
closer, and this is what the key exchange portion of ssh -d4 <hostname>
looks like when the remote host is running Mac OS X 10.11.3:

debug( 4-MAR-2016 08:55:10.19): Ssh2Transport/TRCOMMON.C:2178: Computing
algorithms from key exchange.
debug( 4-MAR-2016 08:55:10.19): Ssh2Transport/TRCOMMON.C:2241: client:
kex = diffie-hellman-group1-sha1, hk_alg =
ssh-dss,ssh-rsa,x509v3-sign-dss,x509v3-sign-rsa
debug( 4-MAR-2016 08:55:10.20): Ssh2Transport/TRCOMMON.C:2243: server:
kex =
curve255...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,
hk_alg = ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519
debug( 4-MAR-2016 08:55:10.20): Ssh2Transport/TRCOMMON.C:2394: lang s to

c: `', lang c to s: `'

debug( 4-MAR-2016 08:55:10.20): Ssh2Transport/TRCOMMON.C:2405:
first_kex_packet_follows: FALSE
debug( 4-MAR-2016 08:55:10.20): Ssh2Transport/TRCOMMON.C:2410: Couldn't

agree on kex or hostkey alg. (chosen_kex = NULL, chosen_host_key = ssh-dss)

debug( 4-MAR-2016 08:55:10.20): Ssh2Transport/TRCOMMON.C:1285:
Disconnecting: reason code: 3 message: 'Algorithm negotiation failed.'

So as far as I can see, the VMS ssh client supports only the deprecated
diffie-hellman-group1-sha1 key exchange algorithm and the algorithms
enabled on the server are simply not available on VMS:

$ search sys$system:*ssh*.exe /format=nonull
curve,ecdh,group-exchange-256,group14

%SEARCH-I-NOMATCHES, no strings matched

So none of these algorithms could be selected on VMS even if there were
a way to specify a key exchange algorithm in the VMS ssh client, which
there isn't.

Short of a fix from HPE, I think re-enabling diffie-hellman-group1-sha1
on the server is the only way to get this working currently. Or port
OpenSSH or the PuTTY ssh client.

[Stephen Hoffman]

On 2016-03-04 15:21:28 +0000, Craig A. Berry said:

> Short of a fix from HPE, I think re-enabling diffie-hellman-group1-sha1
> on the server is the only way to get this working currently. Or port
> OpenSSH or the PuTTY ssh client.

Try setting up an RSA key-pair of length of 3072 or so. A long,
not-DSA host key.

[Craig A. Berry]

On 3/4/16 9:59 AM, Stephen Hoffman wrote:
> On 2016-03-04 15:21:28 +0000, Craig A. Berry said:
>
>> Short of a fix from HPE, I think re-enabling
>> diffie-hellman-group1-sha1 on the server is the only way to get this
>> working currently. Or port OpenSSH or the PuTTY ssh client.
>
> Try setting up an RSA key-pair of length of 3072 or so. A long,
> not-DSA host key.

I did. No joy. Key exchange algorithm negotiation fails well before it
selects an authentication method, much less attempts public key
authentication.

[David Froble]

Ok, going to get in trouble .. again ..

This whole mess is an example of ignoring what the computer(s) are there fro in
the first place. To get the job done. Some people have decided to force the
implementation of some new stuff, and have DEPRECATED the old and working stuff.

Yes, I'm well aware that the internet is a dangerous place, and that the "old
stuff" quite likely is no longer secure.

But, if we cannot get the job done, then why do we need the "old stuff", or the
"new stuff", or the internet, for that matter? Shut the whole thing down. Or
just relegate it to "facebook" and such ....

I'm currently working on two problems.

The first one is what started this thread. My fear is that after an upgrade of
VMS, TCP/IP, and SSH, the "job" still won't be getting done.

The second task is figuring out communications with a company that provides
sales tax info on the internet. This task also has run into a security snag,
where the vendor is attempting to force TLS V1.2. Which I cannot do on VMS, at
this time. However, these people must understand business a bit better, as they
have in place alternate URLs which will still support sha1 and SSL3. They would
prefer TLS V1.2, but they seem to prefer even more "doing the job".

Just thought I'd throw out something to think about when you see that word
"DEPRECATE" ....

[Stephen Hoffman]

On 2016-03-04 23:57:41 +0000, David Froble said:

> Ok, going to get in trouble .. again ..

Pending a fix, downgrading the server will work. Until VSI and HPE
get their updates out. Central issue here is that neither of these
two organizations employ particularly rapid deployments. HPE likely
won't, given their OpenVMS roadmap. VSI has yet to create the tools
and achieve the necessary speeds. Assuming VSI reaches stable funding
and achieves somewhat more modern software deployment speeds, then many
OpenVMS customers are going to have their own Memorex guy-in-the-chair
moments.

[Steven Schweda]

> [...] Some people have decided to force the implementation

> of some new stuff, and have DEPRECATED the old and working
> stuff.

"Deprecate" and "disable" are spelled differently for a
reason.

> [...] My fear is that after an upgrade of VMS, TCP/IP, and

> SSH, the "job" still won't be getting done.

That depends on what you'll be upgrading to what. There
seems to be little reason to expect that an upgrade of VMS
from V8.3-1H1 to V8.4 and/or TCPIP from V5.6 - ECO 5 to V5.7
- ECO 5 will have any great benefit here. If HPE (or anyone
else) provides something better, then the prospect could
change.

> Just thought I'd throw out something to think about when
> you see that word "DEPRECATE" ....

What I think is that too many people seem to use it
without knowing its meaning. (But in a population which has
so much trouble with "lose" and "loose", or apostropes in
general, amazement might be an over-reaction.)

[Bob Gezelter]

David,

Facilities are disabled for serious reasons.

As an example, consider the SSLv2 problem (that exposed private keys to attack) disclosed earlier this week (see Risks; http://catless.ncl.ac.uk/Risks/29.31.html).

If an old algorithm exposes a private key, it is a serious problem. Such a problem undermines all of the bases for authentication and authorization.

The tradeoff between speed of fix and the retirement represents a challenge.

- Bob Gezelter, http://www.rlgsc.com

[David Froble]

Sorry Bob, but I'm going to go back to my question, if you cannot use something
to successfully do a job, then as far as that job is concerned, what good is the
"something" in question?

Ya know, things like "the operation was a success, but the patient died".

I realize the problem is VMS hasn't kept up, and currently is not "up to snuff".
Nor do I want to consider "don't use VMS".

[David Froble]

Steven Schweda wrote:
>> [...] Some people have decided to force the implementation
>> of some new stuff, and have DEPRECATED the old and working
>> stuff.
>
> "Deprecate" and "disable" are spelled differently for a
> reason.

Ok, you got me on that one. However, isn't deprecate the prelude to disable?

>> [...] My fear is that after an upgrade of VMS, TCP/IP, and
>> SSH, the "job" still won't be getting done.
>
> That depends on what you'll be upgrading to what. There
> seems to be little reason to expect that an upgrade of VMS
> from V8.3-1H1 to V8.4 and/or TCPIP from V5.6 - ECO 5 to V5.7
> - ECO 5 will have any great benefit here. If HPE (or anyone
> else) provides something better, then the prospect could
> change.

Yes, that is what I fear.

>> Just thought I'd throw out something to think about when
>> you see that word "DEPRECATE" ....
>
> What I think is that too many people seem to use it
> without knowing its meaning. (But in a population which has
> so much trouble with "lose" and "loose", or apostropes in
> general, amazement might be an over-reaction.)

Loosen up ...

:-)

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@info-vax.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: 02-Mar-16 11:39 AM
> To: info...@info-vax.com
> Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>
> Subject: Re: [New Info-vax] VMS SSH2 experts, journaymen, hackers,
> and just about anyone else
>

> On 2016-03-02 15:08:33 +0000, Kerry Main said:
>
> > If this is the case, then this is likely a good example of not keeping
> > current with changing security standards.
>
> Yes, upgrading off of anything prior to OpenVMS V8.4 and getting to
> "current" versions and patches is important. But as for changing
> security standards? This is HPE OpenVMS. Which — off the top —
> features down-revision OpenSSL. Down-revision Apache. Down-
> revision
> ssh. Down-revision NTP. Down-revision Tomcat. Down-revision Java.
> Down-revision ISC BIND. Utterly unsupported CDSA as the "security"
> infrastructure, and which apparently led HPE to roll their own private
> replacement for the CDSA kit-signing infrastructure. A brand-new
> SMTP server that defaults to an open relay. Rather than one digital
> certificate infrastructure, OpenVMS has at least three completely
> disjoint and incomplete and manually-maintained and arcane digital
> certificate infrastructures. There's no full-disk encryption
> support. The patch infrastructure is manual, and multi-step, and with
> no integrated notifications.
>
> Need I keep going? Because I can...
>

mmm.. we all know that OpenVMS was basically ignored in terms of
investments in the later years of DEC, then Compaq, then HP. With
the addition of the many acquisitions HP made (43 when I left in 2012),
it's no wonder OpenVMS (and now HP-UX + NonStop), as well as other
traditional HP products & platforms slowly became less & less important.

Having stated this, the most recent roadmap from VSI has more new
significant updates on 1 page than the last 10 years under HP. Port to
X86-64, new file system, current version of Apache (likely within 4-6
weeks), Java V8, 64 core /1.5TB memory support, new TCPIP stack.

I'd rather glance at the rear view mirror once in a while, but the future
Is better handled looking forward through the front window.

> The security world does not work at the classic OpenVMS software
> development and deployment cycles, either. You're getting scanned for
> vulnerabilities before the patches are ready. The attackers have
> automated, and can scan the whole of the active IPv4 internet — from a
> single host — in about four minutes. The scans are faster than that,
> from a botnet. But I digress.
>

All platforms and all vendors have that challenge today. It's no secret
the Bots are out there working 24x7. Been doing that for years now. Heck,
my home firewall has GEO IP filtering and I see all of the failed attempts
from disallowed country IP's poking at my door. It’s a lot.

> Yes, VSI has more than a little fodder for enhancements and upgrades
> here.
>

Agree 100%. Onward and upward.

:-)

Btw, I am a big fan of Multinet, so my IP stack is pretty current in terms
of standards support. In addition, their current version V5.4 is supported
on VAX V7.3, Alpha V6.2+, IA64 8.2+ so interoperability with older VMS
systems and other OS platforms is very high.

Next version V5.5 of Multinet has completed public beta, so expect the full
V5.5 version to be available shortly. Here are V5.5 updates:
http://www.process.com/psc/products/multinet/multinet-55-beta-test/

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@info-vax.com] On Behalf Of
> David Froble via Info-vax
> Sent: 05-Mar-16 4:40 AM
> To: info...@info-vax.com
> Cc: David Froble <da...@tsoft-inc.com>
> Subject: Re: [New Info-vax] VMS SSH2 experts, journaymen, hackers,
> and just about anyone else
>

[snip..]

> >
> > David,
> >
> > Facilities are disabled for serious reasons.
> >
> > As an example, consider the SSLv2 problem (that exposed private keys
> to attack) disclosed earlier this week (see Risks;
> http://catless.ncl.ac.uk/Risks/29.31.html).
> >
> > If an old algorithm exposes a private key, it is a serious problem. Such a
> problem undermines all of the bases for authentication and
> authorization.
> >
> > The tradeoff between speed of fix and the retirement represents a
> challenge.
> >
> > - Bob Gezelter, http://www.rlgsc.com
>
> Sorry Bob, but I'm going to go back to my question, if you cannot use
> something
> to successfully do a job, then as far as that job is concerned, what good is
> the
> "something" in question?
>
> Ya know, things like "the operation was a success, but the patient died".
>
> I realize the problem is VMS hasn't kept up, and currently is not "up to
> snuff".
> Nor do I want to consider "don't use VMS".

David - if keeping current with security stds and interoperability with
other platforms while using older versions of OpenVMS is Important to
your environment, perhaps it's time to reconsider your choice of IP stack
i.e. Multinet. As I recall, you used to use Multinet as well.

>From my E8.4-2 OpenVMS system running beta V5.5 of Multinet:

$ SSH
Process Software SSH 6.1.5.0
[snip...]

Supported ciphers:
aes128-cbc, aes128-ctr, aes192-cbc, aes192-ctr, aes256-cbc, aes256-ctr,
3des-cbc, 3des-ctr, blowfish-cbc, blowfish-ctr, des...@ssh.com,
rc2...@ssh.com, none

Supported MAC algorithms:
hmac-sha1, hmac-md5, hmac-sha256, hmac-ripemd160, none

[Craig A. Berry]

On 3/5/16 3:39 AM, David Froble wrote:

> Bob Gezelter wrote:

>> If an old algorithm exposes a private key, it is a serious problem.
>> Such a problem undermines all of the bases for authentication and
>> authorization.
>>
>> The tradeoff between speed of fix and the retirement represents a
>> challenge.
>>
>> - Bob Gezelter, http://www.rlgsc.com
>
> Sorry Bob, but I'm going to go back to my question, if you cannot use
> something to successfully do a job, then as far as that job is
> concerned, what good is the "something" in question?
>
> Ya know, things like "the operation was a success, but the patient died".
>
> I realize the problem is VMS hasn't kept up, and currently is not "up to
> snuff". Nor do I want to consider "don't use VMS".

David, I basically agree with you that the patch madness is an epic fail
of the software industry to meet the needs of real people, but it is the
gerbil wheel we're on and no one has come up with a better way to keep
the software we all rely on from skidding off the road.

That said, it's hard to overstate the extreme staleness of the VMS ssh
implementation. The example server I've been using is a Mac with OpenSSH
6.9, which was released in July 2015. It turns out I can connect to this
just fine using an ancient Power Mac running OpenSSH 5.2, released in
February 2009.

Yep, a client box that has been collecting dust with no updates for
seven years works just fine with an up-to-date (though not completely
current) server (and appears to be using aes128-ctr as the key exchange
algorithm, FWIW).

So the VMS ssh client with its single, hard-wired (not configurable) key
exchange algorithm is more like a decade out-of-date, maybe more. That's
a lot of technical debt, and the collection agency has just showed up to
collect what's past due, with interest.

[Craig A. Berry]

On 3/5/16 7:55 AM, Kerry Main wrote:

>>From my E8.4-2 OpenVMS system running beta V5.5 of Multinet:
>
> $ SSH
> Process Software SSH 6.1.5.0
> [snip...]
>
> Supported ciphers:
> aes128-cbc, aes128-ctr, aes192-cbc, aes192-ctr, aes256-cbc, aes256-ctr,
> 3des-cbc, 3des-ctr, blowfish-cbc, blowfish-ctr, des...@ssh.com,
> rc2...@ssh.com, none
>
> Supported MAC algorithms:
> hmac-sha1, hmac-md5, hmac-sha256, hmac-ripemd160, none

That's a somewhat shorter list than what's in TCP/IP 5.7 ECO 5 (see
below), though shorter isn't necessarily worse. What's at issue in this
discussion, though, is not ciphers or MACs, but key exchange algorithms;
what key exchange algorithms does Multinet support?

from ssh -h:

Supported ciphers:


3des-cbc,aes256-cbc,aes192-cbc,aes128-cbc,aes256-ctr,aes192-ctr,aes128-ctr,blowfish-cbc,twofish-cbc,twofish256-cbc,twofish192-cbc,twofish128-cbc,des...@ssh.com,cast128-cbc,rc2...@ssh.com,arcfour,none

Supported MAC algorithms:


hmac-md5,hmac-md5-96,hmac-sha1,hmac-sha1-96,hmac-...@ssh.com,hmac-sh...@ssh.com,hmac-ri...@ssh.com,hmac-rip...@ssh.com,hmac-t...@ssh.com,hmac-tig...@ssh.com,hmac-t...@ssh.com,hmac-tig...@ssh.com,hmac-t...@ssh.com,hmac-tig...@ssh.com,none

[Stephen Hoffman]

On 2016-03-05 13:57:14 +0000, Kerry Main said:

> Having stated this, the most recent roadmap from VSI has more new
> significant updates on 1 page than the last 10 years under HP. Port to
> X86-64, new file system, current version of Apache (likely within 4-6
> weeks), Java V8, 64 core /1.5TB memory support, new TCPIP stack.

Which is wonderful.

But a decade of "ignored" is not simply nor easily recoverable. Not
in this market. What's missing is vastly greater than IP updates,
Java and a new file system, too. This is very far from easy. Not
at the budget VSI can expend. Which inherently means that VSI will
continue to neglect a number of areas, and will continue to fall behind
in those and other areas. Which means the ports off of OpenVMS will
continue. Differentiating the platform when you're running the same
open source packages as many other platforms won't be easy, either.

Once versions of Apache, ssh, TLS, Java, ISC BIND, NTP and the rest are
all being updated and released and deployed at OpenVMS customer sites
on something approaching their upstream schedules, that'll be more
promising than any roadmap.

Far more promising will be wholly new applications and application
ports and new customers arriving faster than the current applications
and customers are departing.

> I'd rather glance at the rear view mirror once in a while, but the
> future Is better handled looking forward through the front window.

I'd prefer to avoid using rose-colored glass, when looking in either direction.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@info-vax.com] On Behalf Of

> Craig A. Berry via Info-vax

> Sent: 05-Mar-16 9:23 AM
> To: info...@info-vax.com
> Cc: Craig A. Berry <craig...@nospam.mac.com>
> Subject: Re: [New Info-vax] VMS SSH2 experts, journaymen, hackers,
> and just about anyone else
>

> On 3/5/16 7:55 AM, Kerry Main wrote:
>
> >>From my E8.4-2 OpenVMS system running beta V5.5 of Multinet:
> >
> > $ SSH
> > Process Software SSH 6.1.5.0
> > [snip...]
> >
> > Supported ciphers:
> > aes128-cbc, aes128-ctr, aes192-cbc, aes192-ctr, aes256-cbc, aes256-ctr,
> > 3des-cbc, 3des-ctr, blowfish-cbc, blowfish-ctr, des...@ssh.com,
> > rc2...@ssh.com, none
> >
> > Supported MAC algorithms:
> > hmac-sha1, hmac-md5, hmac-sha256, hmac-ripemd160, none
>
> That's a somewhat shorter list than what's in TCP/IP 5.7 ECO 5 (see
> below), though shorter isn't necessarily worse. What's at issue in this
> discussion, though, is not ciphers or MACs, but key exchange algorithms;
> what key exchange algorithms does Multinet support?
>

[snip...]

I would not classify myself as any type of expert on security (far from it),
but here is the SPD for the separate SSH product from Process which, by
the way, is also supported running on top of the native TCPIP services:

http://tinyurl.com/SSH-Process

Actual link (beware wrap)
http://www.process.com/psc/fileadmin/user_upload/documents/ssh/ssh_spd.pdf

"The server is authenticated via a public key and the Diffie-Hellman key-
exchange method. Diffie-Hellman uses a 256-bit random number for the
"session key". This key is used to encrypt all further communications in
the session. The SSH v2 client authentication offers the following options:
host-based, public-key, Kerberos 5, password, keyboard-interactive, and
Certificate."

I will find out if this separate SSH product has more, less or the same
capabilities than what is built into the latest Multinet beta V5.5. Will
also see if there is a more current version of the SSH SPD.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@info-vax.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: 05-Mar-16 10:25 AM
> To: info...@info-vax.com
> Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>
> Subject: Re: [New Info-vax] VMS SSH2 experts, journaymen, hackers,
> and just about anyone else
>

[snip..]

>
> I'd prefer to avoid using rose-colored glass, when looking in either
> direction.
>

Glass half full or half empty .. it depends on your viewpoint.

:-)

[Stephen Hoffman]

On 2016-03-05 15:43:38 +0000, Kerry Main said:

> Glass half full or half empty .. it depends on your viewpoint.
>
> :-)

Or the glass is too big.

[David Froble]

Well stated ....

I'm hoping that VSI can address such issues in some reasonable amount of time.
Yeah, "reasonable" will vary from user to user, and for some, it's negative time.

I've also got TLS V1.2 problems also, but a while back I asked Clair Grant about
the new TCP/IP they have on their roadmap, and I believe the reply was TLS V1.0
at first. Tell me again the definition of a "no-op".

I still want my customer to get up-to-date with VMS and TCP/IP. If or when that
still fails, then the only think I can think of at this time is an intermediate
service on another OS playing man-in-the-middle.

But, we're trying to get away from such intermediate stuff, (yes, we have some
in place now), because of the stupid PCI compliance the credit card companies
are pushing. So nice of them to take their problems and push them off onto others.

[Craig A. Berry]

On 3/5/16 12:02 PM, David Froble wrote:

> I've also got TLS V1.2 problems also, but a while back I asked Clair
> Grant about the new TCP/IP they have on their roadmap, and I believe the
> reply was TLS V1.0 at first. Tell me again the definition of a "no-op".

SSL support is not part of TCP/IP Services; it's a separate product
from an unrelated code base, so I don't think the revamp of of the LAN
driver up through the middle of the IP stack is really relevant. OpenSSL
is on the VSI roadmap but no specific mention is made of what versions.

TLS 1.2 looks like it's been in OpenSSL since 1.0.1, which means it
should be in the SSL1 kits released recently by HP:

$ mcr sys$common:[ssl1.ia64_exe]openssl version
OpenSSL 1.0.2c 12 Jun 2015
SSL1 for OpenVMS V1.0 Nov 20 2015

$ pipe mcr sys$common:[ssl1.ia64_exe]openssl s_client -h | search
sys$pipe 1.2
-tls1_2 - just use TLSv1.2

OpenSSL 1.0.2g is now current and 1.1.0 is in testing.

[Stephen Hoffman]

On 2016-03-05 18:02:13 +0000, David Froble said:

> I'm hoping that VSI can address such issues in some reasonable amount
> of time. Yeah, "reasonable" will vary from user to user, and for some,
> it's negative time.

The miasma around OpenVMS Security is substantial. OpenVMS security
is still quite viable against 1990s-vintage and earlier threats.
Against more modern threats, not so much. But I'm being polite.

> I've also got TLS V1.2 problems also, but a while back I asked Clair
> Grant about the new TCP/IP they have on their roadmap, and I believe
> the reply was TLS V1.0 at first. Tell me again the definition of a
> "no-op".

The VSI folks are likely referring to OpenSSL 1.0.2 series (or later),
which gets you TLSv1.2. That's an update from the old and
now-deprecated 0.9.8 series.

HPE has OpenSSL 1.0.2c and TLSv1.2 now, via SSL1 kit. Unfortunately,
OpenSSL 1.0.2g is current, and work on OpenSSL 1.1.0 is well underway.

The TLSv1.3 draft is now available, and that is currently expected to
remove MD5, various weak ciphers, curves and other vulnerable schemes.
Expect OpenSSL to break some APIs when that rolls out, too.

http://openssl.org/policies/releasestrat.html

> I still want my customer to get up-to-date with VMS and TCP/IP. If or
> when that still fails, then the only think I can think of at this time
> is an intermediate service on another OS playing man-in-the-middle.

I'm working in several configurations with OpenVMS increasingly
subsumed further into the background, due to various limitations in
OpenVMS itself.

> But, we're trying to get away from such intermediate stuff, (yes, we
> have some in place now), because of the stupid PCI compliance the
> credit card companies are pushing. So nice of them to take their
> problems and push them off onto others.

Well, some of those other folks have had their own security issues.
More than a few of us have been getting new credit cards issued, after
all. I've been caught in multiple breaches. One local chain has made
a huge deal around accepting credit cards and higher-security payment
options, and then they get breached. Twice.

[Stephen Hoffman]

On 2016-03-05 18:56:52 +0000, Craig A. Berry said:

> SSL support is not part of TCP/IP Services; it's a separate product
> from an unrelated code base, so I don't think the revamp of of the LAN
> driver up through the middle of the IP stack is really relevant.
> OpenSSL is on the VSI roadmap but no specific mention is made of what
> versions.

Yeah; that's one of the various bag-on-the-side "designs" with OpenVMS
and with the current implementation of security and TLS on OpenVMS,
with three separate certificate implementations, the long-deprecated
CDSA, and the rest of the morass.

If VSI continues with that same "design", that would be rather less
promising for the future of OpenVMS security.

Wholly upward-compatible upgrades won't be feasible here, due in no
small part to limitations within the current "design".

Via the HPE SSL1 kit, the VSI folks likely do have access to OpenSSL
1.01c and TLSv1.2.

[David Froble]

Agreed. One can claim that TCP/IP and SSL are two different things. But today
how many people will accept not having encryption? Not many. If you want to
serve the market, then it's TCP/IP with SSL.

I'm working against some inertia, it can be a bit tough to get people to change
things without some 2x4 up alongside the head, such as has happened recently.
If I had my way, every customer would be 100% up to date on VMS, and actively
talking to, or having me talking to, VSI.

"Hey, it's been working for years, why mess with it?"

A not unreasonable statement, since the customers are in the business of selling
lawn mower parts, not running an up to date computer system ....

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@info-vax.com] On Behalf Of

> David Froble via Info-vax
> Sent: 05-Mar-16 4:04 PM
> To: info...@info-vax.com
> Cc: David Froble <da...@tsoft-inc.com>

The counter to that argument is the analogy of a mandatory vehicle
safety recall - perhaps an issue with brakes failing under specific
conditions.

"Hey, the vehicle has been running fine for 2 years, so why do I need
to have this installed now?"

You can ignore it at your own risk, but sound judgement says it is
better to be safe than sorry.

Need to also emphasize that the biggest security risks these days are
from Internal sources - not the Internet.

Hence, letting internal systems run down is like ignoring basic maint.
on internal factory equipment.

[Jan-Erik Soderholm]

Den 2016-03-05 kl. 19:57, skrev Stephen Hoffman:

> On 2016-03-05 18:02:13 +0000, David Froble said:
>
>> I'm hoping that VSI can address such issues in some reasonable amount of
>> time. Yeah, "reasonable" will vary from user to user, and for some, it's
>> negative time.
>
> The miasma around OpenVMS Security is substantial. OpenVMS security is
> still quite viable against 1990s-vintage and earlier threats. Against more
> modern threats, not so much. But I'm being polite.
>
>> I've also got TLS V1.2 problems also, but a while back I asked Clair
>> Grant about the new TCP/IP they have on their roadmap, and I believe the
>> reply was TLS V1.0 at first. Tell me again the definition of a "no-op".
>
> The VSI folks are likely referring to OpenSSL 1.0.2 series (or later),
> which gets you TLSv1.2. That's an update from the old and now-deprecated
> 0.9.8 series.
>
> HPE has OpenSSL 1.0.2c and TLSv1.2 now, via SSL1 kit. Unfortunately,

> OpenSSL 1.0.2g is current...

1.0.2g was released 1-Mars-2016 and was available for Alpha and IA64
the 2-Mars-2016 here: http://wasd.vsm.com.au/wasd/.

I do not know how fixed this build is against the WASD web server
or if it is even usable for anything else at all...

Jan-Erik.

[Stephen Hoffman]

On 2016-03-05 22:37:40 +0000, Jan-Erik Soderholm said:

> 1.0.2g was released 1-Mars-2016 and was available for Alpha and IA64
> the 2-Mars-2016 here: http://wasd.vsm.com.au/wasd/.

Thanks for making my point. Did I mention the dearth of software
integrity mechanisms of OpenVMS, too? That is, basically nothing for
anybody outside HPE and VSI? But thanks for reminding me how
completely awful that whole mess is.

[Jan-Erik Soderholm]

Agree that it a mess, but hats off for Mark Daniels that makes sure
that the security of WASD is up to date at least...

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@info-vax.com] On Behalf Of
> Jan-Erik Soderholm via Info-vax
> Sent: 05-Mar-16 6:34 PM
> To: info...@info-vax.com
> Cc: Jan-Erik Soderholm <jan-erik....@telia.com>
> Subject: Re: [New Info-vax] VMS SSH2 experts, journaymen, hackers,
> and just about anyone else
>

Agree 100% - big kudos to Mark for keeping WASD current.

While I don't think anyone here thinks there is not a lot of work to
do to make up for many years of HP mismanagement of OpenVMS,
let's not forget the state of the security patches on ALL platforms.

As an example, while the many monthly patches for Windows Server
is well known (shades of Patch Tuesdays), Linux is no better:

Red Hat Linux Security Web Site: (NOT bug fixes, JUST security patches)
https://www.redhat.com/archives/enterprise-watch-list/

Click on "Thread" for any month. Add them up. Scroll down and see
If there were any fewer patches last month vs 2 or 4 years ago.

One can argue which platform is better, but after clicking on any of
these "Thread" months, its plain to see that the good guys are not
winning on ANY platform.

Yes, not all patches apply to every system, but from an Operations
perspective, someone has to go through all of these to determine
which ones they should apply and on which OS instance.

Bottom line - lots of security work to cleanup on ALL platforms.

Of course, Operations groups could always adopt the strategy that
many Windows Operations server groups have adopted.

It's a strategy often called "Patch-n-Pray".

:-)

[Stephen Hoffman]

On 2016-03-06 01:52:46 +0000, Kerry Main said:

> While I don't think anyone here thinks there is not a lot of work to do
> to make up for many years of HP mismanagement of OpenVMS, let's not
> forget the state of the security patches on ALL platforms.

Yes. But then for those other platforms, I don't have to periodically
log into a web site to look for updates, don't have to navigate through
the ever-changing patch web page with the random-patch-ordering
display, find and select and download and unpack and read the master
listing, uncheck what's already installed from the dependency
processing, then find and select and download and FTP the patches
around to the target servers, unzip the patches, confirm the dependency
order and prerequisites, and install each of the patches manually.

OpenVMS has rather fewer of the current patches too, delayed
availability for those patches that are available, and a baroque and
entirely manual patch installation sequence.

> Of course, Operations groups could always adopt the strategy thatmany
> Windows Operations server groups have adopted.
> It's a strategy often called "Patch-n-Pray".
>
> :-)

Ayup. But then Microsoft Windows has tools to automate notification
and remote installation of patches, among other useful features.
Management and automation features lacking on OpenVMS.

To HPE's credit, OpenVMS hasn't had a regression with an UPDATE patch
in a few years, which is a good start toward the ability to install
patches on many servers with fewer local tests.

Toward gaining the trust of system managers to more rapidly apply the
patches, for that matter.

Though the UPDATE patches are rather heavyweight and are available far
less frequently than security updates can require, and particularly as
compared with where we're all headed.

We're all going to be applying patches going forward, and we're all
going to need to do that far more quickly. That's inevitable.
That's particularly inevitable, given VSI is effectively obligated to
make use of common and open source packages for commodity operating
system functions, as writing wholly new packages is a far larger
project, and any rewrite will require dealing with all those cases and
inconsistencies and incompatibilities and vulnerabilities that the
existing software packages already deal with. So VSI will be left
with a choice to investigate and to ship patches for an increasing
number of upstream software providers — and to increasingly manage
cases where the customers will know that there are patches for issues
with the open source packages, too.

This is the software environment that we are in, and nobody — not
Microsoft, not Red Hat, not VSI — has a better answer. Some — not VSI
— make dealing with this environment easier.

Now if you want to discuss why these security vulnerabilities exist and
what can be done about it, realize that the last substantial OpenVMS
security work was done circa V6.0, and there was some no-execute work
implemented more recently. Mitigations such as ASLR, jails, better
coding practices and better security-related routines and tools, etc.,
are all missing.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@info-vax.com] On Behalf Of

> Stephen Hoffman via Info-vax
> Sent: 06-Mar-16 10:21 AM
> To: info...@info-vax.com
> Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>

> Subject: Re: [New Info-vax] VMS SSH2 experts, journaymen, hackers,
> and just about anyone else
>

> On 2016-03-06 01:52:46 +0000, Kerry Main said:
>
> > While I don't think anyone here thinks there is not a lot of work to do
> > to make up for many years of HP mismanagement of OpenVMS, let's
> not
> > forget the state of the security patches on ALL platforms.
>
> Yes. But then for those other platforms, I don't have to periodically
> log into a web site to look for updates, don't have to navigate through
> the ever-changing patch web page with the random-patch-ordering
> display, find and select and download and unpack and read the master
> listing, uncheck what's already installed from the dependency
> processing, then find and select and download and FTP the patches
> around to the target servers, unzip the patches, confirm the dependency
> order and prerequisites, and install each of the patches manually.
>
> OpenVMS has rather fewer of the current patches too, delayed
> availability for those patches that are available, and a baroque and
> entirely manual patch installation sequence.
>
> > Of course, Operations groups could always adopt the strategy
> thatmany
> > Windows Operations server groups have adopted.
> > It's a strategy often called "Patch-n-Pray".
> >
> > :-)
>
> Ayup. But then Microsoft Windows has tools to automate notification
> and remote installation of patches, among other useful features.
> Management and automation features lacking on OpenVMS.
>

Regardless of the level of automation of the patches, it still comes down
to the volume of patches on commodity systems is no longer manageable
and still re-test important applications as best practices dictate.

What many forget is that it is the volume of security patches (not bug fixes)
is what impacts Operations and QA groups, because for security patches,
they need to review each patch and then retest important applications
before rolling out the selected patches. Once this is done, then they can
use tools to automate the deployment and reboot scheduling.

One Lottery OPS group flat out told me they could not keep up with the
volume of Wintel / Linux security patches, so they just roll them out and
hope nothing breaks in Production. "Patch-n-Pray".

I suspect most Windows/Linux OPS groups have adopted the same strategy.

> To HPE's credit, OpenVMS hasn't had a regression with an UPDATE patch
> in a few years, which is a good start toward the ability to install
> patches on many servers with fewer local tests.
>
> Toward gaining the trust of system managers to more rapidly apply the
> patches, for that matter.
>

Agree trust is big component, but best practice states "trust, but verify"
before applying security patches to important production systems.

[snip..]

[johnwa...@yahoo.co.uk]

Fair comment. No one sensible would want to trust Windows Update
without an additional layer of site-specific testing.

They would not trust it to do the right thing (e.g. reliably
deliver relevant patches in a timely manner), nor to not do the
wrong thing (e.g. not to deliver inadequately tested patches
which fail in inconvenient ways, e.g. an infinite reboot loop,
or which attempt to upgrade to Windows 10 without customer
permission, get part way through the upgrade, fail, and leave
the hard drive in an inconsistent semi-usable state).

That's not just my experience, things like that have been reported
by many others, frequently without any actual resolution to
whatever the underlying problems might be.

The "unsolicited Windows 10 upgrade" isn't even considered a
problem by MS, it's apparently considered a feature. Stuff like
this appears to be upsetting quite a few normally loyal members
of the Windows community.

I've no recollection of ever seeing a Suse patch do a really
wrong thing (back to V8 or so), though back in the days of 11
(or maybe 12), specific hardware support used to break
occasionally before being fixed again, and VNC config settings
used to break occasionally. Others may have different experience.

Obviously VMS needs to improve a lot. Windows Update is widely
used but is not a good example of "industry best practice"
despite it being used by lots of people.

Fortunately (?) there's less to update in VMS than there is in
Windows, which (in the short term) *may* help reduce the
magnitude of the problem.

What do IBM do? What do Sun do? What do Tandem do?

Have a lot of fun.

[Stephen Hoffman]

On 2016-03-06 18:30:44 +0000, johnwa...@yahoo.co.uk said:

> Obviously VMS needs to improve a lot. Windows Update is widely used but
> is not a good example of "industry best practice" despite it being used
> by lots of people.
>
> Fortunately (?) there's less to update in VMS than there is in Windows,
> which (in the short term) *may* help reduce the magnitude of the
> problem.

Microsoft has had a supremely effective managerial and business model
and for many years. They've become less central to the client, server
and hosted markets in recent years, with the growth in mobile.

Microsoft controls a sizable chunk of the legacy desktop market and has
a massive installed base.

An installed base that Microsoft can't upgrade.

http://www.extremetech.com/computing/224020-windows-10-adoption-is-slowing-despite-microsofts-best-efforts


Microsoft — like VSI — increasingly need their customers to upgrade,
too. To migrate forward, to newer versions and newer environments.
Long Term Support (LTS) releases only go so far at controlling overhead
for the vendor and for third-party providers, too.

But more to the point of this particular discussion, Microsoft Windows
is seldom considered to be a source of design inspiration. If your
operating system software product can't best Windows in more than a few
product dimensions, then you're at a competitive disadvantage.

> What do IBM do? What do Sun do? What do Tandem do?

What would VSI do?

What can VSI do — within their budget and their staffing — that
provides advantages to their customers over other vendors?

Through ~2020, not really all that much. Unfortunately. If the VSI
investment funding holds out and the revenues stabilize at or
preferably well above costs, they will slow the pace of outbound ports.
But that's not good enough. They need to get OpenVMS where it'll
start to attract new applications and new users. Growth. If they
don't, then they may well have a tidy business for some years, but
OpenVMS folks will be porting out.

[Jan-Erik Soderholm]

How many are these that are upset rellative the total number of
Windows systems out there? Is it 1:1000? Or 1:10000? 1:100000?

Just becuse you can find x number of reports "on the net" from
upset users doesn't say that it wasn't successfull in large.

It's hard to use the largest client/desktop environment when
comparing routines and featurs with one of the smallest
server environments available.

For what it matters, I automaticly updated both my own and my
wifes Win7 laptops to Win10 and it has been a huge seccess.

>
> I've no recollection of ever seeing a Suse patch do a really
> wrong thing (back to V8 or so), though back in the days of 11
> (or maybe 12), specific hardware support used to break
> occasionally before being fixed again, and VNC config settings
> used to break occasionally. Others may have different experience.
>
> Obviously VMS needs to improve a lot. Windows Update is widely
> used but is not a good example of "industry best practice"
> despite it being used by lots of people.

It is a very well example of an toolset for the environmentthat it
was designed to support, Windows. Of course it would not be a
working solution for systems like OpenVMS (with automatic
downloads and updates), but I see no reason why one could not
have a tool to download selected patches directly to OpenVMS.

>
> Fortunately (?) there's less to update in VMS than there is in
> Windows, which (in the short term) *may* help reduce the
> magnitude of the problem.

It is not the volume that is the main difference, it is the
way that Windows and VMS systems are used and managed.

[Craig A. Berry]

Windows has facilities that give the administrator complete control over
what systems get what patches and when they get them, either on a
pre-set schedule or when explicitly pushed. The notion that one must
enable automatic updates with no control over what gets updated or that
one must patch-n-pray by accepting all changes when they are first
released without an opportunity to deploy them after testing reflect a
poor understanding of what actually happens in the real world.

[Jan-Erik Soderholm]

Den 2016-03-06 kl. 23:05, skrev Craig A. Berry:
> On 3/6/16 3:30 PM, Jan-Erik Soderholm wrote:
>> Den 2016-03-06 kl. 19:30, skrev johnwa...@yahoo.co.uk:
>
>>> Obviously VMS needs to improve a lot. Windows Update is widely
>>> used but is not a good example of "industry best practice"
>>> despite it being used by lots of people.
>>
>> It is a very well example of an toolset for the environmentthat it
>> was designed to support, Windows. Of course it would not be a
>> working solution for systems like OpenVMS (with automatic
>> downloads and updates), but I see no reason why one could not
>> have a tool to download selected patches directly to OpenVMS.
>

> Windows has facilities that give the administrator...

Most Windows systems doesn't have any "administrator".
They only have one "user" that knows nothing about computers.
That is the real world that Microsoft is facing.

> complete control over
> what systems get what patches and when they get them, either on a
> pre-set schedule or when explicitly pushed.

Yes, there are a lot of routines that are used within diffrent
organisations to manage their Windows boxes. But that is a
minority of the Windows systems out there. And its is not what
one talks about when talkning about automatic Windows Update
updates to the masses.

> The notion that one must

> enable automatic updates with no control over what gets updated...

99% of the Windows users doesn't have any other option.

> or that
> one must patch-n-pray by accepting all changes when they are first
> released without an opportunity to deploy them after testing reflect a
> poor understanding of what actually happens in the real world.

That *is* what happens in the real world, outside of larger organisations.
How Windows systems are managed within larger organisations is a whole
other question...




>

[Craig A. Berry]

On 3/6/16 4:29 PM, Jan-Erik Soderholm wrote:

> How Windows systems are managed within larger organisations is a whole
> other question...

No, the whole discussion has been about the deployment of patches to
servers in an enterprise environment and the lack of facilities for
doing that on VMS as smoothly as it's done on other systems.

[Jan-Erik Soderholm]

*That* I have no problem with. There are tools available on
"other systems" that are missing from OpenVMS, yes. :-)

Enterprices usualy don't let their PC clients get automatic
updates stright from Microsoft.

But then someone mentioned the automatic updates that are made
through Windows Update as some general example of "everything
bad comes from Redmond". And that is a whole different question.
Windows Update is fine for the environments where it (mainly) runs.

I was just commenting to the bashing of Windows Update as beeing
someting (generally) bad. I say it is a must for most Windows
systems out there.

[johnwa...@yahoo.co.uk]

Windows Update on its own, without whatever Systems Management
Server is now called (and/or some 3rd party equivalent) is indeed
not appropriate for various hopefully obvious reasons for a
serious IT organisation.

Windows Update, if it worked reliably, might be good for home
users and some SMEs. It's not that reliable, but there's no other
real choice (for most Windows users) so maybe it's still a must.

I'm not quite sure how it came into a discussion on where VMS's
update distribution mechanism needs to be in a couple of years.
Windows Update (with or without SMS) addresses a different market
and imo its "design" has little to offer to an enterprise-focused
low volume server market where trustworthy is likely to be at
least as important as simple+shiny in the foreseeable future.
It doesn't hurt to look at what others are doing and then learn
from and improve on it where appropriate.

[Jan-Erik Soderholm]

> Windows Update (with or without SMS) addresses a different market...

Exatly! It is mostly irrelevant to VMS. That is why I commented
on it in the first place. It was not me that mentioned Windows
Update here...

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@info-vax.com] On Behalf Of

> Jan-Erik Soderholm via Info-vax
> Sent: 06-Mar-16 4:31 PM
> To: info...@info-vax.com
> Cc: Jan-Erik Soderholm <jan-erik....@telia.com>

> Subject: Re: [New Info-vax] VMS SSH2 experts, journaymen, hackers,
> and just about anyone else
>

[snip..]

>
> How many are these that are upset rellative the total number of
> Windows systems out there? Is it 1:1000? Or 1:10000? 1:100000?
>
> Just becuse you can find x number of reports "on the net" from
> upset users doesn't say that it wasn't successfull in large.
>
> It's hard to use the largest client/desktop environment when
> comparing routines and featurs with one of the smallest
> server environments available.
>
> For what it matters, I automaticly updated both my own and my
> wifes Win7 laptops to Win10 and it has been a huge seccess.
>

Updating clients / desktops is in a different world from updating server
environments. While I also upgraded from Win8.1 to Win10 with few
issues (intermittent disappearing USB3 drives is still a pain), I would not
do an auto-upgrade on ANY server platform without reading release
notes and testing critical applications. [for the record, I also like Win 10
as a desktop)

In addition, while I had no issue with upgrading my desktop from Win
8.1 to Win 10.0, in a prod server environment, I would likely wait for the
SP1 equivalent version to be available before even beginning testing. In
addition, the normal upgrade sequence is to upgrade DEV, then QA/Test,
then Prod.

Here is counter argument for constant patching:
http://www.eweek.com/c/a/Security/More-Patches-Arent-the-Answer
"Commercial PC software has been around for more than 20 years and
should be past any special exemptions it may have deserved. Instead,
much of the activity in this area is aimed at actually increasing the
protections that software vendors have against liability due to poor
coding. Unfortunately, if this progress continues, we'll be patching for
breakfast, lunch and dinner. Are you sick and tired of constant
patching?"

(btw - this article was written in 2002)

Well, 14 years later and nothing has changed.

What's wrong with this picture?

[snip...]

[David Froble]

Ok, here is how it should work. I doubt others will agree. NIH!

VSI maintains a "library" of all patches. Included with each one is a
description. Perhaps the contents of the library are automatically loaded onto
customer's systems. Don't care how this works.

There is also a utility that tells the system manager what is in the library,
and which ones are installed. It is up to the system manager to evaluate each
patch, and decide whether to install that patch, and, perhaps to de-install
other patches. The utility is user friendly, use check boxes or such to dictate
actions. I guess there can be a "do all" check box for those who don't want to
read about each patch.

Now, what would be the benefits?

1) Site specific decisions on what to install
2) Easy to read list of all patches, no having to search
3) Easy installation, customizable for each site

I'd assume that the utility could be used for a "farm" of VMS systems, making
each the same, or each unique.

This ain't rocket science. It's doable ....

[Stephen Hoffman]

On 2016-03-07 02:12:02 +0000, Kerry Main said:

> Updating clients / desktops is in a different world from updating
> server environments.

Sure, clients and desktops are different, if you're still into
operating servers as pets and not as herds. But if you're running
herds of servers, the differences here are minor at best. Well,
servers often have better network connections. There's that.

> While I also upgraded from Win8.1 to Win10 with few issues
> (intermittent disappearing USB3 drives is still a pain), I would not do
> an auto-upgrade on ANY server platform without reading release notes
> and testing critical applications.

Same reading for herds of clients, too. Same testing of the core
applications and images, too. But unlike operating herds of servers,
losing a few clients probably more of a problem these days, at least
until you can swap out the clients.

Intermittent USB3? That's hilarious. The folks that once posted up
all those dialog boxes — hey, a new USB device was found (duh, I'm the
one that plugged it in); hey, it needs a driver (um, okay, why are you
bothering me about implementation details?); hey, I found a driver
(good on you Windows, but why are you bothering me?); hey, the driver
connected (um, so that's unexpected?); hey, it works! (um, that's what
I paid you to do) — are still at it? Greatly prefer the
just-go-do-it-and-tell-me-if-it-fails approach.

[John Reagan]

On Sunday, March 6, 2016 at 11:07:07 PM UTC-5, David Froble wrote:

Doable, yes. Testable? Depends on the granularity. The permutations that HPE/VSI would have to test would get out of hand quickly. That is one of the reasons why Windows 10 has become more automatic, to reduce their testing matrix and hopefully increase stability.

We don't have the technology to let you pick 3 of 5 fixes to the Fortran RTL now and let you come back in a week and decide you want another one.

I agree with some network-based update manager like you describe. Of course, you have make sure you have proper security and encryption on top of it.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@info-vax.com] On Behalf Of

> Stephen Hoffman via Info-vax
> Sent: 07-Mar-16 7:02 AM
> To: info...@info-vax.com
> Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>

> Subject: Re: [New Info-vax] VMS SSH2 experts, journaymen, hackers,
> and just about anyone else
>

> On 2016-03-07 02:12:02 +0000, Kerry Main said:
>
> > Updating clients / desktops is in a different world from updating
> > server environments.
>
> Sure, clients and desktops are different, if you're still into
> operating servers as pets and not as herds. But if you're running
> herds of servers, the differences here are minor at best. Well,
> servers often have better network connections. There's that.
>

Pets and herds is a nice analogy for large scale standardization for
desktops, but the real world server environment is a lot of pets with
vastly different requirements, platforms and standards that are
owned by different BU's with different priorities and views of the
future.

Throw in server OS religion and you have lots of pets to take care of.

This is the main driver for private clouds today as companies try and
get all these "pets" under control.

That’s real world.

The Googles and Facebooks of the world with their server herds are
vastly different than the world of normal corporations and SMB's.

> > While I also upgraded from Win8.1 to Win10 with few issues
> > (intermittent disappearing USB3 drives is still a pain), I would not do
> > an auto-upgrade on ANY server platform without reading release notes
> > and testing critical applications.
>
> Same reading for herds of clients, too. Same testing of the core
> applications and images, too. But unlike operating herds of servers,
> losing a few clients probably more of a problem these days, at least
> until you can swap out the clients.
>
> Intermittent USB3? That's hilarious. The folks that once posted up
> all those dialog boxes — hey, a new USB device was found (duh, I'm the
> one that plugged it in); hey, it needs a driver (um, okay, why are you
> bothering me about implementation details?); hey, I found a driver
> (good on you Windows, but why are you bothering me?); hey, the driver
> connected (um, so that's unexpected?); hey, it works! (um, that's what
> I paid you to do) — are still at it? Greatly prefer the
> just-go-do-it-and-tell-me-if-it-fails approach.
>

Not even sure what this means ..

:-)

[Stephen Hoffman]

On 2016-03-07 13:12:33 +0000, John Reagan said:

> Doable, yes. Testable? Depends on the granularity. The permutations
> that HPE/VSI would have to test would get out of hand quickly. That is
> one of the reasons why Windows 10 has become more automatic, to reduce
> their testing matrix and hopefully increase stability.
>
> We don't have the technology to let you pick 3 of 5 fixes to the
> Fortran RTL now and let you come back in a week and decide you want
> another one.
>
> I agree with some network-based update manager like you describe. Of
> course, you have make sure you have proper security and encryption on
> top of it.

Maybe rolling out point fixes isn't where VSI wants to be, anyway.

Offer a high-priority path — security patches, malware signatures,
certificate revocations, the occasional last-minute timezone changes,
tested and designed for rapid updates with minimal or no consequences
and quite possibly fully automatic installation by default — and a
maintenance release path that is what a dash release was intended to be
— a maintenance update.

Offering the current smorgasbord of patches is just asking for trouble.
For VSI, and for end-users. This plethora of patches all inherently
ties back to a lack of trust around the stability of the patches in
general, too. Roll'm up, test them, and ship a maintenance update.
Current version gets all fixes, and the previous version and any LTS
version that hasn't aged out gets the high-priority fixes. New
features go into new releases.

HPE went to UPDATE patches because of the testing and due to the very
long OpenVMS release cycles, even for the maintenance releases. Then
HP started shipping enhancements and new features in UPDATE kits Yes,
really. HP then compounded the difficulty and the confusion here by
never providing a mechanism to detect the presence of UPDATE patches,
and then buried the marketing opportunities for the enhancements by
burying the lede in the release notes for the patches. Release which
are inexplicably only available to folks with patch access. But I
digress.

We are not in the same era that HP was in, and are already ~forty years
past the era when VAX-11/VMS was designed and launched. Beyond
stability, very little here is sacrosanct. Not even the APIs, IMNSHO.

Figure out what y'all are going to do here, post a whitepaper or
whatever y'all want to call it, go do it, and move on.

As for staging and managing patches, have a look at what OS X Server
offers with its Software Update Service. It's right in your
wheelhouse.

[Stephen Hoffman]

On 2016-03-07 13:36:16 +0000, Kerry Main said:

> Pets and herds is a nice analogy for large scale standardization for
> desktops, but the real world server environment is a lot of pets with
> vastly different requirements, platforms and standards that are owned
> by different BU's with different priorities and views of the future.

Ayup. Which means you can have more than one herd, Quite possible
with fewer hardware and platform and tool variations, and fewer data
centers.

> Throw in server OS religion and you have lots of pets to take care of.

Vanishingly few being OpenVMS, of course.

> This is the main driver for private clouds today as companies try and
> get all these "pets" under control.
>
>
>
> That’s real world.

A world which is going to be front and center with OpenVMS deployments
on x86, too.

> The Googles and Facebooks of the world with their server herds are
> vastly different than the world of normal corporations and SMB's.

Donno. I'm doing herd-like deployments with OpenVMS. It's a pain
with the way OpenVMS works now, though.

You really should be looking at this for Stark, though. You're going
to need this, particularly as your compute requirements grow and you
establish geographically distributed DCs.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@info-vax.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: 07-Mar-16 9:16 AM
> To: info...@info-vax.com
> Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>
> Subject: Re: [New Info-vax] VMS SSH2 experts, journaymen, hackers,
> and just about anyone else
>

Absolutely. However, standardization, virtualization, workload and
provisioning automation, proactive monitoring/management etc. were
best IT practices decades ago and are the same best practices critical to
meeting business requirements today.

However, in our case, we are not going to worry much about the server
hardware because imho, IA64 I4's are excellent servers. The App/DB/OS
and network optimizations and creativity is where the biggest gains are
going to come from.

Also, proprietary will be seen as a good thing as it provides differentiation
from the competition.