When adding new git host, I receiving:
The repository host key could not be verified. Please update your known_hosts file and try again.
I know I can fix it manually, but I trying to organise dev team work and not going to make them fix things in console for each container instance. Why if they can create ssh keys, add remotes, etc, they could not aproove known hosts update ? Also it seems known hosts not project-wide, may be just place it under .git/node-red-known_hosts and make it project wide along with other project auth settings
So my request is to add a button "Update Known hosts" here, with new fingerprint display:
If the standard output offers the possibility of adding the fingerprint, I think it is feasible because the idea is to just "type" yes. In the other case, the editor MUST do nothing because this would authorize the editor to modify by itself the SSH parameters.
You can do it automatically (this is overridable if cmdline used) not only typing yes, or you can force type yes in gui if security circumates requeire this, it is just inconvinience to manual setup complete automated containers.
UPD: after some thinking, i got that I can make a node which forces known hosts... still not good that they system wide.
There may be a security risk - we need to restrict the case where the editor can ask to update the file. @TotallyInformation what do you think?
The more you let Node-RED do with the system, the more dangerous it gets, that's a given.
As with much to do with security, the devil is in the detail. If Node-RED is running under each individual user ID then letting it do what a user can do manually may be fine. But if you are running a single instance, machine-wide, then I very much doubt that it would be very safe to let Node-RED be able to update a system-wide fingerprint.
What would happen if someone gained access to the system and added a new, rogue host?
If you want to automate a development or test environment, then I would recommend automating it outside of Node-RED in a separate process. The best thing to do is to automate the creation of the environments and update the known hosts files as part of that. Similarly, when removing environments automate the whole thing.
Production environments are different. They need to be even more secure. Here you should be not only automating management of virtual environments but also putting keys into a key management service.
"DevOps" is the keyword here, there are great reasons why DevOps principals have taken over the management of environments, using development style tooling to automate environment management. Every new environment should be created from a template.
1 Like
Same as when you typing "yes" manually (how much people cheking fingerprints with something (with what you suggest [scenario - you suspect that remote is compromised] ? ) when they type "yes" ?) , or do stricthost checking=no to update host, I complete understand security concern about this.
I just placed red button on dashboard, where you shall enter hostname to force knowhost reset, I think it even harder to mistake, than when you typing "yes". Especially when remote is internal network vpn gitlab.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
