The HIP web console: getting into your server when SSH won't connect

You run ssh root@YOUR_IP and get nothing back, even though the same command worked yesterday. Somewhere between then and now you touched a firewall rule, edited sshd_config, or changed a network setting, and now the door is shut. The fix isn't a reinstall or a support ticket. It's the HIP web console: a panel tab that connects to your server directly through the hypervisor, skipping the network stack inside the machine entirely.

Short version. The HIP web console is a virtual monitor and keyboard wired straight into your server, with no dependency on the network running inside it. It keeps working even when SSH, the firewall, or the network interface itself is broken. Open the Console tab on the server's page in my.hip.hosting, log in with a password (SSH keys don't apply here), then check ufw status, the state of ssh, and the output of ip a. Most lockouts turn out to be a two-minute fix once you're in.

What makes the console different from SSH

SSH is a network protocol. You connect over the internet to a specific port, and the whole path depends on what's happening inside the guest OS: whether sshd is listening on that port, whether the firewall lets the traffic through, whether the network interface is even up. Break any one link and SSH has nothing to reach, no matter how many times you retry the command.

The web console works on a different layer. It's a connection made at the hypervisor level, the software that runs the virtual machines on the physical host. Functionally it's the same as plugging a monitor and keyboard into a physical box sitting in a rack: the network never enters the picture. That's exactly why the console stays usable in every case where SSH fails because of the network, or the settings governing it, inside the guest.

When you actually need it

These are the lockouts that leave SSH with nothing to answer, and the console is the only way in because the network inside the server itself has stopped passing traffic.

• You moved SSH to a new port in sshd_config following the fresh VPS hardening guide, but restarted sshd before adding a ufw rule for the new port. This is the single most common way people lock themselves out right after a port change: the old port is already closed, the new one isn't open yet.
• A bad ufw rule blocked port 22 outright, for example running ufw deny 22 by mistake or enabling the firewall with no allow rule for SSH at all.
• A network config edit (netplan or /etc/network/interfaces) took the interface down. The server stops answering on any port even though the panel still shows it as running.
• sshd failed to start after a config edit: a typo, a stray directive, a broken Match block. The service simply never comes up.
• You lost your private SSH key, or deleted the wrong line from authorized_keys. This isn't a network problem at all, it's that nothing on the server will accept your key anymore, but the fix is the same: log in through the console with a password and rebuild the key file from there.

How to open the console

1. Sign in to my.hip.hosting and open the page for the server you're locked out of.
2. In the tab row on that page (Information, Management, Reinstall, Scale, Console, History), select Console.

The panel opens a direct connection to the server's screen, either in a new window or an embedded widget. There's nothing to open on the server's own network: the session runs through my.hip.hosting itself, not through any port on your VPS.

What you need to log in: a password, not a key

SSH keys are checked by sshd while a network connection is being set up. The console never touches that service. It shows you the same login prompt you'd see sitting at a physical keyboard, so the only way in is a password: the username and password of an actual OS account, handled by the system's own login process.

The root password is visible on the server's Information tab in the same panel, hidden behind dots until you click to reveal it. If you've forgotten it, or changed it manually and it no longer matches what the panel shows, that same tab has a reset action that sets a new root password and displays it.

There's a detail worth planning for before you actually need it. If you've turned off password login in sshd and have been getting in with a key for months, the password for root or your working user still exists. It's just not accepted over SSH anymore. The console doesn't know or care about that setting, because it never goes through sshd in the first place: it asks the OS for a password and takes whatever the OS accepts, hardening or not. So keep at least one account's password current and known, even if you never type it into an SSH client. It doesn't undo key-based login. It's a second way in for exactly the moment when the key, or the network, stops cooperating.

Fixing common lockouts from inside the console

Once you're logged in through the console, you're in an ordinary shell on the server. The commands are identical to what you'd run over SSH, only the way you got there is different. From here, work through the likely causes in order.

The firewall is blocking the port

Start by checking what ufw, the firewall bundled with Ubuntu and Debian, is actually allowing.

sudo ufw status

If port 22 (or whatever port you moved SSH to) isn't listed as allowed, or there's an explicit deny rule for it, that's the lockout. Add the rule and reload:

sudo ufw allow 22/tcp
sudo ufw reload

• 22/tcp - swap in your own port if you moved SSH off the default. The built-in OpenSSH ufw profile is always tied to port 22, so a custom port needs an explicit rule like this one.
• ufw reload re-reads the rule set without tearing down connections you already have open, unlike a full firewall restart.

sshd isn't running or has a bad config

Check whether the SSH service is alive at all.

sudo systemctl status ssh

If you see active (running), the service is fine and your lockout is elsewhere (firewall or network). If it says failed or inactive, the service didn't come up, most likely because of a config change you made recently.

Check the config's syntax before you touch the service again, so you don't just restart into the same error.

sudo sshd -t

No output means the config is valid. An error prints the exact file and line number to fix, so you correct that line instead of guessing at the whole file. Once it's clean, restart the service.

sudo systemctl restart ssh

The network interface never came up

If ufw looks fine and sshd is running but the server still doesn't answer on the network at all, the interface itself may be down, often after a netplan edit or a change to a network config file.

ip a

Look at the main interface (usually eth0 or ens3): it should have an IP address assigned and show state UP. If there's no address, or it reads state DOWN, the problem is in the network configuration you edited, not in SSH or the firewall, and that's the file to go back and fix.

Avoiding the console in the first place: two sessions, not one

It's easier to build the habit than to keep fixing access after the fact. Whenever you're changing something remotely in SSH or the firewall (a port, a ufw rule, an sshd directive), keep your current SSH session open in one window and test the new setting through a completely separate connection in a second window. If the second connection fails, the first one is still alive: you fix the mistake and try again without ever losing access. Closing the first session before the second one confirms the change works is the single most common way people end up needing the console at all.

The same habit applies to your everyday SSH connection. The console isn't a replacement for it, it's the fallback for the moments when that second-window test didn't happen or didn't help.

FAQ

I can't SSH into my server, what do I do?

First confirm the server is actually up, through the panel or a ping. If it's up but SSH refuses to connect, open the Console tab on the server's page in my.hip.hosting: it connects directly through the hypervisor and doesn't care about the firewall or sshd. Log in with a password and check ufw status, systemctl status ssh, and ip a in that order.

How do I open the HIP web console?

Sign in to my.hip.hosting, open the page for the relevant server, and select the Console tab alongside Information, Management, Reinstall, Scale, and History. The panel connects you straight to the server's screen without using the network inside it.

I locked myself out with ufw, how do I fix it?

Log in through the web console, which never passes through the firewall, and run sudo ufw status to see the current rules. If the SSH port isn't allowed, or there's a deny rule for it, add one with sudo ufw allow 22/tcp (or your custom port) and apply it with sudo ufw reload.

I lost the root password on HIP, what now?

Open the Information tab on the server's page in my.hip.hosting: there's a reset action that sets a new root password and displays it in the panel. You'll need that same password to log in through the web console, since it only accepts a password, never an SSH key.

sshd won't start after a config change, how do I check it?

Log in through the web console and run sudo sshd -t, which validates the config's syntax and points to the exact broken line, if there is one. Fix that line, then restart the service with sudo systemctl restart ssh; check its status with sudo systemctl status ssh.

Takeaways

• The HIP web console connects through the hypervisor, not the network inside your server, so it keeps working even when SSH, the firewall, or the network interface is broken.
• Open it from the Console tab on the server's page in my.hip.hosting.
• Login is password-only. SSH keys have no role inside a console session.
• Keep at least one account's password current, even if you only ever use keys over SSH. It's a safety net specifically for the console.
• The usual causes are a forgotten ufw rule after a port change, a crashed sshd, or a broken network interface, and all three are fixable with the same commands you'd use over SSH.
• To avoid needing the console at all, test risky SSH and firewall changes in a second session before closing the first.