Getting into a guest

A guest is deployed and running. Now you need a shell in it.

There are two ways in, and they fail independently — which is the whole reason to know both. SSH depends on the network, the firewall and a key having reached the guest. The serial console depends on none of those, which makes it the tool for the day the network is the problem.

The serial console

hoster vm console web-01
hoster microvm console registry

serial is an alias for console. Ctrl+] detaches and returns you to the host shell; your local terminal is restored when the guest disconnects or you detach.

This is a real serial connection to the guest, not a network session. It works when the guest has no address, when you have just broken its firewall rules, and when it is sitting at a boot prompt — the three situations where SSH is not going to help you.

Logging in without knowing the password

hoster vm console web-01 --autologin
hoster microvm console registry --autologin

--autologin sends the guest’s stored root credentials to the console before handing you the session. It is the fastest way into a guest you did not personally set up, and it works precisely because Hoster generated those credentials itself.

The credentials you were never shown

When a guest is deployed, cloud-init configuration is generated for it, and that includes two autogenerated passwords — one for the default user and one for root. They are stored in the guest’s configuration, not printed at deploy time.

hoster vm get-config web-01

The cloud_init block holds them:

get-config prints passwords in clear text. That is what makes --autologin possible, and it means the output of get-config is a secret. Do not paste it into a ticket, and think twice before piping it somewhere that keeps logs.

The default username gwitsuper is a holdover from the platform’s origins. Expect it on guests deployed from stock templates.

SSH

Once the guest is up and reachable, SSH is ordinary:

hoster vm info web-01              # find the address
ssh gwitsuper@web-01.hoster.lan    # if the bridge has a search domain

The name works when the guest’s bridge carries a DNS search domain — see DNS and the WireGuard mesh. Without one, use the address.

Reaching a guest from outside the host is a firewall question, not an SSH question: publish it with a DNAT rule, or reach it over the mesh from another node. See Firewall.

Where keys come from

Two sources, merged when cloud-init is rendered:

• Global host keys — kept in the host configuration, and folded into every guest rendered on that host. A key with enabled: false is skipped, which is how a key is retired without being deleted.
• Per-guest keys — attached to one guest only.

The merged result is what lands in the guest, installed for both the default user and root.

You get one of these for free. The installer generates an ed25519 keypair for the node at /root/.ssh/id_ed25519 and registers the public half as a global key, so ssh from the node into its own guests works from the first deploy without anyone configuring anything.

Adding your own key has no CLI. HosterLib has GetHostSshKeys and HostSetSshKeys, and the API and Control Center reach them, but no hoster command does — there is no hoster host ssh-key tree and no per-guest equivalent. Adding a key from a terminal means editing the host configuration JSON by hand and regenerating cloud-init, or using Control Center.

So the out-of-the-box story is SSH from the node works, SSH from your laptop needs a key you cannot add from the CLI. Worth knowing before you build a node and expect to script your way to access from elsewhere.

Keys reach a guest at cloud-init time

Adding a key does not push it into a running guest. Cloud-init renders the key set when it runs, so an existing guest needs its configuration regenerated and a reboot:

hoster vm ci-reset web-01

See Changing a guest after deploy for what else ci-reset touches — it is the same command that rotates addresses, so read what it does before running it on something in production.

When you cannot get in at all

In order, cheapest first:

1. Is it running? hoster vm list — a stopped guest refuses everything.
2. Use the console. It bypasses the network entirely. If the console works and SSH does not, the problem is networking, and you have just halved the search.
3. Does it have an address? hoster vm info <name>.
4. Is the firewall in the way? hoster firewall vm list <name>, and hoster firewall show for what is actually generated.
5. Does it resolve? See when names do not resolve.
6. Are the keys actually in the guest? hoster vm get-config <name> shows the rendered ssh_keys — if a key you added is not there, cloud-init has not re-run.

Next

• Restoring a guest — when getting in is not the problem, and the guest itself needs to go back to how it was.
• Changing a guest after deploy — ci-reset, and the rest of what can be changed on a running fleet.
• Firewall — publishing SSH, and the rules that quietly prevent it.
• Troubleshooting a node — when it is not the guest that is broken.