Browser console: when to use it and how it differs from SSH

The Console tab in your service panel opens a browser-based serial console attached directly to your VM's display. It's what saves you when SSH stops working — kernel panics, broken sshd config, firewall rules that lock you out, networking changes that orphan your access. This article covers when to reach for it, when not to, and the practical things to know once you're in.

What it is

A token-authenticated noVNC session that opens in a new browser tab. It's wired to the VM's video output the same way a physical monitor would be — you see the GRUB boot menu, the kernel boot messages, single-user mode prompts, anything that's on the screen. No client install, no SSH key, no network path inside the VM.

That last point matters: the console works even when the guest's network is broken. SSH needs a working network stack inside the VM; the console doesn't.

When to use it

• SSH is broken. Bad sshd_config change, the daemon won't restart, you locked yourself out with PasswordAuthentication no and lost your key, etc.
• Firewall lockout. You enabled UFW or nftables, missed adding port 22, and the rule took effect. The console doesn't care about your firewall.
• Watch the boot. The VM seems hung or is taking a long time to come up. The console shows kernel messages, fsck progress, init scripts, anything happening on the way up.
• Kernel panic. The VM is up in the hypervisor's view but unreachable. The console shows the panic stack — often the only diagnostic available.
• Single-user mode / recovery. Some recovery operations need a real terminal at the boot menu (passing kernel parameters, dropping to single-user). The console is the only way to get to GRUB.
• Networking misconfiguration. You changed the IP and rebooted, the VM came up with the wrong IP, now you can't SSH. The console lets you fix the network config from inside.

When NOT to use it

• Daily admin work. SSH is faster, supports copy/paste better, and integrates with your local terminal tools (tmux, screen, scrollback, file transfer).
• Long-running operations. The console session expires after about two hours of inactivity, and closing the tab ends the session immediately. Run anything that takes hours under tmux or screen over SSH so it survives a disconnect.
• Bulk file transfer. Use scp, rsync, or sftp over SSH. The console has no file-transfer channel.

How to launch it

1. Sign in to customer.lylix.net and open your service.
2. Click the Console tab.
3. Click Launch Console.
4. A new browser tab opens with the VM's display. Click into it to give it keyboard focus.

You should see either a login prompt (if the VM is fully booted) or whatever the VM is currently showing. If you see a black screen, click into the window and press a key — many distros blank the console after idle time.

Logging in via the console

The console connects you to a local terminal session, not an SSH session — so you log in with the VM's root password, not your SSH key. If you changed the root password, use the new one. If you've never set one and have only ever used SSH keys, you'll need the root password from the original welcome email (or set one in advance from an SSH session so you have it for emergencies).

Useful keystrokes

• Ctrl-Alt-Del (button in the console toolbar): signals a clean reboot to the guest kernel. Equivalent to running reboot at the shell.
• Send Ctrl+Alt+Del button: same as above — the keyboard combo from your local browser is usually intercepted by your OS, so use the toolbar button.
• Copy-paste: most browsers support it within the noVNC text area, but it's flakier than a native terminal. For long commands, type rather than paste, or paste in chunks.

Common recovery walkthroughs

Fixing a broken sshd config

1. Launch the console, log in as root.
2. Edit the file:

   nano /etc/ssh/sshd_config

3. Test the syntax:

   sshd -t

   (Silent output = no errors.)
4. Restart sshd:

   systemctl restart ssh    # Debian / Ubuntu
   systemctl restart sshd   # AlmaLinux / RHEL

5. From your local machine, try SSH again. If it works, close the console tab.

Adding the SSH port back to the firewall

# UFW:
ufw allow 22/tcp
ufw reload

# firewalld:
firewall-cmd --permanent --add-service=ssh
firewall-cmd --reload

# nftables (direct):
nft add rule inet filter input tcp dport 22 accept

Resetting a forgotten root password

If you can't remember the root password and can't log in via SSH either, the workflow is single-user mode:

1. Launch the console.
2. Reboot the VM (Send Ctrl+Alt+Del).
3. When GRUB appears, press a key to interrupt the auto-boot.
4. Highlight the default kernel, press e to edit.
5. Find the line starting with linux, append init=/bin/bash to the end.
6. Press Ctrl-X to boot.
7. At the bash prompt, remount root rw:

   mount -o remount,rw /

8. Set the password:

   passwd

9. Sync and reboot:

   sync
   reboot -f

If you'd rather not deal with the GRUB dance, the OS reload feature wipes the VM and re-provisions with a fresh root password — but you lose everything on the disk. Single-user mode is faster and non-destructive.

Console session limits

• Per-session duration: up to two hours of idle; activity refreshes the timer.
• Per-customer / per-VM scoping: console URLs are scoped at the hypervisor permission layer — a console token issued for your VM can't be reused to reach another customer's VM, even with URL tampering.
• One session at a time is the comfortable recommendation; multiple browser tabs sharing the same token compete for the keyboard buffer.

If the console doesn't load, the VM is stopped (the hypervisor serves the display only when the VM is running). Power on from the action buttons above the stats panel, then re-launch.