vorta is stricter than openssh about config file modes, and warnings are not shown to the user

[candreasen-krc]

Describe the bug I encountered a frustrating-to-diagnose issue with vorta, where ssh connections to BorgBase worked fine with ssh -v, but did not work in vorta, because some of my ssh config files (I include ~/.ssh/conf.d/* from my main config file to keep things organized) were group-writable/world readable. Not sure if this should be made more permissive (ssh -v did not complain about those files, so I assumed the issue lay elsewhere) or simply give a more descriptive error message to the user (running the flatpak from the command line revealed this warning: "WARNING - Remote: Bad owner or permissions on /home/candreasen/.ssh/conf.d/"), but as-is I found it very frustrating.

To Reproduce

1. create .ssh/config that includes these lines (or similar): Include conf.d/* Host *.repo.borgbase.com IdentityFile ~/keys/ssh/id_rsa
2. create a folder and file .ssh/conf.d/foo with an unrelated ssh config and mode 0655: Host example.com IdentityFile ~/.ssh/foo
3. test the connection using ssh -v [email protected]:repo (should show no config file errors, and end with PTY allocation error indicating a successful connection)
4. open vorta and attempt to initialize a new borgbase repo using the key specified in step 1

Vorta will fail with "Connection closed by remote host. Is borg working on the server?", and the logs/terminal output should show "Remote: Bad owner or permissions on /home//.ssh/conf.d/foo"

Environment (please complete the following information):

• OS: Ubuntu 18.04.6 LTS
• Vorta version: 0.8.3
• Installed from: 1.1.15

Additional context If appropriate include logs. Can be found in Main Window > Misc Tab > Log.

[m3nu]

Not sure if this should be made more permissive (ssh -v did not complain about those files, so I assumed the issue lay elsewhere) or simply give a more descriptive error message to the user (running the flatpak from the command line revealed this warning: "WARNING - Remote: Bad owner or permissions on /home/candreasen/.ssh/conf.d/"), but as-is I found it very frustrating.

How could Vorta help here without getting involved with SSH implementation details? We do parse some errors, so we could redirect important ones to the GUI.

[candreasen-krc]

I assumed that because ssh -v is not complaining, but vorta is, that vorta is doing this checking on its own, but maybe vorta is just calling SSH with a different flag or setting of some sort that triggers more strict checking? I haven't dug in to look.

But even just bubbling up to the GUI user that "Remote: Bad owner or permissions on /home/.ssh/conf.d/foo" warning, that vorta is already logging would have made this a trivial problem to fix, so that would also work, yeah!

The main reason I reported this is because I saw somewhere in documentation to test connections using "ssh -v", which is significantly undermined as a troubleshooting tool if it behaves differently than vorta itself.

[m3nu]

No, we don't even run SSH directly. You can only select the key and add one if you want. That's mostly there to help users make backups without going into the CLI.

[real-yfprojects]

This seems to be an issue of borg because vorta simply forwards the error message borg outputs. Try whether the following reproduces the error:

> export BORG_PASSPHRASE=<password>
> BORG_RSH='ssh -oStrictHostKeyChecking=accept-new -i <home>/.ssh/conf.d/foo'
> borg init --encryption=<encryption-key> <repo>

[candreasen-krc]

Ah, you are correct, the strictness about file modes is coming from borg. Personally I think that these warnings should be shown to the user in vorta though, at least if the error is fatal.

Thanks for the quick replies! I'm glad this project exists, much more friendly for desktop use than the custom shell scripts I use in server environments.

Edit: there are prior issues that should have covered this as well, a couple other people with the same issue were pointed at #375 but that was closed without implementation I think? Seems like the core issue is that vorta is only displaying the last error that borg outputs, but the relevant one, at least in this case, is the first message. Displaying all lines of borg output when there is a fatal error might work? or even just referring people in the documentation to check the log file in case of generic borg error messages would work as a stopgap.

I didn't realize there was a log or how to get to it from the UI until someone on here pointed it out, since it's a hyperlink and somewhat hidden away.

[real-yfprojects]

#375 wasn't closed but migrated to github discussions. I see two issues here: The first issue is that vorta shows the error only in a small status bar without referring to the logs which is especially problematic when creating a new repo since that takes place in a different window. The second issue concerns borg itself because it outputs ssh error message as a warning and outputs a non-descriptive error message additionally. Instead it should throw only one error explaining that ssh failed with the error from ssh.