(best) Split SSH setup guide

mono · July 1, 2021, 1:45pm

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.

mono · July 6, 2021, 12:12pm

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

whoami · July 6, 2021, 12:53pm

I guess you’ve a typo here

whoami · August 30, 2021, 6:38am

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

github.com

Qubes-Community/Contents/blob/master/docs/configuration/split-ssh.md

# Qubes Split SSH

Split SSH implements a concept similar to having a smart card with your private SSH keys, except that the role of the “smart card” is played by another Qubes AppVM. 
This Qubes setup allows you to keep your SSH private keys in a vault VM (`vault`) while using an SSH Client VM (`ssh-client`) to access your remote server. 
This is done by using Qubes's [qrexec][qrexec] framework to connect a local SSH Agent socket from your SSH Client VM to the SSH Agent socket within the vault VM. 
This way the compromise of the domain you use to connect to your remote server does not allow the attacker to automatically also steal all your keys. 
(We should make a rather obvious comment here that the so-often-used passphrases on private keys are pretty meaningless because the attacker can easily set up a simple backdoor which would wait until the user enters the passphrase and steal the key then.)

   ![diagram](https://raw.githubusercontent.com/santorihelix/qubes-splitssh-diagram/main/split-ssh-keepassxc-8.svg)

## Security Benefits

In the setup described in this guide, even an attacker who manages to gain access to the `ssh-client`  VM will not be able to obtain the user’s private key since it is simply not there. 
Rather, the private key remains in the `vault` VM, which is extremely unlikely to be compromised if nothing is ever copied or transferred into it. 
In order to gain access to the vault VM, the attacker would require the use of, e.g., a general Xen VM escape exploit or a signed, compromised package which is already installed in the TemplateVM upon which the vault VM is based.

## Overview

1. Make sure the TemplateVM you plan to use is up to date.
2. Create `vault` and `ssh-client` AppVMs.

This file has been truncated. show original

deeplow · August 30, 2021, 9:19am

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

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

whoami · August 30, 2021, 9:20am

Could you label it as solution.

deeplow · August 30, 2021, 9:21am

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.

mono · October 26, 2021, 7:26am

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

phl · November 14, 2021, 5:36pm

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.

mono · November 14, 2021, 7:09pm

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

phl · November 14, 2021, 8:35pm

That was meant as an answer to your last post .

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

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.

mono · November 14, 2021, 9:32pm

my bad haha, just saw the email text and thought you had trouble, thanks for the Guide (;

whoami · November 16, 2021, 6:13am

I am still here but I didn’t update to 4.1, I will wait for the final release. Currently, there is too much other work to do and I need a working system. Sorry.

@mono thanks for the fix.

pyyjac · January 7, 2023, 7:51pm

In case someone has the same (stupid) problem like me… If you’re using another Shell then Bash, ~/.bashrc probably is the wrong file.

I’m using ohmyzsh in my coding qube and it to me some time to see my mistake. The guide itself works fine. Thanks for that.

mono · May 30, 2023, 7:45am

Updated from fedora 36 templates to fedora 38 for my ssh qube and run into this odd new behavior which probably has an easy solution if i only knew where to look.

First, split-ssh “works as expected” but after pressing enter on the pop up window my ssh window is out of focus and needs either alt tab or mouse click to get back to focus.
This can get annoying pretty fast. Anyone else experience this?

EDIT: To fix this behavior go to Q > System Tools > Window Manager > Focus > and uncheck Automatically give Focus to newly created windows.

Must have snug in with one of the recent updates.

bert7 · February 1, 2024, 12:18am

I’m trying to setup Split SSH for git on a fresh installation of Qubes OS 4.2, but having trouble getting it to work. Like @haaber in #19443 and @mono in comment #38 of this topic, when executing ssh-add -L in the ssh-client VM I click the accept button in the dom0 Operation execution popup for qubes.SshAgent, but the ssh-client VM console prints error fetching identities: communication with agent failed regardless. Both the vault and the ssh-client VMs share the same fedora-38-xfce template that was installed when I installed the OS. First I followed the Split SSH setup guide and then tried virtually any combination of:

Plain setup vs. KeePassXC
@anyvm vs. real VM names in dom0 /etc/qubes-rpc/policy/qubes.SshAgent
ask vs. ask,default_target=vault-VM-name in dom0 /etc/qubes-rpc/policy/qubes.SshAgent
socat vs. ncat in TemplateVM /etc/qubes-rpc/qubes.SshAgent and ssh-client VM /rw/config/rc.local
Trailing newline (comment #48 of this thread) in dom0 /etc/qubes-rpc/policy/qubes.SshAgent
& character before or after the " character in ssh-client VM /rw/config/rc.local
Renaming SSH_AUTH_SOCKET to SSH_SOCKET (to mirror the variable names used in other parts of the guide) in TemplateVM /etc/qubes-rpc/qubes.SshAgent and ssh-client VM ~/.bashrc

I suspect that I’m missing something, so I would like to know if someone got Split SSH working on Qubes OS 4.2.

The next issue is that git push seems to invoke gnome-ssh-askpass on fedora-38-xfce. I don’t know much about distros, but is gnome in xfce supposed to happen?

$ git push

error: unable to read askpass response from '/usr/libexec/openssh/gnome-ssh-askpass'

Username for 'https://...': <empty>

error: unable to read askpass response from '/usr/libexec/openssh/gnome-ssh-askpass'

Password for 'https://...': <empty>

remote: No anonymous write access.
fatal: Authentication failed.

Sorry for not linking to the topics and comments, new forum users are only allowed to post 2 links per post.

mono · February 1, 2024, 11:48am

it worked for me on the reinstall a few weeks ago, did you try to press enter at the end of line in the dom0 policy file you created?
With the newline it suddenly worked for me when i encountered the problem, posted that above back then.

bert7 · February 1, 2024, 1:57pm

Thanks for the quick reply - yes, that is what I meant in step 5 of my previous post. But if it works for you, then it’s not the OS stopping me, but me doing something wrong. I’ll try to come up with more things to test.