Experiments with Secure Remote Installation, Startup, and Remote Access

sphen

Well-Known Member
Joined
Dec 12, 2022
Messages
871
Reaction score
753
Credits
10,429
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 wrote a summary of my objectives in a PM for another member. I thought it useful enough that it would be worth sharing for others in this thread. Here are my objectives:
  • Take a "KVM" VPS and install any Linux on it.
    • KVM is one popular type of VPS. It is like owning bare metal hardware.
    • The alternative is OpenVZ. OpenVZ is similar, but has drawbacks.
    • When you look for a VPS, I recommend KVM over OpenVZ.
  • Configure the VPS so it can remote boot from a Linux installer over the internet.
    • I have this part working with netboot.xyz.
    • I want to serve the installer from another of my VPSs instead of netboot.xyz, so I know the origin of the Linux installer or can make my own installer if desired.
  • Install Linux from my remote installer.
    • In general, I have been installing Debian Linux, but the choice of distro is unimportant.
  • Perform a full disk encryption on the drive.
    • That can be done at installation time, or later.
    • One question I am trying to answer is: How I can unlock it one time so it can boot ... without depending on the VPS provider's console?
  • Configure a boot-time SSH server so that I can unlock the full disk encryption remotely over a secure SSH connection.
    • I have already done this using Dropbear.
    • I am trying to figure out if it is possible to install and configure the Dropbear SSH server during Linux installation, or find a procedure where it is concurrent with encrypting the drive.
  • Once I can boot and remotely unlock the encryption over SSH, I want to configure a secure remote controlled Linux desktop, so I can run a "personal computer" securely over the internet.
    • I am looking at a variety of different ways to do that:
      • VNC over SSH
      • xrdp over SSH
      • Xpra
      • x2go
      • Guacamole (a browser based interface)
      • Other options
    • I have tried a few already. They have their good points and drawbacks. There is more work to do before I am ready.
  • Finally - Document what I learned as a step-by-step procedure so that others can follow and add their own improvements.

-> Quite honestly, I had hoped to find others with related experience and interest here on Linux.org, but the bulk of activity seems to revolve more around Linux as the operating system for desktop computers. I have met some great people here, no doubt about that!

Can you suggest another friendly forum where others are pursuing interests closer to what I am trying to accomplish?
 
  • Once I can boot and remotely unlock the encryption over SSH, I want to configure a secure remote controlled Linux desktop, so I can run a "personal computer" securely over the internet.
    • I am looking at a variety of different ways to do that:
      • xrdp over SSH
Why do you want to use xrdp over ssh, xrdp already allows a secure connections through ssl/tls. If you want to use xrdp over ssh you can, all you would have to do is have xrdp running on your system without 3389 open in the firewall and then create a tunnel from your local system to the remote system where you then have a local port that gets tunneled to your remote system's local 3389 port.
 
Last edited:
Why do you want to use xrdp over ssh, xrdp already allows a secure connections through ssl/tls. If you want to use xrdp over ssh you can, all you would have to do is have xrdp running on your system without 3389 open in the firewall and then create a tunnel from your local system to the remote system where you then have a local port that gets tunneled to your remote system's local 3389 port.
Most of the solutions I tried used the typical SSH tunneling method as described in your link. If I recall correctly, one of them had baked-in SSH on both server and client side, but I do not remember which.

I do not have any preference for the transport layer as long as it is secure. I "wanted" xrdp over SSH because it seemed sensible, others were doing it, and I was able to make it work easily. I am open to xrdp over SSL/TLS with a browser interface if I can keep it secure and it makes sense. Guacamole is something I want to look at, for example. I tried it, but could not get it to work. I did not give it a fair and honest amount of time.

Honestly, it has been a few weeks since I tried out the various options. I had to set that piece of the project aside, and plan to pick it up again in a few weeks, after I clear out some other, higher priority projects. I have some virtual machine snapshots of the previous testbed tests labeled "RDP over SSH 2nd Time", "Xpra working barely", and "x2go working with LibreOffice and Firefox", and "VNC over SSH". I also ran VNC over SSH and xrdp over SSH from a VPS.

When I pick it up again - after I work off those projects and figure out the remote installation solutions - I will start over. Now I know a tiny bit more about how remote access works with Linux and can take notes on performance, user login support, etc.
 
I do not have any preference for the transport layer as long as it is secure. I "wanted" xrdp over SSH because it seemed sensible, others were doing it, and I was able to make it work easily. I am open to xrdp over SSL/TLS with a browser interface if I can keep it secure and it makes sense.
AFAIK xrdp doesn't have a browser option but it has an option to activate ssl for your xrdp connection so that your connection from your local system to the remote system running xrdp are encrypted.
 

Members online


Latest posts

Top