Node.Town VM Service

This repository defines a system that spawns virtual machines.

It has an SSH server that authenticates with GitHub public keys and grants access to freshly booted Firecracker computers with Alpine Linux.

Project A

Run SSH server in Systemd

Run Firecrackers in Systemd

Use Alpine base disk image clones

Project B

Install lolcat in Alpine

Set up the Charm Cloud

Ensure llm works everywhere

Provide shells via web

Go server at https://less.rest/

Login with GitHub

List user VMs

Xterm per VM with ttyd

Provide shells via Telegram

Clustering

Git repositories

Bridged networks

Erlang/OTP clustering

Restless CGI

Speech

VNC

QEMU Computers

We can offer disk images for local QEMU virtual machines.

It’s possible that the root image we’re using for Firecracker simply works with QEMU?

Claude’s Audit

Here are some initial security observations and recommendations for your ssh server and VM setup:

1. You’re using public key authentication from GitHub, which is good. However, you should validate the GitHub username matches the SSH username to prevent someone from authenticating as any user if they add a public key to any GitHub account.
2. You allow password auth but always return false. Consider removing the PasswordAuth option entirely to be more explicit that passwords are not allowed.
3. Be careful allowing unrestricted access to run VMs. A malicious user could potentially escape the VM. Consider strict resource limits and isolation.
4. The mkfire script downloads the Alpine rootfs over HTTP without verification. Use HTTPS and validate the checksum to ensure integrity.
5. The mkfire script allows overwriting existing VM directories, which could allow one user to interfere with another’s VM. Ensure strict separation between users.
6. Ensure the guest VM networking is properly isolated using iptables rules or a restricted bridge. Users shouldn’t be able to access the host or other VMs.
7. Validate and sanitize the GUEST_USER and quid values passed in environment variables to prevent command injection.
8. Restrict the host directories the VM can access with –chroot-base-dir in firecracker and bind mounts.
9. Consider AppArmor or SELinux profiles to further restrict the VM processes.
10. Ensure you rotate SSH host keys and keep Firecracker and the Alpine rootfs up-to-date with security patches.
11. Log VM creation, access and destruction events for auditing.
12. Have a plan to monitor for and deal with abuse, such as mining or illegal content hosted in VMs.

Overall, the SSH and VM setup look fairly well isolated, but testing and hardening is recommended, especially around networking and host access from the guest. An in-depth security review would be prudent before allowing access to untrusted users.