Feature request - SSH key management for SCP Publisher

[knuhg]

Overview

In a service delivery organization where operation, governance and administration is often distributed over multiple roles and responsibilities, it is beneficent if service administration can be performed uniformly in a central administration/management facility rather than being spread across different access forms and user interfaces which in turn often challenges restriction of privileged access. An example of such non uniformity in EJBCA is the configuration of SCP Publishers where admin portal (GUI) facilities, access and rights is not sufficient to be able to implement and configure the publisher service as it also requires direct (remote) file system access to the operating system on which EJBCA resides.

At current the SCP Publisher requires a SSH key pair and the list of known SSH hosts to be present as files in the local file system of the operating system that EJBCA resides on. The path and name of these files are then entered as parameters to a SCP Publisher configuration and the EJBCA system accesses these files from the file system as required when the SCP Publisher job is executed. This is particularly problematic when running appliance variants of EJBCA where direct OS access and custom additions to the file system is undesirable.

This feature request is raised to address the particular issue of SCP Publisher administration in an effort to improve the management of the PKI service platform and potentially improve its operational robustness and resiliency. Further, the overall security of the PKI eco system may also be improved if the SSH private key is generated in EJBCA and never exposed neither to the administrator or to the underlying operating system when compared to the current implementation.

Proposed implementation

Internally the EJBCA code base utilizes the JSch (Java Secure Channel) library to perform SSH/SCP operations. Currently the EJBCA implementation is to provide JSch with the path and file names which it in turn reads from the file system when a session is created (ScpPublisher.java, lines 446-451). The JSch library provides alternative functions where the key file contents can be provided directly through byte arrays ( public void addIdentity(String name, byte[]prvkey, byte[]pubkey, byte[] passphrase) ). With regards to known hosts there is a function available where the contents can be provided in the form of an inputstream object ( public void setKnownHosts(InputStream stream) ). Thus, the facilities exists in the dependency library to utilize data stored in the EJBCA database instead of referencing to files as in the current implementation.

Expected additions and alterations to be implemented:

• Extend EJBCA database to store sets of SSH key pairs and related known hosts information for usage with SCP Publisher (and potentially other functionality that utilizes SSH sessions via JSch)
• Add admin portal functionality to manage SSH key pairs and known hosts stored in EJBCA database:
  • Ability to generate a SSH key pair with selection of algorithms and key lengths appropriate for SSH keys supported by JSch
  • (optional) ability to upload or input/paste an existing SSH private key
  • Ability to name a SSH key pair
  • (optional) ability to store further metadata (for instance description, environment, hostname, reference, contact person etc.) associated with the SSH key pair
  • Ability to upload or input/paste SSH known hosts information related to a particular key pair
  • (optional) ability to activate and deactivate SSH key pairs stored in EJBCA (only active keys should be possible to use for a Publisher and a key in use should not be possible to deactivate)
  • Ability to delete a stored SSH key pair (any key in use by a publisher should not be possible to delete)
  • Ability to edit the stored SSH known hosts information for a SSH key pair
  • Ability to rename a stored SSH key pair (and edit any additionally supported metadata fields)
  • Ability to view and download the SSH public key for a stored key pair
• Extend SCP Publisher configuration:
  • Ability to select a (active) stored SSH key pair (and its related known hosts information) for use with the SCP publisher
• Extend SCP Publisher implementation:
  • Ability to fetch database stored SSH key pair and known hosts information if so configured
  • Ability to utilize alternate JSch functions when configured for usage of database stored SSH keys and known hosts:
    • public void addIdentity(String name, byte[]prvkey, byte[]pubkey, byte[] passphrase)
    • public void setKnownHosts(InputStream stream)
• (optional) Extend EJBCA access rules to regulate new admin portal functionality
  • /ca_functionality/edit_publisher_SSH_keys/
  • /ca_functionality/view_publisher_SSH_keys/

Makes sense?
Now, I am a infrastructure and service architect and not a Java developer, so I do not think I would do a very good job at coming up with the code so I would have to leave that to the professionals :)

Discussion and comments welcome.

BR,
Knut

(Edit: changed indentation on some items in the bullet list, mostly for aesthetics)

[mike-agrenius-kushner]

My dude.

That was the finest feature request I've ever had the pleasure to read.

So the good news is that we're releasing EJBCA 8.0 Enterprise in June with SSH Certificate support. The SCP publisher has been around for a few years (albeit somewhat unloved), but naturally connecting the two is on the roadmap. I can't say for sure that it'll make it into 8.0, but likely in a release before the year is out.

Now, the solemn news is that while we've released the SCP publisher to the Community, we're not quite ready to do so for SSH certs, so the above feature won't be in Community as it's planned right now.

But again let me say...that was a gorgeous damn FR.

Cheers,
Mike

[knuhg]

Hehe, glad to hear ;)

As you point out, combining the features seems natural and logical. If the option of allowing upload or input/pasting of existing/pre-generated keys were implemented that may be a solution to bring the functionality of SSH key management to the community edition also even with the absence of the new SSH cert features. Just a thought as I think this would be valuable also for CE users in say a container environment.

Now, we are on the EJBCA Enterprise wagon and utilizing both physical and virtual appliances in our environment so the new feature of SSH cert support exclusive for Enterprise at this point is fine by us. I put the feature request here on the CE GitHub as it seemed appropriate to look at it in the full context of EJBCA across the variants.

BR,
Knut