Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide known hosts handling from GUI #1754

Open
Forage opened this issue Apr 29, 2024 · 2 comments
Open

Provide known hosts handling from GUI #1754

Forage opened this issue Apr 29, 2024 · 2 comments

Comments

@Forage
Copy link

Forage commented Apr 29, 2024

Is your feature request related to a problem? Please describe.
Known hosts handling is a bit cumbersome. When you run a task for the first time, it is likely to fail with a "Host key verification failed" error because the key of the system you connect to is not known yet. The same issue will occur when e.g. the IP address of a known host has changed. The only way to add new keys to the list of known host is to either add it manually to /root/.ssh/known_hosts or make an ssh connection through ssh manually. Either way, it can not be done through the web UI.

Describe the solution you'd like
Ideally it should:

  • Perform a test connection when creating a new task or when altering an existing one. Or at least offer to perform a test of not done automatically. This to retrieve the host key.
  • Offer to add/accept new keys through the UI and store/replace them in the known_hosts file

Describe alternatives you've considered
An alternative would be to accept every key automatically, but I'm less comfortable with that from a security point of view. It could be an optional service though, specifically enabled in the settings.

@votdev
Copy link
Member

votdev commented May 7, 2024

It does not make sense to me to manually modify this file. I have also never heard or read that this file is maintained manually.

@Forage
Copy link
Author

Forage commented May 7, 2024

You don't have to, and I'm not saying you should, but you can change the known host file manually.
You either get the key added by making a connection to the other machine, which provokes the question if you want to add it, or you add the key manually for whatever reason.
I did it in the past to change e.g. the hashed host name to a non-hashed one and to quickly migrate known keys.
The manual editing is not relevant for the issue though.

My use case is adding new rsync tasks to new/unknown hosts with a connection using ssh/private keys. You can add the tasks, but they will fail later on when the scheduler kicks in, because it won't be able to make a connection due to the host key being unknown.
Ideally it should offer to make a test connection when you create a new task or change the destination of an existing one. Followed by adding the key to the known host file.

Some additional 'intelligence' could be added, by looking at the destination host address and checking if that address in already used by other tasks. Though this isn't necessarily reliable, since you could define multiple new tasks in one go without importing the key. For this to work properly, OMV would need to check the actual (non-hashed) known host file, or maintain a double list, to see of the address is already listed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
7.x
Backlog
Development

No branches or pull requests

2 participants