Split SSH with Password Does Non Persist Reboots

0x9060 · January 15, 2021, 7:29pm

I’ve setup some SSH-Vaults and AppVMs which use those ssh-keys for Split SSH, consistent with this guide (and may others out there).

I actually have 2 SSH-Vaults, one for work where my SSH key also has a password, and another for personal use where my SSH key does not have a password.

I’ve used ssh-add to add the keys to the agent in each vault, and verified access using ssh-add -L. After rebooting each vault, the password-protected key does not persist, so I have to use ssh-add again in the vault, while the non-password-protected key does persist.

The vaults are running Fedora30.

Is there some trick or script updates I must use to make the password-protected-key persist through reboots?

deeplow · January 16, 2021, 11:06pm

There is a very recent guide made by a few folks here on the forum. I’d suggest you give that one a shot. The one you mentioned is 4 years old.

Here it is:

github.com

Qubes-Community/Contents/blob/9c0d278ab7f2283b1bfacd06150439891b11f9aa/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

In these cases, always look first at the documentation the Qubes website. It pointed to this one I mentioned under “Split SSH”.

0x9060 · January 17, 2021, 5:13am

The one I mentioned is 4 years old, but the one you mentioned is less than 4 months old. It’s a very tall order to expect users to stay apprised of updates to all guides that might affect a user with that kind of timeliness. Anyway, the recent guide you reference is exactly the same implementation as the 4 year old guide, with the exception of using socat instead of netcat, but with one important addition:

it makes it clear that whether using ssh-askpass or KeePassXC to store SSH passwords, each method requires re-entering some password (either the SSH password for ssh-askpass, or KeePassXC db password) upon reboots of the vault.

Still though, thanks for the reference!

deeplow · January 17, 2021, 10:35am

Yup. I feel that. The external documentation part on the Qubes website is the go-to index for this sort of stuff (Documentation | Qubes OS). The community documentation should be in sync with that.