Console, shell and SSH: three separate doors into the same machine

You cannot reach a machine. Before panicking, ask one question: which door were you using?

There are three separate doors into the same machine, and each one depends on different things being alive. Knowing which one closed tells you directly where the problem is.

Three doors

Console. Looking at the machine's screen and keyboard. The equivalent of walking up to a physical server and plugging in a monitor. It does not use the guest's network, it goes through the host.

Shell. Typing a command and getting output back. It does not imitate a screen, it opens a command channel directly.

SSH. A service running inside the guest. It needs the network, it needs the service to be up, it needs credentials.

The rule: the more comfortable the door, the more of the guest has to be working

SSH is the most comfortable. You connect from your own terminal, copy and paste works, you move files. In exchange it demands the most: the network config has to be right, the interface has to be up, the service has to be running, the firewall has to allow it, the key or password has to be valid. Break any link in that chain and the door closes.

The console is the least comfortable. You look at a screen in a browser, and copy and paste is usually awkward. In exchange it demands almost nothing: the guest's network can be broken, the firewall can be blocking everything, SSH can be uninstalled, and the screen still appears. Because that screen comes from the host, not from the guest's network.

That is why the console is a recovery path. Not because it is comfortable, but because it depends on so little.

The classic incident

You change a network setting. You apply it. The connection drops and does not come back.

What you did may not even have been wrong: sometimes the setting is correct and the session simply dies while the interface switches over. But now you cannot reach the machine over the network, and fixing it requires reaching the machine.

You open the console, the screen appears, you correct the setting. Because it never went over the network, breaking the network did not touch it.

The practical habit that follows: confirm the console opens before you touch a network setting. Do the risky work while you already hold a working recovery path, rather than going looking for one afterwards.

On the shell side, a container and a virtual machine are not the same thing

This distinction surprises a lot of people, because in the panel the two sit side by side and both offer the same button.

In a container the host can step straight in. The container shares the host's kernel, so the processes inside are already visible to the host. The host can run a command in there and asks nothing of the inside.

In a virtual machine it does not work that way. A virtual machine is a sealed box: the host sees its disk and memory as blocks and does not know what is inside. The host cannot push a command into the box.

The only way in is for something inside the box to be listening. That is exactly what the guest agent is: a small service installed inside the virtual machine that listens for requests from the host and answers them. If it is not installed, the shell door does not exist for that virtual machine, and that is not a fault, it is a consequence of the architecture.

For the same reason the shell does not work while a virtual machine is off. There is nothing there to listen. The console, on the other hand, will show you the screen of a machine that is off, and once you start it you see what happens from the first second.

The console has limits too

To be honest, the console is not magic.

If the host itself is down, all three doors are down. The console goes through the host, so when the host goes, it goes.

There is also this: the console gives you a screen, not files. If you need to get a file out, the console is a poor tool. Good for recovery, not for daily work.

Finally, console access is a separate permission. A user being able to read the panel does not mean they can look at the screens of the machines, and that separation is deliberate: a screen shows the content of the work being done.

What Atlas does

Atlas opens the console from its own screen, without asking for a second login. That sounds small, but there is a story behind it worth telling honestly.

The console actually lives at the Proxmox panel's own address. Atlas is at a different one. To a browser those are two separate sites, and one site's session does not carry over to the other by itself. With nothing done about it, a user pressing the console button gets a "no session" error and is asked to log into the panel a second time.

The first solution was this: hand the session over to the panel from inside an invisible frame. It worked. Then browsers tightened their third-party cookie rules and it stopped working. There was no bug in the code; the ground under it moved.

The second solution stayed because it is sturdier: the console is served from Atlas's own address. The browser sees a single site, there is no session left to hand over, and the problem disappears at its source.

Two small but honest details: the cookie-setting headers on responses coming back from the panel are stripped, so Atlas does not accumulate panel cookies at its own address. And the connection to the panel stays inside the machine, it never goes out onto the network.

The general lesson, independent of any product: a working solution that stops working does not always mean a bug. Sometimes an assumption you were leaning on changed. The solution that lasts is the one that leans on fewer assumptions.