New Free VPS Location! Alexhost, Chisinau, Moldova via FOSSVPS!

zed · August 2025

You're screwing with the name recognition though man.

I catch up on the posts here and by the time I hit next thread I've already forgotten all the names and only remember thanks thanks thanks and then https://en.wikipedia.org/wiki/Semantic_satiation and I don't even know what's going on anymore!

Thanks everybody!

edit: ok I solved it for myself with quick userscript to replace thanks whew.

cmeerw · August 2025

@Not_Oles said:
@cmeerw If I understand right, there seem to be at least three reasons why no user gets access to all the VNC consoles. First, if I understand right, VNC isn't running on the currently deployed VPSes, except for one. Second, each VPS' console would run on a different port, and each user account would get restricted access only to that one port. Third, VNC has password capability which could be used, although I don't believe we set a password for the single VNC which is running now.

I thought you would password-protect VNC access (and was wondering how you would then manage those passwords), but then got confused when you said no password needed.

The way it works is that VNC runs restricted to localhost. The user gets a host account with the shell set to /usr/sbin/nologin. The user connects via an ssh tunnel. There is a per user sshd configuration on the host:
  PermitOpen 127.0.0.1:59XX
  X11Forwarding no
  AllowAgentForwarding no
  ForceCommand /bin/false

Ah yes, I guess that works, but it would give me a somewhat uneasy feeling having to always remember that the security depends on no unprivileged user ever being allowed to open random TCP connections.

Not_Oles · August 2025

The goal was to find a simple, secure, and open source method of enabling VPS users to install their own choice of OS plus also start, stop, reboot, and reinstall their VPS.

How could we do it better? While keeping simplicity, security, and open source?

Thanks again for your help! Always appreciated!

FrankCastle · August 2025

@cmeerw said:
Ah yes, I guess that works, but it would give me a somewhat uneasy feeling having to always remember that the security depends on no unprivileged user ever being allowed to open random TCP connections.

I am not exactly sure what you mean. UserX who owns vmX on portX is the only one that can connect to that port. UserY who owns vmY on portY is in the same boat. They aren't random TCP connections, everything is configured and locked down accordingly. Maybe there is some confusion because the match user part was left off above.

Match User fossvpsuser69
  PermitOpen 127.0.0.1:59XX
  X11Forwarding no
  AllowAgentForwarding no
  ForceCommand /bin/false

Had we done this it would be as you describe:

Match User fossvpsuser69
  AllowTcpForwarding yes
  X11Forwarding no
  AllowAgentForwarding no
  ForceCommand /bin/false

But I made certain that we didn't do it that way as it was far too problematic for obvious reasons. Maybe I overlooked something and am not following what exactly you are saying is the problem.

cmeerw · August 2025

@FrankCastle said:

@cmeerw said:
Ah yes, I guess that works, but it would give me a somewhat uneasy feeling having to always remember that the security depends on no unprivileged user ever being allowed to open random TCP connections.

I am not exactly sure what you mean. UserX who owns vmX on portX is the only one that can connect to that port. UserY who owns vmY on portY is in the same boat. They aren't random TCP connections, everything is configured and locked down accordingly. Maybe there is some confusion because the match user part was left off above.
Match User fossvpsuser69
  PermitOpen 127.0.0.1:59XX
  X11Forwarding no
  AllowAgentForwarding no
  ForceCommand /bin/false
Had we done this it would be as you describe:
Match User fossvpsuser69
  AllowTcpForwarding yes
  X11Forwarding no
  AllowAgentForwarding no
  ForceCommand /bin/false
But I made certain that we didn't do it that way as it was far too problematic for obvious reasons. Maybe I overlooked something and am not following what exactly you are saying is the problem.

As I said, I guess it works.

But the uneasy feeling remains. Usually, the idea of running different services as different users is that if you manage to break out of one service (by some kind of remote code execution, e.g., breaking out of your virtual machine by a buffer overflow in a virtio device), you are still severely restricted by what you can do, because you are still confined by that non-root user. But in the case of your set up, you then have the ability of getting console access to other users' VPSes on that system for free - which is more than what I would usually be comfortable with.

FrankCastle · August 2025

@cmeerw said:
As I said, I guess it works.

Like Not_Oles asked, what would you do instead?

But the uneasy feeling remains. Usually, the idea of running different services as different users is that if you manage to break out of one service (by some kind of remote code execution, e.g., breaking out of your virtual machine by a buffer overflow in a virtio device), you are still severely restricted by what you can do, because you are still confined by that non-root user. But in the case of your set up, you then have the ability of getting console access to other users' VPSes on that system for free - which is more than what I would usually be comfortable with.

I certainly agree that a layered security approach would be better. But unless sshd has a vulnerability (in which case you are already screwed from the hypervisor standpoint vs less important vms) I don't see how you can bypass or break out of this setup. If you can prove otherwise I'm certainly all ears and happy to learn something new. I can provide you with a target to compromise/exploit if you are game.

cmeerw · August 2025

@Not_Oles said:
The goal was to find a simple, secure, and open source method of enabling VPS users to install their own choice of OS plus also start, stop, reboot, and reinstall their VPS.

How could we do it better? While keeping simplicity, security, and open source?

Thanks again for your help! Always appreciated!

I was going to suggest generating random passwords that the user would get over the SSH connection, but it seems an easier way to achieve better user separation for VNC would be to use Unix domain sockets - both qemu and SSH already support those (just tried locally); so you just need to make sure that file permissions are set up correctly, so only the owner of the VPS can connect to the corresponding VNC Unix domain socket.

FrankCastle · August 2025

@cmeerw said:
I was going to suggest generating random passwords that the user would get over the SSH connection, but it seems an easier way to achieve better user separation for VNC would be to use Unix domain sockets - both qemu and SSH already support those (just tried locally); so you just need to make sure that file permissions are set up correctly, so only the owner of the VPS can connect to the corresponding VNC Unix domain socket.

Don't you still end up using a ssh tunnel to be able to access the domain socket? Definitely an interesting solution but seems like a very comparable solution and maybe even a tad more work involved to manage it. So if you do still need to use ssh tunnels the attack surface is the same. It seems like it would work though, just not sure how much of an improvement.

cmeerw · August 2025

@FrankCastle said:

@cmeerw said:
I was going to suggest generating random passwords that the user would get over the SSH connection, but it seems an easier way to achieve better user separation for VNC would be to use Unix domain sockets - both qemu and SSH already support those (just tried locally); so you just need to make sure that file permissions are set up correctly, so only the owner of the VPS can connect to the corresponding VNC Unix domain socket.

Don't you still end up using a ssh tunnel to be able to access the domain socket? Definitely an interesting solution but seems like a very comparable solution and maybe even a tad more work involved to manage it. So if you do still need to use ssh tunnels the attack surface is the same. It seems like it would work though, just not sure how much of an improvement.

It's moving from a localhost TCP port (that every process on that machine can connect to) to a Unix domain socket (that only processes with the same user id can connect to, assuming file system permissions are set up accordingly). That seems like an improvement to me.

FrankCastle · August 2025

@cmeerw said:
It's moving from a localhost TCP port (that every process on that machine can connect to) to a Unix domain socket (that only processes with the same user id can connect to, assuming file system permissions are set up accordingly). That seems like an improvement to me.

Fair enough.

Not_Oles · August 2025

@cmeerw

I'm wondering whether it might be possible, if you have time, please, for you to post a hint about how to create a VPS using your idea of a Unix socket for ssh tunnel access to Node localhost VNC.

Previously, I posted what I have been doing to make VPSes without graphics.

Here is the @FrankCastle virt-install method used for the VNC enabled VPS that was paired with this per user ssh configuration.

I don't know if VNC is necessary for every FOSSVPS client, but there are a few who want to install additional excellent operating systems besides those that FOSSVPS offers pre-installed.

cmeerw · August 2025

@Not_Oles said:
@cmeerw

I'm wondering whether it might be possible, if you have time, please, for you to post a hint about how to create a VPS using your idea of a Unix socket for ssh tunnel access to Node localhost VNC.

Previously, I posted what I have been doing to make VPSes without graphics.

Here is the @FrankCastle virt-install method used for the VNC enabled VPS that was paired with this per user ssh configuration.

I don't know if VNC is necessary for every FOSSVPS client, but there are a few who want to install additional excellent operating systems besides those that FOSSVPS offers pre-installed.

I don't know about virt-install, as I have never used it. With qemu, you can just use -vnc unix:/home/user/vnc.socket, and with ssh you can do ssh -L 5901:/home/user/vnc.socket to forward your local port 5901 to that Unix domain socket on the server.

Not_Oles · August 2025

@cmeerw Thanks so much! More simple than I imagined. I will give it a try. Best wishes, and thanks again, as always, for helping so much!

zejjnt · August 2025

@Not_Oles said:

@zejjnt said: I see there are discussions about distributions here; is this node "stuck" with Ubuntu or is it possible to go with Debian?

Hi @zejjnt!

Usually I go for Debian or NetBSD. The Chisinau Node was delivered with Ubuntu. I thought it would be lots of fun to go with Ubuntu since I haven't used it for a while.

You are right that it would be super great for everyone to be able to install whatever open source OS they want. My question is, though, how to arrange universal open source OS install for everyone without using closed source software? Also, there is my own little preference for ssh and command line, much simpler than something like OpenStack.

One idea might be to make netboot.xyz available. I've been talking with @babywhale about adding netboot.xyz to BashVM. Unfortunately, I have almost no experience with netboot.xyz.

Another idea proposed by @FrankCastle is to use limited no-login ssh:

@FrankCastle said: We would still need to solve getting me access to port 5900 (or 590X if you have used vnc graphics for something else but easy to figure out). This is pretty simple with a restricted shell account that can only do port forwarding (no actual permissions for full shell access). Then I can vnc in over a ssh tunnel (so it is encrypted) and install any operating system I want as many times as I want without ever having to bug you.

@zejjnt How would you implement open source OS install freedom on our Node? Thanks!

Hi again!
I am very fond of netboot.xyz (running it at home for PXE booting and on the go in a Medicat setup) but from what I've read here that might not be a simple solution.
It's a niche thing you're doing and I guess maybe there will have to be some customization involved to get a good solution for OS selection.

I would appreciate if you could wipe my instance and install the latest stable Debian 12 when you've got time to spare

Not_Oles · August 2025

Hi @zejjnt!

Is https://cloud.debian.org/images/cloud/bookworm-backports/latest/debian-12-backports-genericcloud-amd64.qcow2 okay?

If you want something else, just post the link, please.

Best!

Tom

Not_Oles · August 2025

@zejjnt

root@alexhost:/var/lib/libvirt/images# wget https://cloud.debian.org/images/cloud/bookworm-backports/latest/debian-12-backports-genericcloud-amd64.qcow2
--2025-08-26 21:15:34--  https://cloud.debian.org/images/cloud/bookworm-backports/latest/debian-12-backports-genericcloud-amd64.qcow2
Resolving cloud.debian.org (cloud.debian.org)... 2001:6b0:19::173, 2001:6b0:19::165, 2001:6b0:19::163, ...
Connecting to cloud.debian.org (cloud.debian.org)|2001:6b0:19::173|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://saimei.ftp.acc.umu.se/images/cloud/bookworm-backports/latest/debian-12-backports-genericcloud-amd64.qcow2 [following]
--2025-08-26 21:15:34--  https://saimei.ftp.acc.umu.se/images/cloud/bookworm-backports/latest/debian-12-backports-genericcloud-amd64.qcow2
Resolving saimei.ftp.acc.umu.se (saimei.ftp.acc.umu.se)... 2001:6b0:19::138, 194.71.11.138
Connecting to saimei.ftp.acc.umu.se (saimei.ftp.acc.umu.se)|2001:6b0:19::138|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 349175808 (333M)
Saving to: ‘debian-12-backports-genericcloud-amd64.qcow2’

debian-12-backports-ge 100%[=========================>] 333.00M  33.8MB/s    in 10s     

2025-08-26 21:15:45 (33.0 MB/s) - ‘debian-12-backports-genericcloud-amd64.qcow2’ saved [349175808/349175808]

root@alexhost:/var/lib/libvirt/images# wget https://cloud.debian.org/images/cloud/bookworm-backports/latest/SHA512SUMS
--2025-08-26 21:21:57--  https://cloud.debian.org/images/cloud/bookworm-backports/latest/SHA512SUMS
Resolving cloud.debian.org (cloud.debian.org)... 2001:6b0:19::165, 2001:6b0:19::173, 2001:6b0:19::163, ...
Connecting to cloud.debian.org (cloud.debian.org)|2001:6b0:19::165|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 6816 (6.7K)
Saving to: ‘SHA512SUMS’

SHA512SUMS             100%[=========================>]   6.66K  --.-KB/s    in 0s      

2025-08-26 21:21:57 (493 MB/s) - ‘SHA512SUMS’ saved [6816/6816]

root@alexhost:/var/lib/libvirt/images# sha512sum -c SHA512SUMS --ignore-missing
debian-12-backports-genericcloud-amd64.qcow2: OK
root@alexhost:/var/lib/libvirt/images#

Not_Oles · August 2025

@zejjnt Okay to proceed? I want you to have everything exactly right. Or as close to exactly right as we can get.

Thanks to @alexhost Alexhost for donating our nice server Node!

zejjnt · August 2025

@Not_Oles said:
@zejjnt Okay to proceed? I want you to have everything exactly right. Or as close to exactly right as we can get.

Thanks to @alexhost Alexhost for donating our nice server Node!

Absolutely, just flatten and reinstall

Not_Oles · August 2025

@zejjnt

Reinstalled to Debian 12!

You should be able to get in with your ssh key. Password login is not enabled. My ssh keys are present so I could test. Please feel free to remove them.

Please post here about your progress with your VPS. I look forward to hearing about what you are doing!

Thanks to Alexhost for the nice server node!

Best wishes!

Tom

imranex · December 2025

@Not_Oles said:

@imranex said:
Can you please PM me free VPS details? I'm going to host my portfolio website on this. 🙂

Hi @imranex!

Thanks for asking!

We can do something as soon as your profile shows a little more discussion and comment history.

Best wishes!

Tom

Hey Tom,
Is it alright now? Can we get this?

hugo_sabdo · December 2025

Hello FOSSVPS team and generous providers, thank you for making this possible ❤️

Open source software plan

I plan to run Technitium DNS Server in a non-commercial and private setup.
The VPS will be used to test DNS resolution, caching behavior, and DNS-based filtering from an Eastern Europe location.

The service will be configured safely:

Private resolver only (no open resolver)
Running on non-standard ports
DNS-over-HTTPS (DoH) for testing purposes
Strict firewall and access controls

Community contribution

I hope to contribute positively by:

Sharing configuration notes and best practices for running Technitium DNS securely
Providing feedback about latency, routing, and DNS performance from the Moldova region
Participating in discussions and helping other community members where possible

All usage will remain white-hat, open source, and strictly non-commercial.

Preferred location

Alexhost – Chisinau, Moldova

This location is interesting for testing Eastern Europe DNS latency and comparing it with other regions.

IP preference

NAT IPv4 is perfectly fine for my use case.

SSH public key (ed25519)

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINFX1Dud/kwUKjiR1d8m1Y9PKdwhCxXWnGKGijBlweTm hugo@fossvps

Thank you again to FOSSVPS and the providers for supporting open-source projects and the community.

msatt · December 2025

Hi @hugo_sabdo this thread is old and @Not_Oles has passed FOSSVPS over to me and my team.
Head over to the link in my signature and you can complete the registration form.
Moldova is available (till 30th January 2026) but we have different locations to choose from.
Your profile on LET is not the best however your thorough description of what you wish to do gives you bonus points

hugo_sabdo · December 2025

Hi @msatt,

Just a quick update — I attempted to complete the registration form yesterday using my personal domain email (not Gmail). Unfortunately, the verification email arrived too late and the OTP had already expired.

When I tried again this morning, the system flagged it as a multiple registration attempt.
I just wanted to clarify that this was not intentional and was caused by the delayed verification email.

Please let me know if there is anything I should do next, or if I should simply wait.
Thank you for your understanding.

msatt · December 2025

Thanks for letting us know, that is correct functionality, just FYI - checking logs,
You requested at 2025-12-22 10:00:20 and the verification email was sent 22/12/2025 10:00:22
So the delay looks like at your end.
At the moment your profile on LET is not high enough to qualify (I am sorry), we need to see a history. So feel free to re-apply when you have participated more in this forum and we will happily review your request again.
Wishing you well.
Mike

Racel · January 24

Thank you for kindly reward for developers who made open source softwares!

Howdy, Stranger!

Categories

In this Discussion

New Free VPS Location! Alexhost, Chisinau, Moldova via FOSSVPS!

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

New Free VPS Location! Alexhost, Chisinau, Moldova via FOSSVPS!

Comments