Hi, new to Qubes and just tried to SSH to my VPS via Terminal on my Debian10 VM. But this does not work, connection refused. Can anyone give me a hint please?
If you try from a TemplateVM, it’s normal that you can’t connect. You have to create an AppVM and connect from the AppVM terminal. In my case, it works very well.
If have tried it from a AppVM. In “Networking” I set default(sys-firewall) current. Maybe it has to do with my keypairs. Thx for your answer.
Now it worked for one of my VPS, it had something to do with the keypairs(permissions). On the second, connection refused port22, what is the standard I think. mmmmhhh
(Adjusted the title for clarity over the issue)
@grienekliess if you want to add some security magic check this out :
# 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 : We still didn’t make it into the community docs (Documentation | Qubes OS )?
1 Like