(best) Split SSH setup guide

Nope, here all works super smooth. But for me it is just one sec. : select the vault VM in the pop-up and boom I am in.

Finally followed this through! It all worked in the end :slight_smile:

I was having the same issue, following the process. The solution was to install

  • fedora: libnotify and mate-notification-daemon
  • debian: libnotify-bin and mate-notification-daemon

This is the same issue as described here that broke so many people’s VPN configs.

Maybe a note about this should be added to the guide.

2 Likes

That is interesting and definitely unexpected (at least for me). I thought that an error with the notification should have no impact on the rest of the script because it is executed as a separate command, not related to any other line. We should probably try to avoid such errors instead of forcing users to install components which are ‘only comsetic’ (the popup message has no relevance for functionality).

I just found https://stackoverflow.com/questions/11231937 which discusses ways to avoid the termination of a script due to a single failed command. Maybe we could test some of the approaches listed there?

Another idea would be to just change the order of commands in /etc/qubes-rpc/qubes.SshAgent (socat first, notify-send second). Im not sure if this works, though.
Or we could check for existence of the command before exexuting it (see, e.g., https://stackoverflow.com/questions/592620).

I guess may brain was in usual programming language mode and didn’t even realize was not to be expected. But yes, in bash by default if something breaks, all the rest should be executed… So I’m not sure why this broke it.

I think for security the non-displaying of a notification should stop the rest of the script from executing. This is because the notification actually notifies the user that something happened. If it doesn’t show the user might not notice something has happened in the background.

Imho the security comes from the qrexec protocol itself which allows only those interactions that one has allowed in dom0 (either by explicitly defining “allow” in the rpc policy file or by interacting with a dom0 prompt if “ask” policy is used). The notify-send popup is just a nice bonus.

1 Like

While reading Restricting a Qube to selected websites I learned about qvm-connect-tcp (The Qubes Firewall | Qubes OS) which is probably what we should be using instead of our own netcat/socat approach.

I probably won’t be able to test this myself until in a few weeks.

3 Likes

On 4.1 this additional packages do not fix the problem.

Followed the nice guide on github, tested with both fedora-33 and debian-10 templates but ssh-add -L only lists keys in he vault, ssh-client AppVM always replies with
“error fetching identities: communication with agent failed”

Any ideas what i might be missing?

Edit: github guide works with stable Qubes 4.05

Please double chech all your AppVM names. I’d say in 90% of these cases it is a spelling mistake.

Jun 28, 2021, 18:18 by qubes_os@discoursemail.com:

Just set it up with my stable 4.0 Qubes and it works, i doubt i made typos since i copy pasted from guide into template and AppVMs.
Have been using split-ssh for a few years now on Qubes 4.0.x and switched to socat today.
Nevertheless will go one more time from scratch on the Qubes 4.1.

The guide does not work on 4.1.
Tests with original Marmarek 4.1. Alpha iso from last year and today clean install with latest 4.1. Alpha weekly iso and it just will not work.
Tests were done with a clone from a clean fedora-33 Template (ssh-client & vault-ssh AppVms) which comes with installed libnotify.
Without or with mate-notification-daemon no dice.
Test were done with Stable dom0 and current-testing update and reboot.

Would love to help pinpoint the problem but not sure where to look.

After taking a break from 4.1 testing i did find what the split-ssh guide on github is missing.
The vault vm template /etc/qubes-rpc/qubes.SshaAgent file needs to be made executable,
chmod +x /etc/qubes-rpc/qubes.SshAgent

I guess you’ve a typo here

For the record, this chat has result in this how-to wiki:

2 Likes

Yup. I had also linked it back in a previous post. But it’s a good reminder :slight_smile:

I’ve also edited the original post to include a link to that document.

Could you label it as solution.

1 Like

Yes, I have now moved it out of the “guides” category (since the discussion itself is not the guide) and have marked that as the solution.

1 Like

Made a new clean install of 4.1 rc1 restored my AppVMs and templates and noticed that i wasn’t able to get ssh split to work after creating the dom0 policy file.
Turns out i had to press ENTER after ssh-client vault ask and create a new line for it to work, might want to add this into the howto section about dom0 /etc/qubes-rpc/policy/qubes.SshAgent

1 Like

As far as I am aware, nothing about this guide is Qubes-4.1-ready (yet) and it’s awesome to hear from you that it is working (almost) flawlessly. For me personally, Qubes 4.1 is currently not working on my private device and therefore, I can’t test it.
I expect that the guide requires a few updates once someone gets their hands on a Qubes 4.1 installation due to the new Qubes policy file format (Qubes Architecture Next Steps: The New Qrexec Policy System | Qubes OS).

Note that, as the linked article says, the old file format is still supported but should be considered legacy. So we should migrate to the new format in due time.

Follow the github guide, it works with 4.1 versions and read my previous post just above yours.

That was meant as an answer to your last post :slightly_smiling_face:.

I know the GitHub guide. In fact, I helped writing it :wink:.

That’s why I am happy that it more or less worked for you. As far as I know, and I haven’t heard anything else from @whoami and @santorihelix (the other main co-authors, not to forget @deeplow), this guide has not “officially” been tested on 4.1.
As I said, apparently most of it can be migrated but I consider a legacy policy file format to be an intermediate solution at best. The ultimate goal should be to adapt the guide to the new policy file format for Qubes 4.1.

I didn’t dive into it at all so far, so maybe there is not much to do for us.

1 Like