I used:
scp -r name@xx.xx.xx:/home/user/ ~/Documents
At first, I ran the command on the server directory, so I copied it on the same laptop Then I understood what I needed to do ā run the same command, but in the destination terminal!
It took me about 4 hours to do that, to understand the process, manage the VMs, and everything elseā¦
after that,
LuksOpen
sudo mount mapper
and qvm-block attach
qvm-copy-to-vm for send file in other VM
Because I have an offline VM and a detached sdb for safety. The sdb is in my dom0.
21:21 ā Nothing worked :')) My VM didnāt have enough allocated space, so it couldnāt receive everything. Since I have a 900 GB disk thatās encrypted and only partially attached, I canāt send everything to the disk at once. When you send a file through another VM, itās actually written in the source VMās memory ā the one you configured.
After tweaking things too much, I got lost with /mnt/mapper, luksOpen, and qvm-block.
I managed to fix my issues with /mnt/mapper and the rest. Now I just need to recreate a VM with the encrypted sdb1 disk as its allocated space. :S
Anyway, Iām going to sleep ā Iāll deal with it tomorrow!
I donāt agree. This could be useful for other users who would like to set up the same.
But it would be nice if @User.LinuxOne could make it a bit more tutorial like ( so we can all benefit from what youāve learned) - with a dash of personal anecdotes on the side
Of course Iām a moron in your eyes because my opinion differs from yours. You wināhow does that make you feel?
Not everyone thinks the same, and some people may judge your comments the same quality as you judge the OP. You could have made your point in a million ways, but you chose these words.
Iām new to forums, so Iām still learning how to deal with comments like yours. Thank the universe we donāt all abide by the same posting etiquette.
At the end of the day weāre all here to learn, in whatever shape or form.
We definitely donāt need any insults round here.
I would say the OP was written in the aftermath of a long and unfinished fight with compartmentalisation, so I disagree about this part (or rather, I think itās an unfair judgement):
Additionally, I found a useful data point about the problems met by new (and not-so-new) Qubes users.
In this case, I think @User.LinuxOne had the following situation:
qube1 can have SSH access to a set of files on a remote server, but cannot store the data
qube2 has the storage space but canāt use ssh, because no network.
How to get the data from one to the other?
Ideally, qube2 would have to do an absolute minimum of processing of data from qube1
Seems it should be so simple!
After thinking about it, I realised Iām not sure how best to do this, and Iām quite glad for the OP.
Who knows an elegant and secure solution?
[Edited to correct the spell-checker. sash != ssh ]
My first idea was not very good...
The classic solution is something like:
use ssh to run tar -c myfiles on the source server, and to send a stream of data containing the files to a tar -C /home/user/destination/directory -x process which we run in the destination machine.
The naive and less secure method is to use two qvm-run processes in Dom0, with a pipe ā|ā between the two. This is similar to how I would have done it Before Qubes.
A little bit better would be to set up qrexec to allow qube2 to launch the ssh command in qube1. This gives the secure qube a bit more control, and avoids any data going through Dom0ā¦
BUT these solutions use the relatively complex tar format, which must be parsed in the destination, taking care not to overwrite existing files or fill existing directories with cruft.
Is there a more Qubes-ish way for doing itā¦?
An ssh-stream-proxy?
Could/should it be a two-way solution ?
Could we use qubes backup to push through it? Use a single backup command to make local and remote backups, for example.
Regardless of what has been said here, I would like to emphasize that the instructions stress not using the dom0 space; that is, it should not be touched or modified whenever possible. Doing so poses a potential security risk and goes against the Qubes OS philosophy.
Thanks to all of you for your feedback. I ended up working on the topic anyway, while staying within the Qubes philosophy of security.
So here is how I āsolvedā ā or rather handled ā the situation.
First, I used a disposable VM to transfer the data from my Debian machine into Qubes. The idea was to check the files afterwards, and if everything looked good, I could transfer them into the proper VM. All the configurations I had to set up for the transfer/verification process would then be wiped, keeping my VMs āclean.ā
But before anything else, I had to create an LVM structure for my sdb1 and integrate it into Qubes in order to create a VM with storage sized exactly like the disk. That way, I could transfer the files from the disposable VM directly into my āStorageā VM.
Hereās roughly what I did:
Encrypt the sdb1 disk
Create a physical volume with pvcreate on the encrypted partition
Create the volume group on the encrypted partition
Allocate 100% of the space with: lvcreate -l 100%FREE -T myvg/mypool
Integrate it into Qubes with: qvm-pool add mypool lvm_thin -o volume_group=myvg -o thin_pool=mypool -o revisions_to_keep=3
Create an offline VM using mypool as its storage
Right now, as Iām writing this (gladly!), Iām in the middle of transferring the files into a dispVM, but Iām stuck when trying to transfer two folders at the same timeā¦ āPermission denied.ā Yet after checking, Iāve got all the rights needed, and the folders are pretty much of the same type, so to speakā¦
I spent 5 hours after my first post, and once the research was done, the whole operation took me only 20 minutes!!
Ahhh, Linux distributionsā¦ quite the love story!
Thanks again for your feedback, and Iāve taken note that I should be a bit more detailed (like little tuto) when sharing my experience @queboss
Congratulations and thank you for the update. From now on, please respect the Qubes OS security model because it is the only real defense it has, and it is not absolute. Qubes OS is onlyā¦ a reasonably secure system.
I did not understand this remark of @Invictus at first, but I see that the sdb disk is used in Dom0 as a support for a qubes storage pool.
If the sdb is removable, then it could create new risks, but it depends how it is used outside the Qubes system.
If it is never used, then there is no threat to Dom0. If it gets malicious firmware installed from use in a dirty computer, then itās bad news all round and security model is toast. There are possibilities in between.
Unfortunately, the base of possibilities is currently infinite. Search the internet; thereās malware that can be found even in a simple *.jpg image. Now, there has to be a limit to paranoia in these matters, but you are entirely responsible for defining your risk model and security measures. Iām simply offering a well-intentioned opinion. Best regards, and please read all the documentation relevant to your interactions with Qubes. This community only provides voluntary support, and I donāt think that would be very helpful in a real emergency. Once again, your first line of defense is yourself, and probably also your last.
Your opinion does not reveal you are a moron because it is different than a competent Qubes user but because what you posted earlier is objectively dumb.
Itās okay if you do it once in a while. But if you do it too much you will shit up the board.
If one of those .jpg are opened with an image viewer compiled with full formal proof coverage the risk is zero. coq-of-rust is not the only answer to that category of need but is one of the good ones.
Look into CVEs related to filesystems where malformed filesystem information led to unintended code execution. There is also some history around malicious firmware in hard disk controllers doing DMA attacks. Jacob Applebaum touched on the latter in his talk at Chaos Communication Congress in 2013.
If sdb1 is used purely as a Qubes pool, created by Dom0 and directly used only by Dom0, then I do not see any risk, beyond the risk that Dom0 is already compromised by an upstream vendor, or that there is some horrible bug in xen.
The volumes in the pool are created by Dom0.
The filesystems put on the volumes in the pool are created by Dom0 by pure data copy, without using any filesystem code in Dom0.
The following are accessible only to Dom0, and to no other qube:
firmware of the sdb drive
partition table of sdb
raw block data of sdb
raw block data of sdb1
Each qube given a volume from the pool has access only to the block data from inside that volume. This is assured by xen (unless there is some horrible defect in xen), and by the volume handling code of Dom0 (unlessā¦etc).
Soā¦ if the condition above is satisfied, and you use it that way, then I think it would be reasonable to consider that the risk is too small to worry about. If there is a risk, then it would seem very likely to be present for all your other storage pools.
If you mount any volume containing non-Dom0 data and use it inside Dom0, then itās very differentā¦ but I think you are not doing that.
Edit: And of course, your Offline VM which allows you to look at your images and docs is exposed to everything you put inside that storageā¦ but I think you understand that.
Then I understood what I needed to do ā run the same command, but in the destination terminal!
