borgbase
Present details and option to continue on SSH host key failure
https://github.com/borgbase/vorta/blob/2b1fce0936a932a8976f049e77d58b26e6ff9e84/src/vorta/borg/borg_thread.py#L73
If the backup server's identity and/or key changes the user should be warned, given the option to click "no [eg: I don't trust this server]", allowing the backup to safely abort.
I'm fine with removing this line. Didn't notice any issues for normal use cases.
Showing a warning mit more details and giving the option to continue would be the best solution. But we aren't set up very well to handle interactive SSH output.
PR added to just remove this for now until we can show a full message with the host key failure details.
I'm fine with removing this line. Didn't notice any issues for normal use cases.
Showing a warning mit more details and giving the option to continue would be the best solution. But we aren't set up very well to handle interactive SSH output.
PR added to just remove this for now until we can show a full message with the host key failure details.
Thank you, sounds good to me from a security perspective. Would it be possible to display an non-interactive error message with and "ok" button for now? The message would be something along the lines of "SSH connection failed for user_var@remote_host_name_var, please open a terminal and ssh user_var@remote_host_name_var to learn why it failed". I'm just thinking of how silent failures frustrate users, which I'm guessing is what the original intent of adding -oStrictHostKeyChecking=no was.
Will try. Thing is that SSH runs within Borg, so we need to pull up those messages into Vorta first. Let’s see.
Agreed, but that's more work! I'm just talking about a simple if fail, then present a generic ssh debug command notification, using variables in the string that Vorta already knows (nothing to do with ssh, other than that the called process exited with a non-zero status during the initial connection). Little more than an informative stub, and nothing fancy ;-)
ah, I missed one thing. It's borg that would fail with non-zero at this point...ahhh, now I see what you mean. Sorry :-)
Actually I had StrictHostKeyChecking turned off in my SSH configs too. That's why everything kept working.
With this option removed there will be a prompt by Borg and adding the repo fails.
In a perfect world, we would ask users to enter the fingerprint of the server. (BorgBase shows this fingerprint in the web UI.)
In reality this will increase the barrier for beginners. The complexity of SSH keys is already bad enough.
Still testing if there is a way to catch this error.
I think we should keep StrictHostKeyChecking=no for the borg init and borg info operations, which are used to add a new repo, but remove them from everything else. That way the mentioned MITM attacks would fail, but initially adding the repo would work.
Subsequently it may be possible to ask for the fingerprint when adding a new repo.
Since adding a new hostkey is not really what we want to avoid. What we really want to avoid is continuing after this. When a known key changed:
I think we should keep
StrictHostKeyChecking=nofor theborg initandborg infooperations, which are used to add a new repo, but remove them from everything else. That way the mentioned MITM attacks would fail, but initially adding the repo would work.Since adding a new hostkey is not really what we want to avoid. What we really want to avoid is continuing after this. When a known key changed:
:-) this makes sense. By the way, it was a team member of mine who raised this concern, and it's possible the Debian security team will ask me to patch our copy to disable this default.
Why wouldn't repo_url with \:.*$ truncated to populate the equivalent of 'Unable to add your repository.' in other repositories with an ssh connection debugging command not useful/more friendly than the current state?
Subsequently it may be possible to ask for the fingerprint when adding a new repo.
Agreed that will be nice to have someday :-) When I find the free time to make a solid PR I hope to discuss two of my wishlist items. No rush, of course.
I've updated my PR to only accept new host keys when adding a repo. Everything else will need the user to actually know and verify the host key when adding a repo.
The important thing is that changed host keys will now trigger an error for all subsequent operations.
By the way, it was a team member of mine who raised this concern, and it's possible the Debian security team will ask me to patch our copy to disable this default.
We are happy about all input, especially if it's security-related. The existing behavior wasn't great.
Why wouldn't repo_url with :.*$ truncated to populate the equivalent of 'Unable to add your repository.' in other repositories with an ssh connection debugging command not useful/more friendly than the current state?
Not sure I follow here. Currently we pass all logs through, but sometimes add a Vorta-specific message at the end. This can bury the really important message in the logs. So another nice-to-have is to have a mapping of important logs messages and pass them through no matter what.
Remaining task: if ssh key fails inform user and offer to continue.
Problem: we dont have a way to interact with a running borg command. So it would need to be restarted. Tricky.
@m3nu would now be a good time to get a recommendation from Thomas Waldmann? With borg 1.2.0 on the horizon, I also wonder if now is the time to request a new borg interface that will make interoperation with GUI front-ends more elegant, and also more reliable than log/output-parsing.
Interoperation is already quite good with most logs available as JSON. Thomas is also adding JSON for the borg diff command in the next version. So no complaints really.
SSH is more tricky because Borg passes errors through here. We'll figure something out anyways.
Manu @.***> writes:
Interoperation is already quite good with most logs available as JSON. Thomas is also adding JSON for the
borg diffcommand in the next version. So no complaints really.
Oh yeah, I seem to remember seeing commits that indicated we already had JSON support! :-) (sorry for not making the connection)
SSH is more tricky because Borg passes errors through here. We'll figure something out anyways.
Agreed, and it's a shame OpenSSH appears to not support a rich set of exit codes, like:
https://lxadm.com/SSH_exit_codes
...from what I can tell the OpenSSH most people have access to only supports "0" and "255" :-(
I could be wrong, but it seems that Borg would only be able to pass through these two exit codes, plus stdout and/or stderr.
That said, Paramiko appears to have good support for SSH errors:
http://docs.paramiko.org/en/stable/api/ssh_exception.html
and Vorta already uses Paramiko! So maybe do a pre-operation SSH link and login check with Paramiko, do nothing on remote host, and if successful then do the target operation with Borg?
and Vorta already uses Paramiko! So maybe do a pre-operation SSH link and login check with Paramiko, do nothing on remote host, and if successful then do the target operation with Borg?
That's a good idea actually. Will look into that.
Hi, I can confirm that if the fingerprint change in the server, Vorta will display :
In command line, the error will be :
It took me a while to find the error because I searched on the server side at first :D . So I'm staying subscribed to this issue to be alerted of the update. Thanks
