Browser terminal for your VDS: when to use it and when not

A browser terminal on a VDS is a real SSH session that happens to be drawn in a web page. On the RE:NODE VDS page, where the terminal is switched on, you press one button, the panel tries the saved login against your server, and if that works a shell opens in the page already logged in - no client to install, no password to paste. Above it sits a live view of CPU, memory, disk, swap, load, network and uptime, refreshed every 3 seconds with small charts of the last two minutes. It is the right tool for a quick look, a restart of a service, or getting back in from a borrowed laptop. It is the wrong tool for a long working day, file transfers, tunnels or anything you would script. And because both features log in with a password the panel holds, they have a direct effect on how you can harden SSH on the machine. All three sides of that are below.

What the VDS page shows you#

A VDS has no game-panel agent running on it, so the only way the panel can know what the machine is doing is to ask the machine. The VDS page does exactly that: it logs in over SSH with the credentials saved for your order and runs one fixed, read-only command that reads counters under /proc and asks df about the root filesystem. Nothing you type on the page ends up on that command line.

What comes back is drawn as a card called "Live resources":

Bars turn amber at 70% and red at 90%. A small "Live" indicator says how many seconds ago the last reading arrived, and turns into "Paused" when a refresh fails. The charts hold 40 points - two minutes at the 3-second interval - and they live only in your browser tab. Close the tab and the history is gone. This is a "what is happening right now" view, not monitoring with history and alerts; for that, see monitoring that tells you something.

Two details make the numbers easier to trust. CPU and network are rates, worked out from the difference between two snapshots of the kernel counters, so the first reading after you open the page takes about a second longer while it samples twice. And polling stops while the browser tab is hidden, because every refresh is a real SSH login on your machine. Leave the page open in a background tab and it does not keep logging in; bring it to the front and it reads again at once.

Reading the numbers correctly

Memory is the one people misread. The bar uses MemAvailable, which counts page cache the kernel can drop as available. A server showing 40% used memory in the panel while free shows almost nothing in the "free" column is normal: Linux fills idle RAM with cache. The number to watch is available memory going down over hours, not free memory being low. If swap is present and climbing while available memory is near zero, the machine is short of RAM, and the post on swap and the OOM killer explains what happens next.

Load average is not a percentage. On a 4-core VDS, a load of 4 means every core had work queued on average; a load of 8 means work was waiting. Compare it with the core count printed next to the CPU label. A high load with low CPU usually means processes waiting on disk, and reading a server load graph goes through the patterns.

How the browser terminal works#

The terminal card sits under the resource card. Its button reads "Open terminal"; beside the SSH command on the same page there is also a shortcut that scrolls down to it and opens it. Opening runs in a fixed order:

1. The panel tries a real SSH login to your VDS with the saved address, port, username and password, with a short timeout.
2. If the login fails, nothing is drawn. You get a sentence instead: the server could not be reached on its SSH port (it may be off, or a firewall is in the way), or the server refused the saved login details.
3. If it works, the panel issues a single-use address for the session. That address carries no password; it carries a random token that is traded for the login once, on our side, within a minute.
4. The session opens in the page, logged in as the saved user. "Full screen" fills the window, "Close" ends the session.

The order matters. A terminal that opens onto "Permission denied" looks broken; checking the login first means a failure is reported as what it is. The password never travels to your browser at all - not in the address, not in the page. And because the address works once, copying it out of the page and opening it again later gives you an error, not a shell.

The terminal sets TERM=xterm-256color, so htop, vim, nano, less and tmux draw properly, and resizing the window or going full screen resizes the remote shell. Selecting text copies it, and Ctrl+C with a selection copies rather than interrupting the running program. Without a selection, Ctrl+C sends an interrupt as you would expect.

Opening is rate limited to 10 attempts a minute. If you hit that - usually by clicking "Try again" in a loop while the server is still booting - wait a minute.

What the session is, and is not

It is an ordinary interactive SSH login. Everything you do runs on your VDS with the saved user's permissions - on a fresh VDS that is usually root, which is the username the page shows. It is not a sandbox, not a recovery console, and not a view of the machine's screen. If SSH is down, the terminal is down with it: it cannot help you fix a broken sshd_config, a firewall that blocks port 22, or a machine that did not boot. Those need a ticket.

It is also not persistent. Closing the card, reloading the page or losing your connection ends the shell, and whatever was running in the foreground gets a hangup. If you are about to run something long - an upgrade, a large rsync, a database import - start tmux or screen first, so the work survives the tab:

$ tmux new -s work# run the long job, then detach with Ctrl+B then D$ tmux attach -t work

That habit is worth having in any SSH client, but in a browser tab it is the difference between a finished upgrade and a half-installed one.

When the browser terminal is the better tool#

There are situations where a terminal in the panel page is simply quicker:

• You are on a machine that is not yours. A work laptop that will not let you install an SSH client, a library computer, a friend's PC. Nothing is installed and nothing is left behind - no known_hosts entry, no saved key, no password in a clipboard manager.
• You are on a phone and need one command. Restarting a service that hung at night is systemctl restart myapp, and it is faster to tap through the panel than to set up a mobile SSH app.
• You are checking whether the login works at all. The pre-check gives you a plain answer - unreachable, or refused - which is a useful first step before you start debugging your own client.
• You are already looking at the resource card. Memory jumped and you want ps or htop next to it. The card and the shell are on one page.
• You have not set up keys yet. On day one, before you have done the first hour on a new VDS, it is a way in that does not involve typing a generated password.

A typical short session from the page looks like this:

$ systemctl status myapp --no-pager$ journalctl -u myapp -n 50 --no-pager$ df -h /$ free -m$ ps aux --sort=-%mem | head -n 10

Status, recent logs, disk, memory, the top memory users. Five commands, answer found, close the card. Linux commands for server admins has the wider set.

When your own SSH client is better#

For most real work, use a proper client. The browser terminal is deliberately one thing - an interactive shell - and a lot of what you do on a VDS is not that.

Files are the most common gap. There is no upload button in the terminal; paste works for small text, but anything bigger belongs in scp or rsync:

$ rsync -avz --progress ./site/ root@203.0.113.10:/var/www/site/$ scp backup.sql.gz root@203.0.113.10:/root/

Tunnels are the second. If you want to reach a database that listens only on 127.0.0.1 on the VDS, the browser cannot forward a port to your desktop; your client can, as the post on SSH tunnels shows. The same goes for anything you automate: a deploy script, a backup job pulling files to your own machine, a configuration tool. All of those need SSH on your side.

The last reason is comfort over a long day: your own fonts, keyboard shortcuts, a client that reconnects after your laptop sleeps, a ~/.ssh/config with a short host alias. If you set one up, the SSH config file is the place to start:

Host myvds    HostName 203.0.113.10    User root    Port 22    IdentityFile ~/.ssh/id_ed25519

SSH hardening and the panel: the trade-off#

This is the part people find out the hard way. Both the resource card and the browser terminal log in with the password the panel holds for your VDS. The terminal explicitly uses password authentication, not keys. So the standard hardening advice - switch to keys and turn off passwords - has a consequence here.

If you set this in /etc/ssh/sshd_config and reload sshd:

PasswordAuthentication noKbdInteractiveAuthentication no

then the resource card stops updating and the terminal reports that the server refused the saved login. Nothing is wrong with the panel; you told SSH to stop accepting the very thing it logs in with. The same happens if you change the root password, rename or disable the login user, move SSH to a different port, or close the port to the outside in your firewall.

You have three honest options:

1. Keep password login on, and make the password strong. The generated password is long and random; leave it that way, keep fail2ban in front of it, and add keys for your own use alongside it. Password login with a strong secret and brute-force banning is a reasonable position, not a failure.
2. Allow passwords only from the panel's address. sshd's Match blocks can allow password authentication for one source address and refuse it for everyone else. The panel's connections show up in your auth log with their source address; find it with last -i or journalctl -u ssh, and use that, rather than an address you guessed.
3. Turn passwords off and accept that the card and terminal stop working. Use your own client with keys for everything. This is a perfectly good choice for people who never open the panel page.

Option two, in practice, looks like this. The Match block goes at the end of the file, because everything after a Match line belongs to it:

PasswordAuthentication noKbdInteractiveAuthentication noMatch Address 198.51.100.7    PasswordAuthentication yes

Replace the example address with the one from your own log. Test with sshd -t before you reload, and keep a second session open while you do it, so a typo does not lock you out. The SSH keys and hardening guide covers the rest of the file.

Security notes worth knowing#

A browser terminal raises fair questions. Here is what holds, and what you should still think about.

The password does not reach your browser. The page that shows your credentials can reveal the password if you ask it to, but the terminal itself does not use the page's copy. It is handed a single-use token that expires within a minute and can be redeemed once; the login happens on our side. A screenshot or a copied terminal address leaks nothing reusable.

Who can open it. The terminal opens for the account that owns the VDS order. It sits behind your panel session, so the protection on the terminal is the protection on your panel account. Turn on two-factor authentication with an authenticator app, keep the recovery codes somewhere offline, and check the session list for sign-ins you do not recognise. Someone who gets into your panel account gets a root shell on your VDS - which is true of any panel that shows you the root password, terminal or not.

Your auth log will be busy. Each refresh of the resource card is an SSH login. With the page in front of you, that is a successful login roughly every 3 seconds, logged by sshd like any other. It is expected, it stops when you close or hide the tab, and it is a good reason not to treat "a login from an unfamiliar address" in the log as an alarm without checking whether you had the VDS page open at the time.

fail2ban and failed logins. The card keeps polling while it reports an error. If the saved password stops matching, every poll is a failed login, and a fail2ban jail with a typical maxretry = 5 will ban the panel's address within half a minute. You will not lose anything, but when you fix the password, the panel stays locked out until the ban expires or you lift it:

$ fail2ban-client status sshd$ fail2ban-client set sshd unbanip 198.51.100.7

Add the panel's address to ignoreip in jail.local if you would rather it was never banned.

Shared machines. Using the terminal from a borrowed computer is fine, but you are still signed in to the panel in that browser. Sign out when you finish, and if the machine was untrusted, end the session from the session list on your account page.

It is still root. A browser tab makes rm -rf exactly as final as a native client does. Read before you press Enter, and paste multi-line commands with care - a paste that includes a stray newline runs.

Troubleshooting the terminal and the card#

Most problems are one of a handful, and the page tells you which.

"Could not reach the server on port 22". The panel could not open a TCP connection to SSH. The VDS may be off or rebooting, sshd may not be running, or a firewall on the machine is dropping the panel's connection. If you use ufw, check ufw status - an allow for SSH that is limited to your home address also shuts the panel out.

"The server refused the saved login details". The machine answered but rejected the login: a changed password, PasswordAuthentication no, a removed user, or PermitRootLogin changed to prohibit-password. That last one is easy to miss, because it still lets root in with a key and so feels like nothing changed.

"Too many attempts in a minute". The 10-a-minute limit on opening. Wait.

The card says "Paused" but SSH works from your client. Check whether your client uses a key; if so, the password path may be the one that is broken. Also check fail2ban, as above.

The terminal opened, then said the link has expired or was already used. The single-use address was opened twice or too late - for example a page restored from the browser's history. Close the card and open it again.

The shell draws the prompt over itself. Usually a remote shell that did not get the new window size. Run reset, or close and reopen the card at the size you want.

FAQ#

Is the browser terminal less secure than my own SSH client?

The connection to your VDS is SSH either way. The difference is where the password lives: with your client, on your machine; with the browser terminal, with the panel, behind your panel login. If your panel account has 2FA and a strong password, the main risk is the same one you already accept by having the root password shown on the page.

Can I log in with an SSH key in the browser terminal?

No. It logs in with the saved password for your VDS. If you want key-only access, use your own client, or allow passwords only from the panel's address with a Match Address block so both work.

Why does my auth log show a login every few seconds?

That is the live resource card. Each refresh is one SSH login running a read-only command against /proc and df. It stops when you close the page or switch to another tab.

Does closing the browser tab stop my running command?

Yes, the shell ends and foreground programs get a hangup. Start long jobs inside tmux or screen, or run them as a systemd service, and they carry on without the tab.

Can I see more than two minutes of history?

Not on the card. It keeps the last 40 readings in your tab and nothing on the server. For history and alerts, run a monitoring agent on the VDS itself.

What if I do not see the Open terminal button?

The terminal is switched on per panel and the button only appears where it is. The resource card and the SSH command on the page still work; connect with your own client.