Host Key Failure? Only when command run via execution node in NR? Not sure this is actually an NR error.
But something is odd. If I run the following command from the NR instance, i.e. terminal session it works. The host key is valid, the public key was pushed the remote system. The sudo configuration explicitly allows the command to be run under the id noted, i.e. 'nodered' for course.
ssh -i /home/nodered/.ssh/id_ed25519_eccentric nodered@fracture-ethernet "sudo systemctl poweroff" Host key verification failed.
However, if I run the exact same command via an execution node I get result code 255, host key validation failure. Wondering if anyone has tripped over this type of thing? Might be able to suggest how to tackle this?
If you are trying to turn a machine off there may be privilege problems.
The shell node-red creates may not have the rights to do that, even though you are trying to send it the command. sudo etc.
Alas it is above my skill set, but I remember seeing similar problems and it was to do with that sort of thing.
Hi @Jibun-no-Kage,
The host key (for the server you are trying to connect to)
Needs adding to known_hosts BUT…. for the Node RED service account, running Node RED.
On the Node RED host itself, log in to the Node RED user account, and interactively connect to the target server - this (should) prompt and save the trusted host key.
Or….. copy known_hosts to the Node RED user account, from an account that already connects successfully from the source machine.
Just be careful.
I could be wrong in my assumption here, I rarely do ssh stuff, so others may correct me.
-i selects the client key; it doesn't select known_hosts. Run id and ssh -G fracture-ethernet through the exec node and compare with the working terminal, especially hostname and userknownhostsfile. -G only prints the effective client configuration, so it won't connect or execute the shutdown command.
For an actual connection test, use remote true instead of sudo systemctl poweroff. Host-key verification fails before the remote command runs; you can investigate it without switching the machine off.
@Trying_to_learn, (Long time no post with!), Like I noted, if I run the command directly it works. It is only from the execute node I have the issue. This suggests, the known_hosts file is correct, as well as the communication is happening correctly when direct shell test.
@marcus-j-davies, NR is running under 'nodered', I did not mention that. I ran ssh-copy-id under that same id, to stage the key. As I noted above the command works just fine from NR system to the remote system from SSH shell, direct execution. Just not from NR its self.
@krotname, excellent suggestions.
Everyone, thank you... more testing of course. I could also have execute node run a local script, that does the actual invocation of the command... that would likely work, but not as elegant or efficient of course.
Hi @Jibun-no-Kage,
I think there are two viewpoints being discussed here.
The client key might have been transferred, but does the Node-RED process user (that is configured in the systemd file) have access to a known_hosts file that trusts the target server?
For example, when you run the command in an interactive shell, are you doing that under a shell owned by the same user that is running the Node-RED process?
I think @krotname is actually trying to ask the same thing I'm asking: whether the Node-RED process user has recorded and trusts the target server's host key.
EDIT
If you ran ssh-copy-id under a shell owned by the process user, then in theory - it should have already trusted the target server (maybe... 
), so my question above .might be a moot point.
