Walk into virtually any of the Fortune 500 companies and ask about the Secure Shell Protocol (SSH) key management in their Linux environments, and you'll get a confident answer: There's some kind of central key vault, key rotation process, and audit of orphaned keys. You'd be amazed at the sophistication and automation. Ask the same question about z/OS systems, and a couple of hands will rise. "I don't know" is the usual answer, followed by muttered comments about RACF and "how SSH just works" on USS.

A control gap remains, right on top of our trading, payment, and credit card systems.

Where the Crown Jewels Actually Live

According to IBM, mainframes process more than 90 percent of global credit card transactions and handle a significant share of the world’s financial data, which means auditors regularly find them at the endpoint of an audit trail involving PCI-DSS cardholder data flow or a SOX-relevant financial close. When considering the fact that these are the same systems with some of the most tightly controlled batch processing in the enterprise, we've reached a point of maturity where the systems carrying the most critical assets sometimes carry the least scrutinized access controls.

OpenSSH on z/OS UNIX System Services works the same way as OpenSSH does anywhere else you run it. Once an individual opens an existing USS shell to update their own authorized_keys file, a trusted relationship exists between the remote host and z/OS. This relationship goes unnoticed by any layer of the z/OS security stack. This is done by placing a public key file in authorized_keys: no prompt from RACF, no entry in NetView, no SMF record screaming, "You are creating a new trust relationship." But as it turns out, authorized_keys is simply a flat text file in HFS/zFS, with governance up to you.

The governance of those key files, though, is often much less developed than that of most other means of accessing the system on which they reside.

The Two Controls That Matter, and Why They're Missing

Two specific controls allow the doors to be governed from a keys file.

The first is the from= restriction. Without a from= restriction, any computer can access your SSH account as long as it can open the SSH port. For example, an authorized_keys entry like from=10.x.x.x,10.y.y.y adds another level of security by specifying that the key may only be accessed from known IP addresses, such as known bastion or "jump" hosts. My observation is that it's generally missing from places.

A second method also is available. With ZOS-KEY-RING-LABEL, the user identity bound to your SSH public key also can be bound to a key ring on RACF or ACF2. To auditors who have been trained to understand your enterprise security perimeter, such a keyring holds attributes of other security artifacts, such as AT-TLS certificates and dataset access. It also helps to better bind together the concepts of user identity and other artifacts that require secure access to data. When you add your public keys without the ZOS-KEY-RING-LABEL= flag, the key file just ends up as a blob of text with no governance. When used, the key file's value is bound to a SAF ring, and the ring attestation can be used to revoke keys if necessary. Not many of the key files I checked have this key set.

When both controls are missing from the process, no other individual or department can account for it. It is just "out there" in a place where it can be accessed by an attacker or by auditors first. So, now it depends on you to find it first.

Compliance Exposure Is Real

PCI-DSS 4.0 requires a formal accounting and business rationale for every mechanism that can be used to directly access cardholder data. The SSH key is such a mechanism. An authorized_keys file lacks explicit justification for when the keys may be used, who owns the private keys, or to whom the private keys may be distributed. From an ITGC point of view, SOX asks a question that authorized_keys files can't answer: If an SSH key pair can change financial data, how can we be sure that the private half is under control?

The hard part is that the SSH audit process itself rarely uncovers these problems. You usually find out about them later, during some type of breach investigation or regulatory exam, which is often the worst possible time to be found out.

What a Centralized Validation Pipeline Looks Like

The solution isn't terribly exotic; you just treat authorized keys as part of the system configuration.

Start small, move all authorized_keys files to a single parent location under BASEDIR in USS for each user ID to be controlled by the central sshd daemon, and have this daemon manage the keys for the user in its AuthorizedKeysFile sshd_config. Users will be less likely to "shadow" a centrally managed set of authorized keys by having an equivalent local copy.

Now, get to validating! A script scans all the key entries at the base of your directory tree and checks that the from= clauses include an allowlist (the from= must actually be non-zero) and that the zos-key-ring-label= entries point to real SAF rings. You'll get error records for any key entries that failed validation, and status records for those that passed. Each record is delimited with a pipe and has a guideline value attached to it that references the application inventory.

After this, it surfaces, so validation adds it to your MVS dataset with the correct DCB values. It shows up for NetView to pick up in the autolog, in the same console that monitors your TCP/IP stack, your AT-TLS policy, and even your SSH trust graph. Compliance Check then consumes it and places the results in your enterprise compliance dashboard alongside all the rest of your compliance.

These are all standard components of z/OS: NetView, SAF key rings, the USS shell, MVS datasets, and RACF profiles. With SSH on z/OS, the problem is not another new product or costly modernization; it's making network security a priority for management, as Linux system administrators have for the past decade.

The Pitch to Leadership

If you want this funded, lead with the most obvious point: You've operated a Linux fleet with mature SSH governance, while your mainframe runs the company's financial record with weak SSH governance. As the control matures, the approach gets closer to tool automation that you already have access to, producing an artifact easily shared with auditors.

Rohit Kumar Shaw is an infrastructure engineer specializing in mainframe security and modernization across IBM z/OS environments. His work focuses on AT-TLS policy architecture, SNMP hardening, certificate lifecycle automation, and TCP/IP configuration standardization for regulated financial systems. Shaw has led SNMPv2-to-SNMPv3 migration efforts, AT-TLS policy rollouts, and disaster recovery testing initiatives across large mainframe estates. Working hands-on with z/OS, z/VM, NetView, Omegamon, z/OSMF, and Splunk, he has experience integrating mainframe security telemetry with enterprise SIEM platforms. Additionally, Shaw has authored research papers on cryptographic protocol migration in financial mainframes, including work on SNMPv3 risk reduction and Kerberos versus public key authentication on z/OS.