Security issues with the External SSH Tool

[RNovak]

I’d like to get the community’s take on the following implementation issues with the External SSH Tool. I feel that the design of this node is severely lacking, and causes some real issues when using it in an environment where workflows are deployed and run on KNIME Server.

First we look at the SSH Connector node, which uses good design.

Here, the private auth key is specific to the workflow/node. It can be included in the workflow repository directory and referenced via the knime://knime.workflow metaURL. Only the specified key is used to attempt to authenticate to the SSH endpoint, resulting in a single AUTH key exchange.

Now, the External SSH Tool.

Here, there is no option to specify the public key to use to authenticate against the provided hostname. Instead, this node uses the private keys configured in Preferences/General/Network Connections/SSH2. So, keys are configured at the executor level, not the workflow level. This is bad juju.

How does the node know which key to use? It doesn’t. It just tries each one in turn. This means that if I’m trying to connect to host “slanthammer”, the node tries the keys for testhost001, testhost002, and dublduck before a successful auth KEX for slanthammer. In a KNIME server environment where there may be many flows requiring connectivity to many systems, thus requiring a long key list, this can result in excessive failed auth attempts, tripping security alarms and requiring MaxAuthTries being set excessively high on the endpoints.

Additionally, because this node uses system-level settings and not workflow/node level settings, any updates to add new keys is disruptive - all server nodes must be restarted.

I’d very much like to see this node re-implemented to use node-level configuration of SSH private auth keys, similarly to the SSH Connector. The current implementation is bad, and compromises security best practices.

[marvin_kickuth]

Hi @RNovak,

you bring up valid points. While the (newer) SSH Connector node covers many cases where SSH is used, it doesn’t support all features the External SSH Tool has.

I have created an enhancement ticket (internal reference: AP-19772) to look into updating the External SSH Tool.

Out of curiosity (and possibly for design choices), it would be interesting to know what use-cases require many different keys for many different servers.

Kind regards
Marvin

[RNovak]

Thanks @marvin_kickuth,

We have an environment where the KNIME Server supports multiple analytics teams. In most cases, because of the nature of our business, the sensitivity of the information handled (we’re in a regulated industry), and the nature of our general IT systems support (workload-specific VMs rather than large general purpose servers), each of those teams has their own set of server endpoints. Typically a dev/staging environment as well as one or more production VMs. These endpoints are generally used to perform high CPU/memory loads that would bog the KNIME Server down - Python/conda machine learning models, large data merges/ETL operations, deep statistical analysis ops on large dataframes, etc. The flows use External SSH Tool nodes to transfer database credential/key files and invoke those resource-intensive processes.

Our current environment supports around 20 teams. Of those, maybe a third employ workflows that require remote command execution. And each of those may require multiple keys to support different environments where security requirements demand separate authentication credentials. Right now, our key list sits at a little over a dozen, but it’s growing as workloads come online.