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.