TL;DR:
I am experimenting with different aspects of secure Linux remote access, starting with secure remote installation through bringing the Linux desktop back to the local display.
-> Stop now! The paragraphs below are not the long gory messy details you are looking for. Move along to the next thread.
INTRODUCTION
This post started as a response to another thread that asked why there is a need for lightweight Linux desktops and also touched on remote installation. I started to reply and realized that I have a lot to say. My post would be hijacking that thread, so I started this one. In addition, this post is helping me organize my own thoughts, because the work has been wide-ranging. This was the original thread:
https://www.linux.org/threads/antix...it-true-É-verdade-¿es-cierto-cest-vrai.43173/
This thread describes several related areas where I have been experimenting recently. Those ongoing experiments were the reason I joined this forum a few days ago. I am not quite ready to post and ask questions, but I don't mind sharing where I am going with it. The paragraphs below may seem disjoint and unrelated, but not to me. I hope you will see how they relate to each other.
-> I am not expecting any specific response or help in this thread, but feel free to comment or make suggestions.
WHY LIGHTWEIGHT?
I run Linux in virtual machines on my personal computer and on virtual private servers (VPS), which are publicly accessible virtual machines on the internet. Those systems are often resource-limited, where a lightweight system is desirable. In addition, if you are operating remotely over the internet, then a lightweight system and desktop manager may yield better performance over other choices.
SECURE REMOTE ACCESS
I began to look at secure remote access solutions for a Linux desktop running on a VPS. (The term "remote desktop" has different meanings, depending on who you ask.) What a rabbit hole!
If you are going to run a Linux desktop remotely, you need a way to display it on the local computer. I built a virtual testbed to try various solutions. I also tested using VPSs on the internet, to gain a better understanding of the performance penalties associated with the internet. I tried VNC, xrdp, Xpra, and x2Go, and have prior experience with other solutions. There is much more to investigate, including commercial products like TeamViewer, NoMachine, etc. I am still trying to get Guacamole to work as well. I am mostly focused on self-hosted solutions rather than ones that rely on remote servers operated by third-parties, such as TeamViewer.
For security, most remote desktop protocols can be tunneled through SSH. Some may use their own baked-in security, such as SSH or TLS or something proprietary. I still have much to learn in this area. The one thing I have learned is that there is no standard, high-performance solution. To be honest, the "commercial" products generally give the best performance.I wish it were as simple as Microsoft Remote Desktop or Apple Remote Desktop, so Welcome to Linux!
LIGHTWEIGHT DESKTOP MANAGER
If you are running a Linux desktop over the internet, performance is a potential issue. It seems to me that choosing a very lightweight desktop manager would yield better performance over other desktop managers. My initial focus has been on Xfce and MATE.
While I was at it, I created a bunch of identical Debian virtual machines with a different desktop manager on each one. The choices were taken from the "tasksel" list at installation time: GNOME, Xfce, GNOME Flashback, KDE Plasma, Cinnamon, MATE, LXDE, and LXQt. I am still trying to parse what I learned so far. To be honest, I am still trying to figure out what I need to figure out related to Linux desktop managers and my experiments. (Yeah, read that sentence at least twice.)
WHOLE DISK ENCRYPTION and SECURE REMOTE UNLOCKING
If you are going to run a remote desktop Linux, you may want to use whole disk encryption to encrypt the entire drive and protect it from hackers. The problem is that when the system boots, you must unlock the encryption, usually by entering a password/passphrase. You can use the provider's console to enter it, but that entails its own risks.
A better approach is to install the dropbear SSH server. It runs at boot time and lets you establish a secure authenticated connection to your remote Linux system to unlock the whole disk encryption. You can configure it for public key authentication, which I recommend. I tested it, and it works well. See:
https://matt.ucc.asn.au/dropbear/dropbear.html
SECURE LINUX INSTALLATION
The most common virtualization approaches for VPSs are OpenVZ and KVM. OpenVZ uses a customized shared kernel where you must use the provider's control panel to install your choice of distro from a menu of selections with the modified kernels. You must trust whatever the provider provides. For me, they are a dead end.
KVM is like having your own computer. You can use the provider's installer (like OpenVZ), but most KVM VPS providers will download and mount a .iso of whatever distro you prefer, so you can perform your own installation. Most KVM VPS providers offer some type of virtual console through VNC (not secure) or a VNC frame inside your browser window. I wanted something better and more secure. You must also trust the provider not to tamper with your mounted .iso installer (a reasonable assumption, but not absolute).
I found this website, which offers various ways to boot and install Linux over the internet:
https://netboot.xyz
I tested it, and it works well. It is reasonable to assume that they don't tamper with the installers, but not absolute. (That is especially true considering that they start by downloading installers from the original distro sources and wrap them in their own remote installation tools, with an automatic build once a week.)
Their project is open source and the website describes how to self-host your own installers. I would like self-host my own Debian installer from another VPS, and I am currently trying to make that work. There is still much for me to learn.
-> This is my current area of focus, and I would appreciate some help from the people here. When I am ready to ask the right questions, I will start a separate thread about it.
OBJECTIVE
My objective is to tie them all together into an integrated whole and document it carefully. I would like to document the threat model - what it protects and what it does not protect, including which "holes" remain. I would also like to create a set of step-by-step procedures that others can follow.
A FINAL WORD ABOUT VPS SECURITY
For the record, your VPS provider has ultimate power over your running VPS. They can find the decryption key for your drive somewhere in RAM. If the VPS is not running, that is a different story. If you are doing something very very bad that might get the attention of a well-funded adversary, such as the US government, then using a VPS to do it is not a good idea.
I am experimenting with different aspects of secure Linux remote access, starting with secure remote installation through bringing the Linux desktop back to the local display.
-> Stop now! The paragraphs below are not the long gory messy details you are looking for. Move along to the next thread.
INTRODUCTION
This post started as a response to another thread that asked why there is a need for lightweight Linux desktops and also touched on remote installation. I started to reply and realized that I have a lot to say. My post would be hijacking that thread, so I started this one. In addition, this post is helping me organize my own thoughts, because the work has been wide-ranging. This was the original thread:
https://www.linux.org/threads/antix...it-true-É-verdade-¿es-cierto-cest-vrai.43173/
This thread describes several related areas where I have been experimenting recently. Those ongoing experiments were the reason I joined this forum a few days ago. I am not quite ready to post and ask questions, but I don't mind sharing where I am going with it. The paragraphs below may seem disjoint and unrelated, but not to me. I hope you will see how they relate to each other.
-> I am not expecting any specific response or help in this thread, but feel free to comment or make suggestions.
WHY LIGHTWEIGHT?
I run Linux in virtual machines on my personal computer and on virtual private servers (VPS), which are publicly accessible virtual machines on the internet. Those systems are often resource-limited, where a lightweight system is desirable. In addition, if you are operating remotely over the internet, then a lightweight system and desktop manager may yield better performance over other choices.
SECURE REMOTE ACCESS
I began to look at secure remote access solutions for a Linux desktop running on a VPS. (The term "remote desktop" has different meanings, depending on who you ask.) What a rabbit hole!
If you are going to run a Linux desktop remotely, you need a way to display it on the local computer. I built a virtual testbed to try various solutions. I also tested using VPSs on the internet, to gain a better understanding of the performance penalties associated with the internet. I tried VNC, xrdp, Xpra, and x2Go, and have prior experience with other solutions. There is much more to investigate, including commercial products like TeamViewer, NoMachine, etc. I am still trying to get Guacamole to work as well. I am mostly focused on self-hosted solutions rather than ones that rely on remote servers operated by third-parties, such as TeamViewer.
For security, most remote desktop protocols can be tunneled through SSH. Some may use their own baked-in security, such as SSH or TLS or something proprietary. I still have much to learn in this area. The one thing I have learned is that there is no standard, high-performance solution. To be honest, the "commercial" products generally give the best performance.I wish it were as simple as Microsoft Remote Desktop or Apple Remote Desktop, so Welcome to Linux!
LIGHTWEIGHT DESKTOP MANAGER
If you are running a Linux desktop over the internet, performance is a potential issue. It seems to me that choosing a very lightweight desktop manager would yield better performance over other desktop managers. My initial focus has been on Xfce and MATE.
While I was at it, I created a bunch of identical Debian virtual machines with a different desktop manager on each one. The choices were taken from the "tasksel" list at installation time: GNOME, Xfce, GNOME Flashback, KDE Plasma, Cinnamon, MATE, LXDE, and LXQt. I am still trying to parse what I learned so far. To be honest, I am still trying to figure out what I need to figure out related to Linux desktop managers and my experiments. (Yeah, read that sentence at least twice.)
WHOLE DISK ENCRYPTION and SECURE REMOTE UNLOCKING
If you are going to run a remote desktop Linux, you may want to use whole disk encryption to encrypt the entire drive and protect it from hackers. The problem is that when the system boots, you must unlock the encryption, usually by entering a password/passphrase. You can use the provider's console to enter it, but that entails its own risks.
A better approach is to install the dropbear SSH server. It runs at boot time and lets you establish a secure authenticated connection to your remote Linux system to unlock the whole disk encryption. You can configure it for public key authentication, which I recommend. I tested it, and it works well. See:
https://matt.ucc.asn.au/dropbear/dropbear.html
SECURE LINUX INSTALLATION
The most common virtualization approaches for VPSs are OpenVZ and KVM. OpenVZ uses a customized shared kernel where you must use the provider's control panel to install your choice of distro from a menu of selections with the modified kernels. You must trust whatever the provider provides. For me, they are a dead end.
KVM is like having your own computer. You can use the provider's installer (like OpenVZ), but most KVM VPS providers will download and mount a .iso of whatever distro you prefer, so you can perform your own installation. Most KVM VPS providers offer some type of virtual console through VNC (not secure) or a VNC frame inside your browser window. I wanted something better and more secure. You must also trust the provider not to tamper with your mounted .iso installer (a reasonable assumption, but not absolute).
I found this website, which offers various ways to boot and install Linux over the internet:
https://netboot.xyz
I tested it, and it works well. It is reasonable to assume that they don't tamper with the installers, but not absolute. (That is especially true considering that they start by downloading installers from the original distro sources and wrap them in their own remote installation tools, with an automatic build once a week.)
Their project is open source and the website describes how to self-host your own installers. I would like self-host my own Debian installer from another VPS, and I am currently trying to make that work. There is still much for me to learn.
-> This is my current area of focus, and I would appreciate some help from the people here. When I am ready to ask the right questions, I will start a separate thread about it.
OBJECTIVE
My objective is to tie them all together into an integrated whole and document it carefully. I would like to document the threat model - what it protects and what it does not protect, including which "holes" remain. I would also like to create a set of step-by-step procedures that others can follow.
A FINAL WORD ABOUT VPS SECURITY
For the record, your VPS provider has ultimate power over your running VPS. They can find the decryption key for your drive somewhere in RAM. If the VPS is not running, that is a different story. If you are doing something very very bad that might get the attention of a well-funded adversary, such as the US government, then using a VPS to do it is not a good idea.