The NordBastion polar-bear mascot in a Nordic library at night, leaning over a long oak reading table strewn with open dictionaries and PGP-signed papers under aurora-blue lamplight
Glossary entry · Security primitive

SSH Secure Shell

The encrypted remote-shell protocol every Linux box on the planet listens on by default — and the front door of every VPS we ship.

Definition
Plain English

An encrypted network protocol for operating a remote machine as if you were sitting at its console: shell access, file transfer (SCP, SFTP), arbitrary TCP port forwarding and SOCKS proxying. Replaced the cleartext telnet/rlogin/rsh trio starting in 1995. The dominant modern implementation is OpenSSH, shipped by every major Linux and BSD distribution and by macOS.

Why it matters at NordBastion

SSH is the entire control plane of your VPS.

There is no proprietary control panel between you and the operating system — no graphical "server manager", no abstracted file browser, no captive-portal-style web shell. Every NordBastion VPS lands in your hands as a stock Linux machine listening on port 22 for SSH, with a single root credential delivered through the panel. SSH is the entire control plane, full stop.

That decision rests on the same logic as the rest of the product: SSH is open, well-audited, fast, and works identically from a laptop in Berlin, a smartphone with Termius and a CI runner in another data centre. A custom web panel would be slower, weaker, and would require us to maintain code that the OpenSSH project already maintains better than we ever could.

First-hour opsec recommendations are the same on a NordBastion VPS as on any production Linux box: generate an Ed25519 key, copy the public half to the server, disable password authentication and root login if it is not needed, install fail2ban or an equivalent, and consider restricting source IPs at the firewall. The hardening guide walks through every command.

FAQ · SSH

The questions people actually ask.

How do I connect to my VPS over SSH?

From a terminal: `ssh [email protected]`. The first connection prompts you to verify the host's fingerprint — compare it against the value shown in the customer panel before accepting. After that, key-based authentication is the recommended setup: generate an Ed25519 key pair locally, paste the public half into ~/.ssh/authorized_keys on the VPS, and disable password login in /etc/ssh/sshd_config. The first-hour hardening guide walks through every step.

Is password authentication safe?

Safe enough if the password is long and random, but key-based authentication is meaningfully better. A strong key cannot be brute-forced by drive-by scanners (and there are a lot of those hitting every public IP on port 22 every day), and disabling password auth entirely eliminates an entire class of credential-stuffing noise from your logs. The hardening guide recommends key-only authentication as the default.

What is SSH port forwarding?

A way to tunnel arbitrary TCP traffic over an encrypted SSH connection. Local forwarding (`-L`) exposes a remote service on a local port — for example, opening the VPS's PostgreSQL on your laptop's localhost:5432. Remote forwarding (`-R`) is the inverse. Dynamic forwarding (`-D`) sets up a SOCKS proxy that routes any application configured to use it through the VPS. All three are extremely useful and worth learning.

Should I change the default SSH port from 22?

Mostly cosmetic. Moving SSH to a high random port cuts down the volume of drive-by scanner noise in your logs but does nothing against a targeted attacker who will simply scan the host. The real defences are key-only authentication, a fail2ban-style rate-limiter, and limiting source IPs at the firewall level if your access pattern allows it. The guide walks through all three.