15 SSH Keys Management Concepts

Secure Shell (SSH) is the protocol used for remote administration and operations of hosts.

• SSH Protocol
  Secure Shell (SSH) is a protocol for logging in to remote hosts securely. In most organizations, users routinely use the SSH software to log in to remote hosts for administrative purposes, running commands, tunneling or copying files.
• SSH Public Key Authentication
  Client authentication can be done by one of the user authentication methods like password authentication, host-based authentication, or the public key authentication. Public key authentication makes use of the public-private key pair to establish the identity of the user connecting to the Secure Shell (SSH) server.
• OpenSSH Implementation of the SSH Protocol
  OpenSSH is an implementation of the Secure Shell (SSH) protocol that is available with Oracle Linux and in general with Linux and Linux-like platforms.
• Challenges with SSH Public Key Authentication
  Following sections describe the challenges faced with SSH Public Key Authentication.
• Controlling Access to SSH Server Centrally with Oracle Key Vault
  Oracle Key Vault can centrally manage the access to Secure Shell (SSH) servers. Centralized access control improves security, enables quicker responses to threats, reduces human error, and simplifies authorization management at scale.
• Managing SSH User Keys with Oracle Key Vault
  Oracle Key Vault can centrally manage the Secure Shell (SSH) key pairs of the SSH client users.
• Oracle Key Vault and SSH Integration
  While Oracle Key Vault can manage the Secure Shell (SSH) keys and can also control the access to SSH servers independently, ideally both the SSH keys and access control of SSH servers should be managed in Oracle Key Vault centrally.
• Supported Platforms for SSH Server and Client Endpoints
  Oracle supports 64-bit platforms for SSH server and client endpoints.

15.1 SSH Protocol

Secure Shell (SSH) is a protocol for logging in to remote hosts securely. In most organizations, users routinely use the SSH software to log in to remote hosts for administrative purposes, running commands, tunneling or copying files.

SSH has replaced the less secure means of remote host access like telnet and less secure means of remote copy like rcp.

SSH protocol has a client-server architecture and consists of three components: the transport layer protocol, the user authentication protocol, and the connection protocol. SSH client users can be users or other processes on the client hosts running the SSH client software. SSH server is a host running the SSH service. The SSH client user initiates the connection with the SSH server. The protocol authenticates the server, establishes an encrypted session and also establishes the authenticity of the client user.

There are many implementations of the SSH protocol. OpenSSH is the open source implementation commonly found on GNU/Linux and UNIX-like operating systems.

Figure 15-1 SSH Protocol

Description of "Figure 15-1 SSH Protocol"

15.2 SSH Public Key Authentication

Client authentication can be done by one of the user authentication methods like password authentication, host-based authentication, or the public key authentication. Public key authentication makes use of the public-private key pair to establish the identity of the user connecting to the Secure Shell (SSH) server.

After the connection has been setup and the encryption and integrity algorithms have been negotiated, the client is authenticated. Public key authentication requires the client user to be configured with an RSA or DSA private and public key pairs. The private key is often called identity keys. The private key is only available to the client user. The public key is shared with the SSH server and is also called the authorized key. The public and private key pair used for the SSH protocol are also called SSH user keys or SSH keys.

The possession of the private key serves as the basis for authentication. For public key authentication, the SSH client software generates a signature using the private key and the server validates the signature using the public key that is associated with the client. The session is created if the signature is valid but the SSH user may be subject to other authentications.

SSH Server

Most common terms that are used with SSH public key authentication include:

The host running the SSH service. A client user can establish a connection to the SSH server and operate as a user of the SSH server host.

SSH Client

The host from which a client user tries to establish the connection with the SSH server.

SSH Client User or SSH User

The principal (user or host) trying to establish a connection with the SSH server.

SSH User Key Pair or SSH Key Pair

Public and private keys of the SSH user used to setup the SSH connection. Only RSA algorithm with key sizes of 2048, 3072, and 4096 bits is supported with Oracle Key Vault 21.7.

SSH User Keys or SSH Keys

Public or private keys of the SSH client user used to setup the SSH connection.

15.3 OpenSSH Implementation of the SSH Protocol

OpenSSH is an implementation of the Secure Shell (SSH) protocol that is available with Oracle Linux and in general with Linux and Linux-like platforms.

Secure Shell Daemon application (sshd) is the OpenSSH service running on SSH servers listening for incoming SSH connection requests. sshd typically runs as the root user. ssh is the OpenSSH client software used to initiate ssh connections. Both the client and server implementations have their own configuration files.

OpenSSH does support public key authentication. It requires the creation of an SSH user key pair. The private key is on the SSH client host and should be secured. The public key is typically added to the authorized_keys file of a host user on the SSH server. The client connects as that host user on the SSH server. Connection as any other host user will be denied unless the client's public key also exists in the authorized_keys file of that host user. The authorized keys file is typically stored as ~/.ssh/authorized_keys file. The public key is in the SSH format in authorized_keys file.

Figure 15-2 Open SSH Setup

Description of "Figure 15-2 Open SSH Setup"

SSH user keys of the SSH client John are created by John or by an administrator. The keys are stored on the SSH client host.John's public key is added to the authorized_keys file of the oracle user on SSH server phoenix. John can now initiate connections as oracle to SSH server phoenix. However, connections as other users like opc on phoenix is denied since John's public key does not exist in the authorized_keys file of opc

Once a client logs in as oracle to phoenix, the client may be able to change the authorized_keys file thereby granting access to other clients, or revoking access from existing clients.

15.4 Challenges with SSH Public Key Authentication

Following sections describe the challenges faced with SSH Public Key Authentication.

• Limited Decentralized Access Control
  The typical public key authentication setup involves the Secure Shell (SSH) server administrator or the SSH server host user adding the public key to the authorized_keys file of the SSH server host user.
• Client Key Management
  Since Secure Shell (SSH) is the tool of choice for accessing remote hosts for operation and administrative purposes, hundreds of users in the organization use SSH.
• Governance
  With SSH keys scattered all over the organization, enforcing uniform enterprise-wide key-management policies and ensuring that key-management best practices are followed becomes difficult.
• No Reporting
  With the distributed access to Secure Shell (SSH) servers, there are no records of who (SSH client user) has access to what (SSH server). There is no enterprise-wide view of the SSH configuration.

15.4.1 Limited Decentralized Access Control

The typical public key authentication setup involves the Secure Shell (SSH) server administrator or the SSH server host user adding the public key to the authorized_keys file of the SSH server host user.

The Secure Shell (SSH) server host user typically has access to its own authorized_keys file. Authorizing a user to login to an SSH server as the SSH server host user is controlled:

1. on the SSH server itself
2. by the SSH server host users or SSH server administrators.

Since the authorization control lies with multiple actors on the SSH servers, there is no consistent and uniform access control.

This problem is further exacerbated because potentially more than one SSH client user can become the SSH server host user. After an SSH client user successfully connects to the SSH server as a SSH server host user, this user can then add public keys of other SSH client users to the authorized_keys file. Such an uncontrolled access grant by the client user operating as SSH server host user essentially bypasses the administrator access authorization which had been intended to grant authorization to only a specific SSH client user.

Additionally, since the authorization control is done on each SSH server, SSH administrators of all these SSH servers are involved which leads to human errors. Three different administrators may have to add the keys to the three different SSH servers to grant a single user access to all three of them. This is not ideal as it introduces a time skew between the time when authorization is done to the time it takes effect on the SSH severs. Furthermore, the decentralized approach is time consuming, requires coordination, and is still error prone.

Figure 15-3 localized-SSH-server-access

Description of "Figure 15-3 localized-SSH-server-access"

Finally, the decentralized nature of the access control architecture has its own share of security risks. The public keys of users that no longer need access to SSH servers must be removed from those SSH servers in a timely manner. However, with decentralized access control the revoke process may take time. Another example is where the SSH server host user grants access to the SSH server out of band. There will be no record of this authorization and no awareness about it, thus increasing the security risks.

In an enterprise setting, multiple administrators grant or revoke access to hundreds of users on thousands of hosts within their domain. At this scale, the decentralized nature of the access control architecture quickly becomes overwhelming, making the system generally more prone to errors and thus more exposed to security risks.

15.4.2 Client Key Management

Since Secure Shell (SSH) is the tool of choice for accessing remote hosts for operation and administrative purposes, hundreds of users in the organization use SSH.

Moreover, for better security, public key authentication is often the preferred method of user authentication. Secure Shell (SSH) is also the tool of choice for server-to-server communication and operations. Hundreds of SSH client users, users, and servers alike, generate their own SSH key pairs. Every SSH client users has to manage the SSH key pairs. Consequently there is so much key sprawl that there are bound to be security weaknesses for any organization-wide deployment.

Every SSH client users has to secure their private keys against compromise. Every SSH client users has to do life cycle management of their SSH keys. SSH key pairs should be rotated at periodic intervals. This is made more complicated because the SSH keys do not come with an expiry date. Every SSH client users needs to ensure that the old key pairs are removed from the SSH servers and SSH client hosts. Enforcing proper key life cycle management is a daunting task when the SSH keys are spread across the enterprise.

Figure 15-4 Limited-SSH-User-Key-Management

Description of "Figure 15-4 Limited-SSH-User-Key-Management"

15.4.3 Governance

With SSH keys scattered all over the organization, enforcing uniform enterprise-wide key-management policies and ensuring that key-management best practices are followed becomes difficult.

Secure Shell (SSH) client users can choose to create keys of different sizes. They can also choose to use different SSH keys to access different SSH servers which in some cases is desirable but not always. It is very difficult to enforce policies granting temporary access to an SSH server or removing access from SSH server machines temporarily, say, if an employee is on vacation. Without centralized control, relying on every SSH client user to enforce governance is error prone and not likely to be feasible at scale.

15.4.4 No Reporting

With the distributed access to Secure Shell (SSH) servers, there are no records of who (SSH client user) has access to what (SSH server). There is no enterprise-wide view of the SSH configuration.

Records are essential when revoking or granting access to SSH client users and auditing the authorizations within the enterprise.

When a distributed approach to SSH key management is used, there is no centralized inventory of the SSH keys and it is difficult to identify whether SSH client users are using redundant keys, multiple keys and if the old keys have been purged. Without the complete visibility of their SSH key inventory, organizations cannot identify and remove weak links, and enforce uniform policies across enterprise.

15.5 Controlling Access to SSH Server Centrally with Oracle Key Vault

Oracle Key Vault can centrally manage the access to Secure Shell (SSH) servers. Centralized access control improves security, enables quicker responses to threats, reduces human error, and simplifies authorization management at scale.

AuthorizedKeysCommand

The configuration file of the OpenSSH daemon sshd_config includes the AuthorizedKeysCommand keyword. This keyword specifies a program that can be used to lookup the public key of the SSH client users. The configuration can further supply this program with the server host user to log in as the SSH server host (or the SSH server host user) and the public key of the SSH client user. This program should emit the authorized public keys in SSH format to standard output. The AuthorizedKeysCommand keyword applies to public key authentication only. Oracle Key Vault ships with a script (okv_ssh_ep_lookup_authorized_keys.sh) that is used to look up the public key in Oracle Key Vault.

SSH Server Host User

This is the Operating System user on the SSH server that the SSH client user uses to log in as the SSH server host.

SSH Server Endpoint

With release 21.7, Oracle Key Vault has a new endpoint type, the SSH Server. The SSH Server endpoint type must be deployed on the SSH Server. SSH Server endpoint software includes the script to lookup the authorized public keys in Oracle Key Vault server. The AuthorizedKeysCommand keyword of the SSH daemon should be configured to invoke this okv_ssh_ep_lookup_authorized_keys.sh script. SSH Server endpoints have the SSH server hostname associated with them. See, Supported Platforms for SSH Server and Client Endpoints for platforms on which you can deploy SSH server endpoint.

SSH Server Wallet

Starting with Oracle Key Vault release 21.7, you can create wallets of different types:

• SSH Server wallet
  • This wallet has the SSH server host user associated with it.
  • It only contains public keys that are authorized to access SSH server as a SSH server host user
• General wallet
  • This type covers all existing wallets
  • It can store TDE keys, secrets, opaque objects, etc

The wallet to be used with SSH Server endpoint should be of type SSH Server. SSH server wallets can contain only public keys and only SSH Server endpoints can be granted access to SSH Server wallets. SSH Server wallets have the SSH server host user associated with them.

SSH Server Mapping File

SSH Server endpoints must set up the SSH server mapping file. This is the configuration file for the okv_ssh_ep_lookup_authorized_keys.sh script. This file contains the mapping of the SSH server host user to its corresponding SSH Server wallet. For each SSH server host user there must be a corresponding SSH wallet set up in Oracle Key Vault. The mapping helps identify whether a given public key in the SSH wallet can be used to authorize the SSH client user to operate as the SSH server host user on SSH server.

# Configuration file for Oracle Key Vault SSH server endpoints
# [ <SSH server host user> ]
# ssh_server_wallet= <SSH wallet>

[ opc ]
ssh_server_wallet=opc_ssh_wallet

[ oracle ]
ssh_server_wallet=oracle_ssh_wallet

SSH Server Endpoint lookup Script

OpenSSH daemon should be run as the root user and SSH endpoint should be deployed as the root user. OpenSSH daemon must be configured to use the AuthorizedKeysCommand keyword to run Oracle Key Vault's okv_ssh_ep_lookup_authorized_keys.sh script. SSH endpoint uses the okv_ssh_ep_lookup_authorized_keys.sh script to setup a secure connection to Oracle Key Vault and validate that the endpoint has access to the public key. For this purpose, OpenSSH daemon is configured to supply the script with the SSH server host user and the public key of the SSH client user. The script uses the SSH server host user to lookup the corresponding SSH wallet mapping stored in SSH server mapping file. Once the SSH wallet has been identified from the mapping file, the script locates it in Oracle Key Vault, opens it, and looks up the public key of the SSH client user. If the public key is accessible to the SSH endpoint, then the SSH client user is authorized to proceed further in the SSH authentication. If the public key presented by the SSH client user is not available in mapped SSH wallet, the SSH client software retries the operation using other public keys, if any, of the SSH user. If no matching public key is found in the SSH wallet, then the connection is terminated.

• Deployment
  Secure Shell (SSH) wallets are the means to manage the authorization of an SSH server host user on SSH server centrally.

15.5.1 Deployment

Secure Shell (SSH) wallets are the means to manage the authorization of an SSH server host user on SSH server centrally.

As long as the public key of SSH client user is in the SSH server wallet of SSH server host user, the client is authorized to access the SSH server as that SSH server host user. An administrator can add or remove the SSH client user's public key to/from the SSH wallet to grant or revoke the SSH client user's access to an SSH server. SSH endpoints identify the SSH server to which the SSH client user is granted access. Since the SSH client users can request access to more than one SSH server host user, an SSH endpoint may require access to more than one SSH wallet.

Figure displays a typical setup where SSH server access is centrally managed in Oracle Key Vault.

The SSH client user, John is trying to login to SSH server, phoenix, as SSH server host user oracle. phoenix is setup with an SSH endpoint and the OpenSSH daemon is setup to use the lookup script (okv_ssh_ep_lookup_authorzied_keys) to check the public keys in Oracle Key Vault. For the OS user oracle on phoenix, the SSH server mapping file maps phoenix OS user oracle to oracle_ssh_wallet in Oracle Key Vault. The SSH wallet (oracle_ssh_wallet) is created in Oracle Key Vault and the SSH endpoint on phoenix is granted read access to oracle_ssh_wallet.

As John tries to log in to phoenix as user oracle, the SSH daemon hands off the public key received from John along with the user oracle, that John is trying to log in as to the lookup script. The lookup script checks the mapping of oracle to an SSH wallet, oracle_ssh_wallet in this case. The lookup script next checks if John's public key is exists in oracle_ssh_wallet. If not, the clients retries with the next public key, if any. If none of the public keys exist in the oracle_ssh_wallet, the client connection is denied, otherwise the SSH user authentication continues further. Whether John can eventually login to phoenix as oracle depends on whether John has the corresponding private key and how the SSH user authentication is setup on phoenix.

Figure 15-5 Centralized-SSH-Server-Access

Description of "Figure 15-5 Centralized-SSH-Server-Access"

You must set up the SSH wallet mapping to the SSH wallets, SSH endpoints, and the SSH server host to manage the authorization of an SSH server as the SSH server host user centrally. Deploy the SSH daemon and SSH endpoints as the root user. Also,update the AuthorizedKeysCommand keyword-argument in sshd_config file to point to the SSH server endpoint lookup script. For each SSH server host user that the SSH client users log in as, there must be a mapping entry in the SSH server mapping file. More than one SSH server host user can share the same SSH wallet. Multiple SSH servers can share the same SSH server wallet to manage the authorization of the corresponding SSH host user on these servers. This implies that the same set of SSH client users are authorized to log in as that host user on any of these SSH servers.

SSH endpoint working in tandem with the OpenSSH daemon verifies if the incoming connection is authorized. The authorization depends on whether the public key presented by the SSH client exists in the SSH wallet. The public key of one or more SSH client users can be added or removed from the SSH wallets of host users of multiple SSH servers centrally in Oracle Key Vault, enabling centralized access of SSH servers.

• Limiting Access Control to Root User
  Even though the authorization of an SSH server is managed centrally, the OpenSSH daemon configuration could still allow SSH client users to log into the SSH server.

15.5.1.1 Limiting Access Control to Root User

Even though the authorization of an SSH server is managed centrally, the OpenSSH daemon configuration could still allow SSH client users to log into the SSH server.

Even though the SSH client user's initial log into an SSH server is controlled centrally in Oracle Key Vault, once the client user is logged in to the SSH server as a host user, this user can then add the public keys of other SSH client users in to the authorized keys file of the host user, thus bypassing the central access control in Oracle Key Vault. For this reason, configure the SSH daemon to disallow the support of the authorized_keys file for regular SSH server host users, thereby enforcing central access management. If SSH is your primary means of SSH server host administration, Oracle recommends you have the authorized_keys file as a fall back option for the root user so you can recover the system in emergencies.

15.6 Managing SSH User Keys with Oracle Key Vault

Oracle Key Vault can centrally manage the Secure Shell (SSH) key pairs of the SSH client users.

Centralized key management not only brings structure and organization to SSH keys in one repository but also improves security by enforcing key governance, key life cycle management and key operations like rotation and revocation.

• Deployment
  Oracle Key Vault integrates with OpenSSH to support the SSH authentication while using the SSH user keys from Oracle Key Vault. Oracle Key Vault provides the PKCS#11 library that the OpenSSH client can leverage to perform SSH authentication steps using the SSH keys stored in Oracle Key Vault.

15.6.1 Deployment

Oracle Key Vault integrates with OpenSSH to support the SSH authentication while using the SSH user keys from Oracle Key Vault. Oracle Key Vault provides the PKCS#11 library that the OpenSSH client can leverage to perform SSH authentication steps using the SSH keys stored in Oracle Key Vault.

Any Oracle Key Vault endpoint can upload the SSH key pairs to Oracle Key Vault. For better management and access control, the SSH keys pairs should be uploaded to wallets. Starting with Oracle Key Vault 21.7, you can also create the SSH keys in Oracle Key Vault. All Oracle Key Vault endpoint types include Oracle Key Vault's PKCS#11 library. As such any Oracle Key Vault endpoint can function as an SSH client user. See, Creating Keys in Managing Oracle Key Vault Virtual Wallets and Security Objects.

The SSH client software that Oracle Key Vault can work with are limited to OpenSSH. Deploy the Oracle Key Vault endpoint on the SSH client. The endpoints PKCS#11 library is loaded by the OpenSSH client program. The PKCS#11 library communicates with Oracle Key Vault and run the SSH operations requested by the SSH client program. The operations are performed using the SSH keys stored in Oracle Key Vault.

With SSH keys in Oracle Key Vault, the SSH client user sets up the connection using the following command:

 ssh -I $OKV_HOME/lib/liborapkcs.so ssh server host user@ssh server

Oracle Key Vault's PKCS#11 library is loaded by the OpenSSH client software using the -I option. Other relevant OpenSSH client software can always be used. Users may also want to make use of the ssh-agent to cache the connection pin. The connection pin is NULL if the endpoint is deployed with auto-login setup (Oracle Linux 8), else the connection pin is the endpoint password used when deploying endpoint (Oracle Linux 9).

It is recommended to keep the extractable attribute of the SSH private key set to FALSE so that the SSH private key never leaves the boundary of the Oracle Key Vault cluster. An endpoint is deployed on the SSH client host. The SSH client endpoint should have the read and modify privileges on this wallet. The manage wallet privilege is required if the SSH client user needs to register SSH keys. The SSH endpoint also includes the PKCS#11 library which is used with the OpenSSH client software when the SSH client user needs to setup a connection to the Oracle Key Vault server.

The Centralized-SSH-Key-Management figure displays the setup for managing SSH keys in Oracle Key Vault. Users should create a general wallet per SSH client user to store and manage the SSH keys.

Figure 15-6 Centralized-SSH-User-Key-Management

Description of "Figure 15-6 Centralized-SSH-User-Key-Management"

With the SSH keys registered or created in Oracle Key Vault, the key management of these keys becomes simpler. Deactivation date can be associated with these keys and the customer is notified of when the keys are expiring and need to be rotated. SSH keys could be rotated periodically. SSH keys could be revoked quickly in case they are compromised. Moreover, when the SSH keys of SSH client users are registered in Oracle Key Vault, it is easy to identify and weed out redundant and unused keys, thus streamlining the organization and management of SSH user keys. Finally, administrators can subject the SSH keys to key life cycle management.

Managing the SSH keys in Oracle Key Vault simplifies their organization, administration and enforces key management best practices.

15.7 Oracle Key Vault and SSH Integration

While Oracle Key Vault can manage the Secure Shell (SSH) keys and can also control the access to SSH servers independently, ideally both the SSH keys and access control of SSH servers should be managed in Oracle Key Vault centrally.

• About Oracle Key Vault and SSH integration
  Oracle Key Vault centrally manages both the Secure Shell (SSH) private keys and SSH public keys. Managing the public keys enables access control of the SSH servers in the enterprise and managing the private keys enforces key governance, key management and organization for SSH keys across the enterprise.
• SSH Admin Managing the SSH User Keys and Access to SSH Servers
  In this model, the Secure Shell (SSH) admin is responsible for the SSH key and access to SSH server management for the entire enterprise. SSH client users in a manner subscribe to the keys managed by the SSH admin.
• SSH Client Users Manage SSH Keys and SSH Admin Manage Access to SSH Servers
  In this model, the Secure Shell (SSH) admin is responsible only for controlling the access to SSH servers for the entire enterprise. The SSH client users own and manage the SSH user keys themselves. The SSH client users own and manage the SSH user keys.

15.7.1 About Oracle Key Vault and SSH integration

Oracle Key Vault centrally manages both the Secure Shell (SSH) private keys and SSH public keys. Managing the public keys enables access control of the SSH servers in the enterprise and managing the private keys enforces key governance, key management and organization for SSH keys across the enterprise.

You can perform both, SSH key setup and access control of SSH server setup as described in SSH Public Key Authentication and Controlling Access to SSH Server Centrally with Oracle Key Vault.

Figure below illustrates the SSH key and access control management, John initiates the connection to phoenix as SSH server host user Oracle.

John supplies the SSH client endpoint's PKCS#11 library. The PKCS#11 library fetches all the public keys that can be used to setup the connection. The keys are tried one by one until the connection is established. On the SSH server, Oracle Key Vault's endpoint lookup script checks for the corresponding public key in SSH Server wallet on the SSH server for authorization. If authorized, the SSH authentication process continues using the matched/authorized public key otherwise the connection attempt is blocked.

Note:

There is no footprint of the private and public keys on the SSH client or SSH server.

Figure 15-7 Centralized-SSH-Key-Management

Description of "Figure 15-7 Centralized-SSH-Key-Management"

An added advantage for SSH key and access control management is that the rotation can be done centrally. Revoke not only prevents the use of the compromised key on SSH clients but you can use it to block access to the SSH server as well.

You can use one or both of these measures to suspend SSH client user access of SSH servers. This helps when the SSH client user is not accessing the system for short durations like vacation, and you want to prevent unintentional, accidental, or malicious access of the SSH servers using the SSH client user's keys.

SSH Admin

SSH admin is an Oracle Key Vault user that owns the SSH endpoints and SSH wallets and may or may not be managing the SSH user keys. Typically, the SSH admin would also control the access to one or more SSH server or the SSH domain of the SSH admin.

There are two models of managing SSH user keys and access control to SSH servers. One where the SSH admin manages both. The other where the SSH client users manage their own keys and the SSH admin control access to SSH servers.

15.7.2 SSH Admin Managing the SSH User Keys and Access to SSH Servers

In this model, the Secure Shell (SSH) admin is responsible for the SSH key and access to SSH server management for the entire enterprise. SSH client users in a manner subscribe to the keys managed by the SSH admin.

The SSH admin has permissions to read, modify and manage the SSH server wallets and the general wallets that store the SSH keys of the SSH client users. SSH admin would typically create these wallets and grant necessary privileges to the SSH client users and SSH server endpoints.

SSH admin would also create and own the SSH server endpoints. And SSH admin would also be responsible for deploying the SSH server endpoint software on the SSH servers and modifying the OpenSSH daemon configuration.

SSH User Key Management

SSH admin creates the SSH key pair or registers an SSH key pair in Oracle Key Vault. The keys are created with certain key sizes depending on the organizational policies. The SSH admin can choose to associate a deactivation date with the SSH key pair. A notification is sent to the administrators when the key is expiring so that they can rotate the keys.

The SSH admin creates a general wallet for the SSH client user and grants the read access of the wallet to the endpoint used by the SSH client user. The SSH admin adds the newly created or registered SSH key pair into the SSH client user's general wallet. No other user or endpoint need to have access to this SSH key pair, specifically the SSH private key.

Access Control

SSH admin adds the SSH client user's public key to the SSH wallets of the SSH servers to grant SSH client user access to those SSH servers. SSH admin can remove the SSH client user's public key from the SSH wallet to revoke access of the SSH client user on SSH servers.

SSH admin can also remove the SSH client user's access from the SSH private key to prevent the SSH client user from accessing any SSH servers at all in the SSH domain. For instance, when an employee quits the organization and the access needs to be revoked from all SSH endpoints immediately.

15.7.3 SSH Client Users Manage SSH Keys and SSH Admin Manage Access to SSH Servers

In this model, the Secure Shell (SSH) admin is responsible only for controlling the access to SSH servers for the entire enterprise. The SSH client users own and manage the SSH user keys themselves. The SSH client users own and manage the SSH user keys.

The SSH client user creates two wallets: A general wallet holding the SSH public and private key pair of the SSH client user and an SSH Server wallet that just hold the SSH public key. Only the SSH client user has access to the first wallet. SSH admin has read access to the second wallet, the SSH client user's public key wallet.

The SSH client user creates or registers the SSH key pair in Oracle Key Vault and stores the key pair in the general wallet. Only the SSH public keys are stored in the SSH client user's public key wallet. The SSH client user owns and manages the SSH client user endpoint also. The SSH key management in this model is the responsibility of the SSH client user.

The SSH admin creates and owns the SSH server endpoints and the SSH server wallets. The SSH admins are responsible for deploying the SSH server endpoint software on the SSH servers and modifying the OpenSSH daemon configuration.

SSH User Key Management

The SSH client user creates the SSH key pair or registers an SSH key pair in Oracle Key Vault. You should create the keys with certain key sizes depending on the organizational policies. The SSH client users can chose to associate a deactivation date with the SSH key pair. A notification is sent to the SSH user and to the Oracle Key Vault key administrators before the key expires. The SSH key admins can also inform the SSH user that the keys are expiring in case the SSH user has not set up email alerts. The SSH client user rotates the SSH keys. The new SSH public key should be authorized by SSH admin in the same manner as the previous SSH public key.

Only the SSH client user has access to the SSH public and private keys. The SSH admins cannot deny the SSH client user access to the SSH keys.

Access Control

The SSH admin adds the SSH client user's public key from the SSH client user's public key wallet to the SSH wallets of the SSH servers to grant the SSH client user access to those SSH servers. The SSH admin can remove the SSH client user's public key from the SSH wallet to revoke access of the SSH client user on SSH servers.

15.8 Supported Platforms for SSH Server and Client Endpoints

Oracle supports 64-bit platforms for SSH server and client endpoints.

These are the supported platforms for SSH server endpoints in this release.

• Oracle Linux (8, 9)
• Oracle Solaris SPARC 11.4
• Oracle Solaris X64 11.4
• HP-UX (IA) 11.31
• AIX 7.3

  Note:

  The SSH server must use OpenSSH 8 or later.

These are the supported platforms for SSH client endpoints in this release.

• Oracle Linux (8, 9)
• Oracle Solaris SPARC 11.4
• Oracle Solaris X64 11.4

Note:

An OpenSSH must be at least at version 7.2p1 for endpoints that do not require a password and at version 8.1p1 for endpoints that do require a password.