Access & security
Who can reach this server's command line — password or key, root or not, and on which port.
This tab configures sshd: how people authenticate, whether root may sign in
at all, and which port the daemon listens on. Three settings, each of which can
lock you out if you get it wrong — which is why saving them goes through a
confirmation that names the consequence.
How can people sign in?
Applies to everyone with an account on this server.
| Option | Means |
|---|---|
| With a password or an SSH key | Either works. Easier to set up, but passwords get guessed. |
| With an SSH key only | No key, no way in — including for you. |
Key-only is the safer setting and the one to aim for. The panel will not let you switch to it blind: if there is no SSH key on this server yet, the option is disabled with the reason — "No SSH key on this server yet — add one first, or you would lock yourself out." Add a key under System users first.
On a freshly adopted or freshly installed server, the System Users screen shows a banner reading "SSH switches aren't active yet — every user can sign in over SSH until Access & security is saved." Saving this section once is what turns the per-user SSH switches on.
Can the root user sign in directly?
| Option | Means |
|---|---|
| Yes, with a password or a key | Not recommended. |
| Only with an SSH key | A password will never work for root. |
| No, not at all | Use a normal user and sudo instead. |
No, not at all is the right answer on almost every server. root is the one
username every automated attack already knows, so removing it as a target
removes the entire category.
If root login by password is on, Settings marks Access & security with a Needs attention badge from every tab, and this section carries a warning at the top. That badge is the only one of its kind on the screen — everything else here is a preference, this one is a standing invitation.
Port for SSH connections
22 by default, and the port scanners try first. Moving it to something else cuts the noise in your auth log dramatically. It is not a security control on its own — a scanner that sweeps all 65,535 ports still finds you — but it is free.
Saving
Change what you need and press Save SSH settings.
Read the confirmation. It lists the practical consequence of each change you made, in plain terms — not a generic "are you sure".
The messages you can see here:
| Change | What the dialog tells you |
|---|---|
| Port moved | SSH moves from port 22 to 2222. The firewall opens 2222 first and closes 22 afterwards, unless you added the rule for 22 yourself. |
| Passwords turned off | Password logins stop working. Without a key already on this server, you're locked out. |
| Root turned off | Root can no longer log in. Make sure another user can, with sudo. |
| Root password login turned on | Root will be able to log in with a password — the account attacks try first. |
Every one of them is followed by the same advice, which is worth taking: test the new settings in another terminal before closing this one.
Press Apply changes. sshd is reconfigured and reloaded. Existing sessions
stay up — a reload does not disconnect you, which is what gives you the window to
test.
Caveats
- The firewall is handled for you on a port move — the new port is opened before the old one is closed. The one exception is a rule for the old port that you added yourself on the Firewall screen; the panel leaves your own rules alone, so remove it yourself afterwards.
- A port move does not update anything that connects out. Deploy keys, rsync scripts, an SFTP backup destination pointing at this host — all of them keep using the old port until you change them.
- These settings are server-wide. Per-user SSH access is a switch on each system user; this screen decides what those switches are even allowed to mean.
- Fail2ban is a separate screen, and still worth turning on whatever you choose here.
- Needs Setting · Manage.