Pardon me if this looks like a dumb question...

The company I work for runs a business that require PCI certification.
Several security measures must be implemented to obtain this, among
them password strength :
- minimum length and maximum life time (VMS standard feature)
- minimum complexity (not VMS standard but easily implemented)

We also needed to disable Telnet and FTP, for obvious reasons, and now
most people use SSH to login. Some, not all, use a private/public key
pair associated with a passphrase to achieve this.

The question therefore is, is there any way, on an OpenVMS system, to
enforce the strength of those passphrases, system-wide, in a similar
way
to the classical password ? I recently discovered that one
of my ex-colleagues, now retired, used a null passphrase to access his
full privileged accounts on production systems. I do not feel very
comfortable with that, and I wonder what would be the reaction of an
auditor seeing a sysadmin guy logging in by just typing <return> at the
passphrase prompt...

--
Marc Van Dyck

On 8/1/2022 11:26 AM, Marc Van Dyck wrote:
> Pardon me if this looks like a dumb question...
>
> The company I work for runs a business that require PCI certification.
> Several security measures must be implemented to obtain this, among
> them password strength :
> - minimum length and maximum life time (VMS standard feature)
> - minimum complexity (not VMS standard but easily implemented)

Note that password maximum life time aka required frequently password
change is actually an anti-pattern today.

> We also needed to disable Telnet and FTP, for obvious reasons, and now
> most people use SSH to login. Some, not all, use a private/public key
> pair associated with a passphrase to achieve this.
>
> The question therefore is, is there any way, on an OpenVMS system, to
> enforce the strength of those passphrases, system-wide, in a similar way
> to the classical password ? I recently discovered that one
> of my ex-colleagues, now retired, used a null passphrase to access his
> full privileged accounts on production systems. I do not feel very
> comfortable with that, and I wonder what would be the reaction of an
> auditor seeing a sysadmin guy logging in by just typing <return> at the
> passphrase prompt...

For SSH client on VMS?

Arne

Den 2022-08-01 kl. 17:26, skrev Marc Van Dyck:
> Pardon me if this looks like a dumb question...
>
> The company I work for runs a business that require PCI certification.
> Several security measures must be implemented to obtain this, among
> them password strength :
> - minimum length and maximum life time (VMS standard feature)
> - minimum complexity (not VMS standard but easily implemented)
>
> We also needed to disable Telnet and FTP, for obvious reasons, and now
> most people use SSH to login. Some, not all, use a private/public key
> pair associated with a passphrase to achieve this.
>
> The question therefore is, is there any way, on an OpenVMS system, to
> enforce the strength of those passphrases, system-wide, in a similar way
> to the classical password ? I recently discovered that one
> of my ex-colleagues, now retired, used a null passphrase to access his
> full privileged accounts on production systems. I do not feel very
> comfortable with that, and I wonder what would be the reaction of an
> auditor seeing a sysadmin guy logging in by just typing <return> at the
> passphrase prompt...
>

We are in the process of implementing login authorization using
the central corporate AD system using LDAP/ACME. Apart from some
technical issues, this gives a password handling that follows the
corporate standards, no matter what VMS thinks about it.

I have also thought about bringing up the question about replacing
telnet with ssh when the summer vacations has passed by...

On 8/1/22 10:26 AM, Marc Van Dyck wrote:
> Pardon me if this looks like a dumb question...
>
> The company I work for runs a business that require PCI certification.
> Several security measures must be implemented to obtain this, among
> them password strength :
> - minimum length and maximum life time (VMS standard feature)
> - minimum complexity (not VMS standard but easily implemented)
>
> We also needed to disable Telnet and FTP, for obvious reasons, and now
> most people use SSH to login. Some, not all, use a private/public key
> pair associated with a passphrase to achieve this.
>
> The question therefore is, is there any way, on an OpenVMS system, to
> enforce the strength of those passphrases, system-wide, in a similar way
> to the classical password ? I recently discovered that one
> of my ex-colleagues, now retired, used a null passphrase to access his
> full privileged accounts on production systems. I do not feel very
> comfortable with that, and I wonder what would be the reaction of an
> auditor seeing a sysadmin guy logging in by just typing <return> at the
> passphrase prompt...

I'm pretty sure you can only tell whether a key pair has a passphrase
associated with it by inspecting the private portion or running it
through ssh-keygen to modify the password -- if it says "Enter new
passphrase" then it didn't have one before. I'm assuming VMS is the
server side here and would only have the public key, so no way to do the
enforcement you're looking for.

On 2022-08-01 15:26:55 +0000, Marc Van Dyck said:

> Pardon me if this looks like a dumb question...
>
> The company I work for runs a business that require PCI certification.
> Several security measures must be implemented to obtain this, among
> them password strength :
> - minimum length and maximum life time (VMS standard feature)
> - minimum complexity (not VMS standard but easily implemented)

Other than a minimum length, the rest of those are considered "SHOULD
NOT" practices by US NIST.

See 5.1.1.2 as described here: https://pages.nist.gov/800-63-3/sp800-63b.html

Password length checks and compromised-password checks are what US NIST
recommends.

Conflicting security requirements are always such fun.

> We also needed to disable Telnet and FTP, for obvious reasons, and now
> most people use SSH to login. Some, not all, use a private/public key
> pair associated with a passphrase to achieve this.
>
> The question therefore is, is there any way, on an OpenVMS system, to
> enforce the strength of those passphrases, system-wide, in a similar
> way to the classical password ? I recently discovered that one of my
> ex-colleagues, now retired, used a null passphrase to access his full
> privileged accounts on production systems. I do not feel very
> comfortable with that, and I wonder what would be the reaction of an
> auditor seeing a sysadmin guy logging in by just typing <return> at the
> passphrase prompt...

Check with VSI, but AFAIK there is no integration from ssh passphrases
into the OpenVMS password filter API. Near as I can tell from the
OpenSSH documentation, there's also no setting to enforce minimal
passphrase length.

You're probably headed for two-factor authentication here, particularly
if you encounter an auditor's (and intractable) requirement for
passphrase length. While OpenVMS isn't very good at two-factor
authentication itself and app APIs are definitely lacking here, there
are two-factor add-ons for LOGINOUT. Binding to a directory (LDAP, what
OpenVMS calls "external authentication") is a common approach for all
this, and that also deals with employee turnover, and can (usually)
deal with two-factor authentication requirements on behalf of the bound
systems. Though that won't help with passphrase length requirements.

--
Pure Personal Opinion | HoffmanLabs LLC

On 8/1/2022 12:19 PM, Craig A. Berry wrote:
> On 8/1/22 10:26 AM, Marc Van Dyck wrote:
>> We also needed to disable Telnet and FTP, for obvious reasons, and now
>> most people use SSH to login. Some, not all, use a private/public key
>> pair associated with a passphrase to achieve this.
>>
>> The question therefore is, is there any way, on an OpenVMS system, to
>> enforce the strength of those passphrases, system-wide, in a similar way
>> to the classical password ? I recently discovered that one
>> of my ex-colleagues, now retired, used a null passphrase to access his
>> full privileged accounts on production systems. I do not feel very
>> comfortable with that, and I wonder what would be the reaction of an
>> auditor seeing a sysadmin guy logging in by just typing <return> at the
>> passphrase prompt...
>
> I'm pretty sure you can only tell whether a key pair has a passphrase
> associated with it by inspecting the private portion or running it
> through ssh-keygen to modify the password -- if it says "Enter new
> passphrase" then it didn't have one before.  I'm assuming VMS is the
> server side here and would only have the public key, so no way to do the
> enforcement you're looking for.

I am not familiar with SSH key storage in particular.

But usually the passphrase is associated with the keystore
and not the private key.

Arne

On 8/1/22 11:38 AM, Arne Vajhøj wrote:
> On 8/1/2022 12:19 PM, Craig A. Berry wrote:
>> On 8/1/22 10:26 AM, Marc Van Dyck wrote:
>>> We also needed to disable Telnet and FTP, for obvious reasons, and now
>>> most people use SSH to login. Some, not all, use a private/public key
>>> pair associated with a passphrase to achieve this.
>>>
>>> The question therefore is, is there any way, on an OpenVMS system, to
>>> enforce the strength of those passphrases, system-wide, in a similar way
>>> to the classical password ? I recently discovered that one
>>> of my ex-colleagues, now retired, used a null passphrase to access his
>>> full privileged accounts on production systems. I do not feel very
>>> comfortable with that, and I wonder what would be the reaction of an
>>> auditor seeing a sysadmin guy logging in by just typing <return> at the
>>> passphrase prompt...
>>
>> I'm pretty sure you can only tell whether a key pair has a passphrase
>> associated with it by inspecting the private portion or running it
>> through ssh-keygen to modify the password -- if it says "Enter new
>> passphrase" then it didn't have one before.  I'm assuming VMS is the
>> server side here and would only have the public key, so no way to do the
>> enforcement you're looking for.
>
> I am not familiar with SSH key storage in particular.
>
> But usually the passphrase is associated with the keystore
> and not the private key.

I've only ever seen the term "keystore" used in the context of Java.
With ssh, all the implementations I've seen store everything as plain
text files (base64-encoded) in the .ssh or other directory. There is no
passphrase associated with the storage mechanism, only with each private
key found there.

There are various agents on various systems (e.g. PuTTY's Pageant or the
macOS keychain) that can prompt for the passphrases at login or
configuration time or on first use so that you don't have type them
every time, so in normal usage it always appears that there is no
passphrase at connection time even if there is one.

On 8/1/2022 1:06 PM, Craig A. Berry wrote:
> On 8/1/22 11:38 AM, Arne Vajhøj wrote:
>> On 8/1/2022 12:19 PM, Craig A. Berry wrote:
>>> On 8/1/22 10:26 AM, Marc Van Dyck wrote:
>>>> We also needed to disable Telnet and FTP, for obvious reasons, and now
>>>> most people use SSH to login. Some, not all, use a private/public key
>>>> pair associated with a passphrase to achieve this.
>>>>
>>>> The question therefore is, is there any way, on an OpenVMS system, to
>>>> enforce the strength of those passphrases, system-wide, in a similar
>>>> way
>>>> to the classical password ? I recently discovered that one
>>>> of my ex-colleagues, now retired, used a null passphrase to access his
>>>> full privileged accounts on production systems. I do not feel very
>>>> comfortable with that, and I wonder what would be the reaction of an
>>>> auditor seeing a sysadmin guy logging in by just typing <return> at the
>>>> passphrase prompt...
>>>
>>> I'm pretty sure you can only tell whether a key pair has a passphrase
>>> associated with it by inspecting the private portion or running it
>>> through ssh-keygen to modify the password -- if it says "Enter new
>>> passphrase" then it didn't have one before.  I'm assuming VMS is the
>>> server side here and would only have the public key, so no way to do the
>>> enforcement you're looking for.
>>
>> I am not familiar with SSH key storage in particular.
>>
>> But usually the passphrase is associated with the keystore
>> and not the private key.
>
> I've only ever seen the term "keystore" used in the context of Java.
> With ssh, all the implementations I've seen store everything as plain
> text files (base64-encoded) in the .ssh or other directory.  There is no
> passphrase associated with the storage mechanism, only with each private
> key found there.

JKS is one such keystore.

But I believe PFX/PKCS#12 is similar even though it is called
an archive file and not a keystore.

Arne

On 2022-08-01 17:06:15 +0000, Craig A. Berry said:

> On 8/1/22 11:38 AM, Arne Vajhøj wrote:
>>
>> I am not familiar with SSH key storage in particular.
>>
>> But usually the passphrase is associated with the keystore and not the
>> private key.
>
> I've only ever seen the term "keystore" used in the context of Java.
> With ssh, all the implementations I've seen store everything as plain
> text files (base64-encoded) in the .ssh or other directory. There is
> no passphrase associated with the storage mechanism, only with each
> private key found there.

In typical configurations, ssh encrypts the private key using the passphrase.

Apple uses the term Keychain, and keybag, and provides
password-encrypted storage for secrets. On OpenVMS, it would remove
password management from DECnet Phase IV and other apps, and would
avoid the scatter-shot storage currently used for ssh private keys and
SSL/TLS private keys, and user password storage, and preferably with
integration with ENCRYPT and its own key storage scheme.

> There are various agents on various systems (e.g. PuTTY's Pageant or
> the macOS keychain) that can prompt for the passphrases at login or
> configuration time or on first use so that you don't have type them
> every time, so in normal usage it always appears that there is no
> passphrase at connection time even if there is one.

Details on using ssh passphrases with Keychain on macOS:
https://rderik.com/blog/understanding-ssh-keys-and-using-keychain-to-manage-passphrase-on-macos/

--
Pure Personal Opinion | HoffmanLabs LLC

On Monday, August 1, 2022 at 3:55:11 PM UTC-4, Arne Vajhøj wrote:
> But I believe PFX/PKCS#12 is similar even though it is called
> an archive file and not a keystore.
>

OpenSSL uses the filesystem-is-a-database approach and stores
certificates and CRLs as text files where the file name is a hash of
the certificate's subject name (or CRL's issuer name). Some versions
of OpenSSL define a lookup type of private key to store those in that
directory as well, but they apparently decided that was a bad idea
and dropped that symbol definition from the header file.

I maintain my list of root CA's by exporting the set Chrome uses as a
PKCS12 archive, convert it to PEM, and breakout the certificates for
inclusion into the ssl1$certs directory. I'm investigating modifying
OpenSSL (1.1.1q) to use a database, if present, instead of the certs
directory. The hack only requires replacing one OpenSSL source file,
plus several bits so support code to create and populate the database.

Stephen Hoffman formulated the question :
>
> Other than a minimum length, the rest of those are considered "SHOULD NOT"
> practices by US NIST.
>
> See 5.1.1.2 as described here: https://pages.nist.gov/800-63-3/sp800-63b.html
>
> Password length checks and compromised-password checks are what US NIST
> recommends.
>
> Conflicting security requirements are always such fun.
>

I knew someone would tell me that. I know. But I don't make the rules.
PCI organization (payment card industry, a.k.a. master card and visa)
does that. May be someday, someone - not me - will enligthen them.

> Check with VSI, but AFAIK there is no integration from ssh passphrases into
> the OpenVMS password filter API. Near as I can tell from the OpenSSH
> documentation, there's also no setting to enforce minimal passphrase length.
>
That's what I expected, but I just wanted to be sure.

> You're probably headed for two-factor authentication here, particularly if
> you encounter an auditor's (and intractable) requirement for passphrase
> length. While OpenVMS isn't very good at two-factor authentication itself and
> app APIs are definitely lacking here, there are two-factor add-ons for
> LOGINOUT. Binding to a directory (LDAP, what OpenVMS calls "external
> authentication") is a common approach for all this, and that also deals with
> employee turnover, and can (usually) deal with two-factor authentication
> requirements on behalf of the bound systems. Though that won't help with
> passphrase length requirements.

We have two-factor authentication, in some form already. Portable PCs
cannot access the production systems directly. People must connect to
a stepstone system (citrix instance) first, which has two-factor
authentication (certificate on card + password), and only then SSH to
the production hosts. But that would not prevent someone to hack
someone
else's key pair...

--
Marc Van Dyck

Arne Vajhøj was thinking very hard :
>
> For SSH client on VMS?
>
> Arne

SSH server on OpenVMS, SSH client anywhere, OpenVMS or Windows.

--
Marc Van Dyck

On 2022-08-02 14:02:11 +0000, Marc Van Dyck said:

> Stephen Hoffman formulated the question :
>>
>> Other than a minimum length, the rest of those are considered "SHOULD
>> NOT" practices by US NIST.
>>
>> See 5.1.1.2 as described here: https://pages.nist.gov/800-63-3/sp800-63b.html
>>
>> Password length checks and compromised-password checks are what US NIST
>> recommends.
>>
>> Conflicting security requirements are always such fun.
>>
>
> I knew someone would tell me that. I know. But I don't make the rules.
> PCI organization (payment card industry, a.k.a. master card and visa)
> does that. May be someday, someone - not me - will enligthen them.

Viewed cynically, PCI isn't intended to prevent breaches. It's intended
to transfer the costs of breach remediation. Viewed less cynically,
there are a whole lot of really bad data security practices around, and
PCI has and will clean up some of those.

By some competitive standards, OpenVMS data security is weak. There are
pieces and parts and hardware which can be assembled, doc is sparse at
best, and mistakes are too easy and the APIs can be subtle and quick to
anger. Which makes OpenVMS apps more difficult to secure.

You're probably headed for binding with a directory here; what OpenVMS
calls external authentication. OpenVMS directory integration is limited
to passwords and account status. OpenVMS external authentication setup
is also fragile and arcane, but can be gotten to work.

--
Pure Personal Opinion | HoffmanLabs LLC

On 2022-08-02 14:03:43 +0000, Marc Van Dyck said:

> SSH server on OpenVMS, SSH client anywhere, OpenVMS or Windows.

ssh server knows and can know absolute zilch about ssh client
passphrase usage or passphrase not-usage.

--
Pure Personal Opinion | HoffmanLabs LLC

On 8/2/22 9:02 AM, Marc Van Dyck wrote:

> We have two-factor authentication, in some form already. Portable PCs
> cannot access the production systems directly. People must connect to
> a stepstone system (citrix instance) first, which has two-factor
> authentication (certificate on card + password), and only then SSH to
> the production hosts. But that would not prevent someone to hack someone
> else's key pair...

If you want to enforce passwords on private keys, you'd have to scan the
relevant locations on your citrix farm, identify and flag those keys
that don't have a password,[1] and have a plan for how to make people
fix them once you find them. As has been said, you can't do it from the
server side nor as part of the SSH connection initiation, but since you
have a controlled client environment like citrix, you could enforce it
on the client side.

[1] Some mechanisms for doing so are listed here:

https://security.stackexchange.com/questions/129724/how-to-check-if-an-ssh-private-key-has-passphrase-or-not

On Mon, 01 Aug 2022 17:26:55 +0200, Marc Van Dyck
<marc.gr.vandyck@invalid.skynet.be> wrote:

>The question therefore is, is there any way, on an OpenVMS system, to
>enforce the strength of those passphrases, system-wide, in a similar
>way
>to the classical password ? I recently discovered that one
>of my ex-colleagues, now retired, used a null passphrase to access his
>full privileged accounts on production systems. I do not feel very
>comfortable with that, and I wonder what would be the reaction of an
>auditor seeing a sysadmin guy logging in by just typing <return> at the
>passphrase prompt...

This seems like it would something that could be solved with a CA
policy. There may be a way to restrict access to ssh-keygen and only
issue the certificates through the CA front end policy.

Mark

On 8/2/2022 10:03 AM, Marc Van Dyck wrote:
> Arne Vajhøj was thinking very hard :
>> For SSH client on VMS?
>
> SSH server on OpenVMS, SSH client anywhere, OpenVMS or Windows.

That means you need to check client keys stored
anywhere.

Arne

On 8/1/2022 10:27 PM, David Jones wrote:
> On Monday, August 1, 2022 at 3:55:11 PM UTC-4, Arne Vajhøj wrote:
>> But I believe PFX/PKCS#12 is similar even though it is called
>> an archive file and not a keystore.
>
> OpenSSL uses the filesystem-is-a-database approach and stores
> certificates and CRLs as text files where the file name is a hash of
> the certificate's subject name (or CRL's issuer name). Some versions
> of OpenSSL define a lookup type of private key to store those in that
> directory as well, but they apparently decided that was a bad idea
> and dropped that symbol definition from the header file.

Yes. PEM files are indeed text files with private keys encrypted.

(OpenSSL can specify an explicit name of the PEM file - like with
SSL_CTX_use_certificate_file)

Arne

On 2022-08-02 22:46:15 +0000, Mark DeArman said:

> ...This seems like it would something that could be solved with a CA
> policy. There may be a way to restrict access to ssh-keygen and only
> issue the certificates through the CA front end policy.

That'll work for certificate control, but it doesn't enforce the
requested passphrase length nor passphrase content filtering
requirements.

--
Pure Personal Opinion | HoffmanLabs LLC

And that implies if you find one with no password, is the same as having
that users' password and thus full access to what that user can do.

Private key storage should be secured and not visible to anyone but the
user [and sysadmins]

On Tue, Aug 2, 2022 at 4:25 PM Arne Vajhøj via Info-vax <info-vax@rbnsn.com>
wrote:

> On 8/2/2022 10:03 AM, Marc Van Dyck wrote:
> > Arne Vajhøj was thinking very hard :
> >> For SSH client on VMS?
> >
> > SSH server on OpenVMS, SSH client anywhere, OpenVMS or Windows.
>
> That means you need to check client keys stored
> anywhere.
>
> Arne
>
>
> _______________________________________________
> Info-vax mailing list
> Info-vax@rbnsn.com
> http://rbnsn.com/mailman/listinfo/info-vax_rbnsn.com
>

--
Dean Woodward =o&o
dean.woodward@gmail.com

DeanW <dean.woodward@gmail.com> writes:

> On Tue, Aug 2, 2022 at 4:25 PM Arne Vajh=C3=B8j via Info-vax <info-vax@rbnsn.com>
> wrote:

>> On 8/2/2022 10:03 AM, Marc Van Dyck wrote:

>>> Arne Vajh=C3=B8j was thinking very hard :

>>>> For SSH client on VMS?

>>> SSH server on OpenVMS, SSH client anywhere, OpenVMS or Windows.

>> That means you need to check client keys stored anywhere.

> And that implies if you find one with no password, is the same as having
> that users' password and thus full access to what that user can do.

I forget how this works on VMS[1] but on TOPS-20[2] a login directory with no
password is locked. It has to have a password assigned in order to log in.

This differs, of course, from the AT&T toy operating system's model.

> Private key storage should be secured and not visible to anyone but the
> user [and sysadmins]

Agreed, but a change to the semantics associated with login would do wonders.

[1] which I only administered in a museum setting for a decade or so
[2] where my experience goes back to the late 1970s in production environments

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

On 2022-08-10 19:54:36 +0000, Rich Alderson said:

> DeanW <dean.woodward@gmail.com> writes:
>
>> And that implies if you find one with no password, is the same as
>> having that users' password and thus full access to what that user can
>> do.
>
> I forget how this works on VMS[1] but on TOPS-20[2] a login directory
> with no password is locked. It has to have a password assigned in
> order to log in.

OpenVMS permits a no-password login, though most installations will
have a minimum password length set, and which would then require a
privileged user set the username to have no password.

But this thread is about (potentially) enforcing rules for the
passphrase used for decrypting and using the ssh private key for some
ssh or sftp activity, and not centrally about the OpenVMS login
passwords.

The ssh daemon managing the arriving login has no information about the
presence or absence of a passphrase on the ssh private key in use.

No password on the ssh private key does mean access is available to
whatever is authorized by the associated public key.

--
Pure Personal Opinion | HoffmanLabs LLC

On Tue, 2 Aug 2022 22:25:04 -0400, Stephen Hoffman
<seaohveh@hoffmanlabs.invalid> wrote:

>On 2022-08-02 22:46:15 +0000, Mark DeArman said:
>
>> ...This seems like it would something that could be solved with a CA
>> policy. There may be a way to restrict access to ssh-keygen and only
>> issue the certificates through the CA front end policy.
>
>That'll work for certificate control, but it doesn't enforce the
>requested passphrase length nor passphrase content filtering
>requirements.

After a little bit of research it does appear this is possible in a
Windows AD environment using the AD CA and appropriate group policy to
enforce Strong Key Protection. I didn't test it out, and I'm still
not clear on wheather if exporting private keys is allowed in the
Machine policy, wheather a key can be exported without a passphrase
from the local keystore. But it does seem that with the correct
syncronization of public keys from the CA, and appropriate security
restrictions on the users ability to upload arbirary public keys to
the SSH server on the OpenVMS side it should be possible to implement.

Mark

On 2022-08-10 21:39:28 +0000, Mark DeArman said:

> On Tue, 2 Aug 2022 22:25:04 -0400, Stephen Hoffman
> <seaohveh@hoffmanlabs.invalid> wrote:
>
>> That'll work for certificate control, but it doesn't enforce the
>> requested passphrase length nor passphrase content filtering
>> requirements.
>
> After a little bit of research it does appear this is possible in a
> Windows AD environment using the AD CA and appropriate group policy to
> enforce Strong Key Protection. I didn't test it out, and I'm still not
> clear on wheather if exporting private keys is allowed in the Machine
> policy, wheather a key can be exported without a passphrase from the
> local keystore. But it does seem that with the correct syncronization
> of public keys from the CA, and appropriate security restrictions on
> the users ability to upload arbirary public keys to the SSH server on
> the OpenVMS side it should be possible to implement.

Binding with LDAP was mentioned up-thread.

OpenVMS LDAP integration is limited.

OpenVMS external authentication doesn't implement this feature; doesn't
enforce a passphrase on a private key.

The SSH public key doesn't "know" from the password set on the private key.

The password on the private key can change entirely independently from
and without changing and without re-uploading the public key.

The OpenVMS SSH client is not—at least not prior to the OpenSSH stuff,
and which is only just becoming available—capable of tying into a
directory service.

If the SSH client can pull the private key from the local
directory—OpenVMS cannot, at least not prior to OpenSSH—then this
passphrase limit can likely be established.

Further limiting this, OpenVMS lacks a per-user and a per-system
trusted and encrypted store for private keys, passwords, and other
secure info, too.

--
Pure Personal Opinion | HoffmanLabs LLC

In article <mailman.0.1660151115.13071.info-vax_rbnsn.com@rbnsn.com>,
DeanW <dean.woodward@gmail.com> writes:

> And that implies if you find one with no password, is the same as having
> that users' password and thus full access to what that user can do.
>
> Private key storage should be secured and not visible to anyone but the
> user [and sysadmins]

And if you break in to that account, such keys are the equivalent of an
obviously named plain-text file in an obvious location with a list of
usernames and passwords for other systems.

People are told not to store passwords in plain text in an obvious place
on their computer, but that is effectively what SSH keys are. Sure,
they are longer, and someone looking over your shoulder won't be able to
remember it, but how many accounts are cracked that way?