Thomas Letan's Blog - self-hosting

I Cannot SSH Into My Server Anymore (And That’s Fine)

January 5, 2026

I Cannot SSH Into My Server Anymore (And That’s Fine)

I would like to thank Yann Régis-Gianas, Sylvain Ribstein and Paul Laforgue for their feedback and careful review.

To kick off 2026, I had clear objectives in mind: decommissioning moana, my trusty $100+/month VPS, and setting up tinkerbell, its far less costly successor.

On the one hand, I have been using moana to self-host a number of services, and it was very handy to know that I had always a go-to place to experiment with whatever caught my interest. On the other hand, $100/month is obviously a lot of money, and looking back at how I used it in 2025, it was not particularly well spent. It was time to downsize.

Now that tinkerbell is up and running, I cannot even SSH into it. In fact, nothing can.

There is no need. To update one of the services it hosts, I push a new container image to the appropriate registry with the correct tag. tinkerbell will fetch and deploy it. All on its own.

In this article, I walk through the journey that led me to the smoke and mirrors behind this magic trick: Fedora CoreOS , Ignition and Podman Quadlets in the main roles, with Terraform as an essential supporting character. This stack checks all the boxes I care about.

Note

For interested readers, I have published tinkerbell’s full setup on GitHub. This article reads as an experiment log, and if you are only interested in the final result, you should definitely have a look.

Container-Centric, Declarative, and Low-Maintenance

Going into this, I knew I didn’t want to reproduce moana’s setup—it was fully manualIn the end, I never took the time to publish a write-up about it, so in a nutshell: everything relied on a small script that enabled me to create interconnected nspawn containers on the spot. and I no longer have the time or the motivation to fiddle with the internals of a server. Instead, I wanted to embrace the principles my DevOps colleagues had taught me over the past two years.

My initial idea was to start with this very website, since it was the only service deployed on moana that I really wanted to keep. Since I had written a container image for this website, I just had to look for the most straightforward and future-proof way to deploy it in production™— something I could later extend to deploy more cool projects, if I ever wanted toIf my goal was limited to host a static website, this whole setup would arguably be both overengineered and counterproductive. tinkerbell was to become my little foothold in the Internet, though. My “cloud homelabs,” of sorts. .

Docker Compose alone wasn’t a good fit. I like compose files, but one needs to provision and manage a VM to host them. Ansible can provision VMs, but that road comes with its own set of struggles. Writing good playbooks has always felt surprisingly difficult to me. In particular, a good playbook is supposed to handle two very different scenarios—provisioning a brand new machine, and updating a pre-existing deployment—and I have found it particularly challenging to ensure that both paths reliably produce the same result.

Kubernetes was very appealing on paper. I have seen engineers turn compose files into Helm charts and be done with it. If I could do the same thing, wouldn’t that be bliss? Unfortunately, Kubernetes is a notoriously complex stack, resulting from compromises made to address challenges I simply don’t face. Managed clusters could make things easier, but they aren’t cheap. That would defeat the initial motivation behind retiring moana.

CoreOS , being an operating system specifically built to run containers, obviously stood out. That said, I had very little intuition on how it could work in practice. So I started digging. I learned about Ignition first. Its purpose is to provision a VM exactly once, at first boot. If you need to change something afterwards, you throw away your VM and create a new one. This may seem counter-intuitive, but since it eliminates the main reason I was looking for an alternative to Ansible, I was hookedCoreOS and Ignition enable me to think about virtual machines the same way OCaml or Haskell trained me to think about data: as immutable values. .

I found out how to use systemd unit files to start containers via podman CLI commands. That was way too cumbersome, so I pushed on for a way to orchestrate containers à la Docker Compose. That’s when I discovered Podman Quadlets and auto-updates .

With that, everything clicked. I knew what I wanted to do, and I was very excited about it.

Assembling `tinkerbell`

For more than a year now, my website has been served from RAM by a standalone, static binary built in OCaml, with TLS termination handled by Nginx and certbot’s certificates renewal performed by yours trulyI didn’t lie when I said moana’s setup was indeed manual. . I didn’t have any reason to fundamentally change this architecture. I was simply looking for a way to automate their deployment.

Container-Centric, …

The logical thing to do was to have tinkerbell run two containers:

The reverse proxy: I had been firmly on Team Nginx for years now, but when I heard Caddy could “automatically obtain and renew TLS certificates,” I was sold on giving it a try.
The website itself: Static binaries can be wrapped inside a container with close to zero overhead using the scratch base image, so I did just that. I published it to a free-plan, public registry hosted on Vultr that I created for the occasionWhich means getting an offline copy of this website is now as simple as calling docker pull ams.vultrcr.com/lthms/www/soap.coffee:live. .

Nothing beats a straightforward architecture

Nothing fancy or unexpected here, which made it a good target for a first deployment. It was time to open Neovim to write some YAML.

Declarative, …

At this point, the architecture was clear. The next step was to turn it into something a machine could execute. To that end, I needed two things: first an Ignition configuration, then a CoreOS VM to run it.

The Proof of Concept

Ignition configurations (.ign) are JSON files primarily intended to be consumed by machines. They are produced from YAML files using a tool called Butane . For instance, here is the first Butane configuration file I ended up writing. It provisions a CoreOS VM by creating a new user (lthms), along with a .ssh/authorized_keys file allowing me to SSH into the VMI didn’t know at the time that I would deliberately remove these lines from the final Butane file. .

variant: fcos
version: 1.5.0
passwd:
  users:
    - name: lthms
      ssh_authorized_keys:
        - ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKajIx3VWRjhqIrza4ZnVnnI1g2q6NfMfMOcnSciP1Ws lthms@vanellope

What’s important to keep in mind is that Ignition runs exactly once, at first boot. Then it is never used again. This single fact has far-reaching consequences, and is the reason why any meaningful change implies replacing the machine, not modifying it.

Before going any further, I wanted to understand how the actual deployment was going to work. I generated the Ignition configuration file.

butane main.bu > main.ign

Then, I decided to investigate how to define the Vultr VM in Terraform. The resulting configuration is twofold. First, we need to configure Terraform to be able to interact with the Vultr API, using the Vultr provider . Second, I needed to create the VM For discovering what values to put in most fields, vultr-cli is pretty convenient. Kudos to the Vultr team for making it in the first place. and feed it the Ignition configuration.

resource "vultr_instance" "tinkerbell" {
  region = "cdg"
  plan = "vc2-1c-1gb"
  os_id = "391"

  label = "tinkerbell"
  hostname = "tinkerbell"

  user_data = file("main.ign")
}

And that was it. I invoked terraform apply, waited for a little while, then SSHed into the newly created VM with my lthms user. Sure enough, the tinkerbell VM was now listed in the Vultr web interface. I explored for a little while, then called terraform destroy and rejoiced when everything worked as expected.

The MVP

At this point, I was basically done with Terraform, and I just needed to write the Butane configuration that would bring my containers to life. As I mentioned earlier, the first approach I tried was to define a systemd service responsible for invoking podman.

systemd:
  units:
    - name: soap.coffee.service
      enabled: true
      contents: |
        [Unit]
        Description=Web Service
        After=network-online.target
        Wants=network-online.target

        [Service]
        ExecStart=/usr/bin/podman run \
          --name soap.coffee \
          -p 8901:8901 \
          --restart=always \
          ams.vultrcr.com/lthms/www/soap.coffee:latest
        ExecStop=/usr/bin/podman stop soap.coffee

        [Install]
        WantedBy=multi-user.target

Adding this entry in my Butane configuration and redeploying tinkerbell got me exactly what I wanted. My website was up and running. For the sake of getting something working first, I added the necessary configuration for Caddy (the container and the provisioning of its configuration file), redeployed tinkerbell again, only to realize I also needed to create a network so that the two containers could talk together. After half an hour or so, I got everything working, but was left with a sour taste in my mouth.

This would simply not do. I wasn’t defining anything, I was writing a shell script in the most cumbersome way possible.

Then, I remembered my initial train of thought and started to search for a way to have Docker Compose work on CoreOSWell, Podman Compose, I guess. . That is when I discovered Quadlet, whose initial repository does a good job justifying its existence This repository is now archived, since Quadlet has got merged upstream. . In particular,

With quadlet, you describe how to run a container in a format that is very similar to regular systemd config files. From these actual systemd configurations are automatically generated (using systemd generators ).

To give a concrete example, here is the .container file I wrote for my website server.

[Container]
ContainerName=soap.coffee
Image=ams.vultrcr.com/lthms/www/soap.coffee:live

[Service]
Restart=always

[Install]
WantedBy=multi-user.target

I wasn’t wasting my time teaching systemd how to start containers anymore. I was now declaring what should exist, so that systemd—repurposed for the occasion as a container orchestrator—could take care of the rest.

Tip

If your containers are basically ignored by systemd, be smarter than me. Do not try to blindly change your .container files and redeploy your VM in a very painful and frustrating loop. Simply ask systemd for the generator logs.

sudo journalctl -b | grep -i quadlet

I excitedly turned caddy.service into caddy.container, redeployed tinkerbell, ran into the exact same issue I had encountered before and discovered the easiest way for two Quadlet-defined containers to talk to each other was to introduce a pod . Unlike Docker Compose which uses DNS over a bridge network, a pod shares the network namespace, allowing containers to communicate over localhost.

To define a pod, one needs to create a .pod file, and to reference it in their .container files using the PodName= configuration option. A “few” redeployments later, I got everything working again, and I was ready to call it a day.

And with that, tinkerbell was basically ready.

Caution

I’ve later learned that restarting a container that is part of a pod will have the (to me, unexpected) side-effect to restart all the other containers of that pod.

And Low-Maintenance

Now, the end of the previous section might have given you pause.

Even a static website like this one isn’t completely “stateless.” Not only does Caddy require a configuration file to do anything meaningful, but it is also a stateful application as it manages TLS certificates over time. Besides, I do publish technical write-ups from time to timeTwo in 2025, that’s true. But 2026 is only starting, you never know what might come! .

Was I really at peace with having to destroy and redeploy tinkerbell every time I need to change anything on my website?

On the one hand, yes. I believe I could live with that. I modify my website only a handful of times even in good months, I think my audience could survive with a minute of downtime before being allowed to read my latest pieces. It may be an unpopular opinion, but considering my actual use case, it was good enough. Even the fact that I do not store the TLS certificates obtained by Caddy anywhere persistent should not be an issue. I mean, Let’s Encrypt has fairly generous weekly issuance limits per domain How do I know that? Well... I might have hit the limit while hacking my way to a working setup. . I should be fine.

On the other hand, the setup was starting to grow on me, and I have other use cases in mind that could be a good fit for it. So I started researching again, this time to understand how a deployment philosophy so focused on immutability was managing what seemed to be conflicting requirements.

I went down other rabbit holes, looking for answers. The discovery that stood out the most to me—to the point where it became the hook of this article—was Podman auto-updates.

To deploy a new version of a containerized application, you pull the new image and restart the container. When you commit to this pattern, why should you be the one performing this action? Instead, your VM can regularly check registries for new images, and update the required containers when necessary.

In practice, Podman made this approach trivial to put in place. I just needed to label my containers with io.containers.autoupdate set to registry, enable the podman-auto-update timerBy default, the timer is triggered once a day, which felt unnecessarily long, so I decided to make it hourly instead. , and that was it. Now, every time I update the tag www/soap.coffee:live to point to a newer version of my image, my website is updated within the hour.

And that is when the final piece clicked. At this point, publishing an image becomes the only deployment step. I didn’t need SSH anymore.

The Road Ahead

tinkerbell has been running for a few days now, and I am quite pleased with the system I have put in place. In retrospect, none of this is particularly novel. It feels more like I am converging toward a set of practices the industry has been gravitating toward for years.

A man looking at the “CoreOS & Quadlets” butterfly and wondering whether he’s looking at Infrastructure as Code. I’m not entirely sure of the answer.

The journey is far from being over, though. tinkerbell is up and running, and it served you this HTML page just fine, but the moment I put SSH out of the picture, it became a black box. Aside from some hardware metrics kindly provided by the Vultr dashboard, I have no real visibility into what’s going on inside. That is fine for now, but it is not a place I want to stay in forever. I plan to spend a few more weekends building an observability stackOh, and maybe I will move these TLS certificates in a block storage or something. That could be a good idea. . That will come in handy when things go wrong—as they inevitably do. I would rather have the means to understand failures than guess my way around them.

Did I ever mention I am an enthusiastic Opentelemetry convert?

Installing a LUKS-Encrypted Arch Linux on a Vultr VPS

February 25, 2024

Installing a LUKS-Encrypted Arch Linux on a Vultr VPS

self-hosting vultr

I’ve been a happy customer of Vultr for three years now. For one, this little corner of the Internet is hosted on one of their VPS, along with other services I have self-hosted. Recently, I have decided to migrate to a new VPS with more disk space and more powerful vCPUs.

In this article, I describe how I have set up the host (an Arch Linux system on a LUKS-encrypted partition) of jasminejasmine being my shiny new server—I have taken the habit to name my servers and personal computers after Disney princesses. . I had done a similar thing for mulan, jasmine’s predecessor. Unfortunately, I didn’t take the time to document mulan installation steps three years ago. Needless to say, I had plenty of opportunities to regret this oversight while I painfully redicovered how to make this work.

Hopefully, most of what is in this write-up will stand the test of time and remain true three years from now, when I migrate again 😅.

Booting on the Installation ISO

It is no surprise that Vultr does not propose an out-of-the-box LUKS-encrypted Arch Linux installation in their OSes library. As a consequence, I had to boot my brand new VPS on the Arch Linux ISO .

In the Vultr dashboard, I visited the “ISOs” page (in the “Orchestrations” menu) to add the latest Arch Linux installation ISO.
Then, I went to the management panel of jasmine, more precisely in the “Settings” tab. I visited the “Custom ISO” page, and attached the Arch Linux ISO. This prompted a reboot.

jasmine happily booted the image, but the resulting system was lacking a SSH server to connect to. Instead, I used the “View Console” feature to get a shell access to my VPSIt is noteworthy that I had to disable one of my Firefox extensions: Vimium. Vimium provides me vim-like keystrokes in the browser, and the keys I am using for motion (t, s, r, and n) were not forwarded to the console. .

The Arch Linux installation ISO’s default keymap is qwerty, a keyboard layout I am helpless with. The first command I always use in this situation is loadkeys, which allows me to switch to the fr-bepo layout.

Note

In this article, I am using ; as the terminal prompt for ease of copy/pasting .

; loadkeys fr-bepo

Remote Access to `jasmine`

The next step was to start a SSH server I could connect to using my terminal emulator. A virtual console is nice enough, but when your muscle memory commands you to hit Ctrl-W to delete the word before your cursor as soon as you are connected to a shell, you don’t want to stay in a browser tab for obvious reasons.

I set up a password for the root user using passwd.
I modified the /etc/ssh/sshd_config file to let me connect with the root user using a password (PermitRootLogin yes).
I started the SSH server using systemctl start sshd.

From there, I could connect jasmine from my terminal emulator.

# after modifying /etc/hosts to add `jasmine` IP there
; ssh root@jasmine

Disk Partitions

Now that I was enjoying the comfort of my terminal emulator of choice (kitty ), the serious business could start. Moving forward, my next task was to set up the disk layout and the filesystems.

Warning

Did you know that Vultr VPS are using legacy boot and not UEFI? I surely did, three years ago, but sadly I had forgotten. So I did a first installation setup with a EFI partition layout (GPT, /boot formatted with VFAT, etc.), only to discover that my shiny system could not boot.

To create an MBR partition system, fdisk is a nice enough tool. The disk is exposed to the VPS under the name /dev/vda.

; fdisk /dev/vda

Firstly, I created a new MBR.

Command (m for help): o

Then, I created the /boot partition. To be sure I would not run out of space, I allocated 3GBytes for it.

Command (m for help): n
Partition number (1-128, default 1): 
First sector (34-268435422, default = 2048) or {+-}size{KMGTP}: 
Last sector (2048-268435422, default = 268433407) or {+-}size{KMGTP}: +3G

The root partition was to take the remaining space.

Command (m for help): n
Partition number (2-128, default 2): 
First sector (34-268435422, default = 6293504) or {+-}size{KMGTP}: 
Last sector (6293504-268435422, default = 268433407) or {+-}size{KMGTP}:

I reviewed the resulting partition layout.


Command (m for help): p

Disk /dev/vda: 128 GiB, 137438953472 bytes, 268435456 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xdbc3620d

Device     Boot   Start       End   Sectors  Size Id Type
/dev/vda1          2048   6293503   6291456    3G 83 Linux
/dev/vda2       6293504 268435455 262141952  125G 83 Linux

LGTM!

Command (? for help): w

Filesystems

`/boot` Partition

No need to be particularly fancy here. I formatted /boot with the ext3 filesystem. As far as I know, this is a reasonable default choice for this partition.

; mkfs.ext3 /dev/vda1

LUKS-Encrypted Root Partition

I mostly followed the Arch Linux Wiki for this. Generally speaking, the Arch Linux Wiki is a wonderful source of information for anything related to Linux.

I formatted /dev/vda2 with cryptsetup to initialize the encryption scheme.

; cryptsetup -y -v luksFormat /dev/vda2

Important

Be sure to save your LUKS passphrase somewhere, otherwise you are likely to run in trouble at some point. I’ve personally added it to my Bitwarden.

As-is, the partition cannot be used; it needs to be “open” with cryptsetup.

; cryptsetup open /dev/vda2 root

root here is the name given to the usable partition. More precisely, after this command the partition can be manipulated through the /dev/mapper/root logical volume.

Before, I had always used ext4 for my root partition, but for a while I’ve had an interest for alternative filesystems. And so, I decided out of the blue to format /dev/mapper/root with btrfsTime will tell if this was a mistake… The Internet seems to suggest it might be one 😅. . I like the idea of a filesystem compressing its contents by default.

; mkfs.btrfs -d single -m single /dev/mapper/root
; mount -t btrfs -o defaults,noatime,compress=zstd /dev/mapper/root /mnt

Finally, I could mount the two formatted partitions in /mnt.

; mkdir /mnt/boot
; mount /dev/vda1 /mnt/boot

Installing Arch Linux

I have installed the bare minimum with pacstrap. I personally prefer entering in the chroot as soon as possible.

; pacstrap -K /mnt base linux
; genfstab -U /mnt >> /mnt/etc/fstab
; arch-chroot /mnt

In the rest of the article, I focus on the details that are directly related to our main subject. That is, being able to boot a LUKS-encrypted Arch Linux VPS. To that end, I have chosen to reproduce the exact setup I did three years ago for mulan. It consists in configuring the initramfs to spawn an SSH server (tinyssh ) which let me enter the LUKS passphrase of /dev/vda2 remotely.

`sshd`

Before configuring the boot process, it had to take a small detour and configure the SSH server (sshd from OpenSSH) jasmine will start once it has booted. The main reason is quite simple: I wanted tinyssh and sshd to use the same host key.

tinyssh is limited in terms of the key types it supports, but I personally always default to Ed25519 so I’m fine with that.

ssh-keygen -f /etc/ssh/ssh_host_ed25519_key -N '' -t ed25519

I then modified /etc/ssh/sshd_config to ensure sshd would default to it.

# in /etc/ssh/sshd_config, uncomment
HostKey /etc/ssh/ssh_host_ed25519_key

I used this opportunity to also (temporarily) allow login as root using a password. Eventually, I will definitely remove this line from sshd config, but while I’m configuring everything, it’s too convenient to bother with another approach.

# in /etc/ssh/sshd_config, add
PermitRootLogin yes

This line is only useful if root has a password, so I initialized one.

; passwd

I also enabled the sshd service, to let systemd start sshd automatically at boot time.

; systemctl enable sshd

TinySSH

At this point, I knew I had only dealt with the easy bits. The hard part is to be able the damn thing.

I have always used Busybox-based initial ramdisk. While rereading the Arch Linux Wiki, I discovered it was also possible to use systemd, which… well, nobody is surprised by this, I guess. I am a happy adopter of systemd multiple features in general, but for the particular setup I am targeting, using systemd means installing an AUR package . So I decided to stick with Busybox.

I gathered and installed the packages I needed for this to work.

; pacman -S tinyssh mkinitcpio-tinyssh mkinitcpio-netconf mkinitcpio-utils python3

And I modified /etc/mkinitcpio.conf to modify the HOOKS array.

-HOOKS=(base udev autodetect modconf kms keyboard keymap consolefont block filesystems fsck)
+HOOKS=(base udev autodetect modconf block netconf tinyssh encryptssh filesystems keyboard keymap fsck)

I tried to keep it minimal (hence the removal of kms for instance, which does not seem very useful for a remote server considering its about setting display resolution), and I borrowed from the /etc/mkinitcpio.conf file of mulan for netconf, tinyssh and encryptssh.

Turns out mkinitcpio-tinyssh is affected by a long standing bug , but fortunately the patch to /usr/lib/initcpio/install/tinyssh worked like a charm.

   local return_code=1
 
   if [ ! -d $destdir -a -x /usr/bin/tinyssh-convert ]; then
-      mkdir $destdir
-  fi
-  
-  if [ -s "$osshed25519" -a ! -s $destdir/.ed25519.sk -a ! -s $destdir/ed25519.pk -a -x /usr/bin/tinyssh-convert ]; then
-      tinyssh-convert -f $osshed25519 -d $destdir
+      tinyssh-convert $destdir < $osshed25519
       if [ $? -eq 0 ]; then
           return_code=0
       fi

On my local machine, I generated a brand new SSH key using the Ed25519 key type.

; ssh-keygen -t ed25519 -f jasmine

I copy/pasteed the content of jasmine.pub in /etc/tinyssh/root_key on jasmine. It was also a good idea to delete the etc/tinyssh/sshkeydir directory, before running the command to generate the initial ramkdisk.

; mkinitcpio -p linux

Grub

This is your periodic reminder that Vultr does not support UEFI and still requires to the legacy MBR to boot. This means systemd-boot is out of the picture. I always feel overwhelmed when i have to configure Grub. However, three years ago I managed to make it work, so I decided to stick to this again.

; pacman -S grub
; grub-install --target=i386-pc /dev/vda
; grub-mkconfig -o /boot/grub/grub.cfg

/boot/grub/grub.cfg contains a lot of things. I looked for the line

### BEGIN /etc/grub.d/10_linux ###

In the first menuentry after it, I modified one lineMy initial thought was to install the intel-ucode package, and to configure Grub to load Intel’s microcode upgrades at boot time. However, since jasmine is a VPS, it does not directly access the physical CPU it is running onto. As a consequence, this step is not necessary. .

First, the linux line.

        linux   /vmlinuz-linux root=/dev/mapper/root rw cryptdevice=UUID=7e58f868-529
a-4d70-bdfd-31317017c30b:root ip=<server ip>::<server gateway>:<server netmask>::eth0:none logle
vel=3 quiet

The one is the most tricky.

root=/ev/mapper/root rw is the most straightforward. It means the root filesystem in located in /dev/mapper/root, that is a logical volume.
cryptdevice=UUID=7e58f868-529a-4d70-bdfd-31317017c30b:root tells the kernel that the root logical volume is inside the encrypted (cryptdevice) /dev/vda2 partition. To get the UUID of /dev/vda2, I used blkid.

; blkid | grep UUID
/dev/mapper/root: UUID="0a44e4c7-10b7-4e85-8228-7663cf16a631" UUID_SUB="0c9edc1c-31c0-417d-93e2-6f035c68b7cb" BLOCK_SIZE="4096" TYPE="btrfs"
/dev/vda2: UUID="e9695de0-403c-4a6c-b8a2-9891dca2a60a" TYPE="crypto_LUKS" PARTUUID="dbc3620d-02"
/dev/vda1: UUID="fa7a24d2-fc76-4af2-b26c-58548650253f" BLOCK_SIZE="4096" TYPE="ext3" PARTUUID="dbc3620d-01"

ip=<server ip>::<server gateway>:<server netmask>::eth0:none tells the kernel enough information for tinyssh to be accessible from the Internet. These three IPS can be found in the “Settings” tab of jasmine management panel in the Vultr dashboard.

Networking

There was only one step remaining before rebooting jasmine without the installation ISO attached: configuring the system to ensure remote access. In practice, it means enabling DHCP for the Ethernet interface (named ens3 in jasmine’s case).

I did that by defining a .network unit in /etc/systemd/networkd to enable DHCP so that jasmine can get its ip from Vultr DHCP server.

# /etc/systemd/network/50-ens3.network
[Match]
Name=ens3

[Network]
DHCP=yes

As a last touch, I enabled both systemd-networkd and systemd-resolved.

; systemctl enable systemd-networkd
; systemctl enable systemd-resolved
; ln -sf ../run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

And I was good to go!

I exited the chroot, came back to Vultr dashboard to detach the custom ISO from jasmine, which prompted a reboot of the VPS. A look a the virtual console was enough to confirm tinyssh had started and was waiting for incoming connection. I edited my ~/.ssh/known_hosts to remove jasmine now out-dated line, and tried to connect to jasmine. tinyssh asked me kindly the passphrase for /dev/vda1, before closing the connection.

A new attempt at connection to jasmin using SSH led me to the expected system. Hourray!

Conclusion

Needless to say, while this article is meant to propose a linear story to its readers, my personal journey was everything but. I had to reboot many times into the installation ISO, to mount my root partition and tweak the configuration until it finally worked.

Hopefully, this article lists the various pitfalls I ran into, and how I fixed them. It’ll be helpful for Future Me, and maybe to you before that.

Thomas Letan's Blog - self-hosting

I Cannot SSH Into My Server Anymore (And That’s Fine)

I Cannot SSH Into My Server Anymore (And That’s Fine)

Container-Centric, Declarative, and Low-Maintenance

Assembling tinkerbell

Container-Centric, …

Declarative, …

The Proof of Concept

The MVP

And Low-Maintenance

The Road Ahead

Installing a LUKS-Encrypted Arch Linux on a Vultr VPS

Installing a LUKS-Encrypted Arch Linux on a Vultr VPS

Booting on the Installation ISO

Remote Access to jasmine

Disk Partitions

Filesystems

/boot Partition

LUKS-Encrypted Root Partition

Installing Arch Linux

sshd

TinySSH

Grub

Networking

Conclusion

Assembling `tinkerbell`

Remote Access to `jasmine`

`/boot` Partition

`sshd`