Secure SSH Access on Linux Servers

In short: SSH is secure as a protocol, but its default settings leave an internet-facing server open to brute-force attempts within minutes of installation. Five changes close most of the gap: move the port, disable root login, use keys instead of passwords, restrict the port in the firewall and ban repeat offenders with Fail2Ban.

Why the defaults are not enough

Every public IPv4 address is scanned continuously for port 22. With root login and password authentication enabled, attackers can try millions of password guesses; a weak or reused password eventually falls. Securing SSH prevents unauthorised access, limits brute-force attacks and, with keys, makes the credential impossible to guess.

Step 1: change the SSH port

Moving off port 22 removes the automated noise. Edit the configuration:

sudo nano /etc/ssh/sshd_config

Find the Port line and set a new value, for example Port 2222. Open the new port in the firewall before restarting SSH, then restart the service:

sudo systemctl restart sshd

Connect with ssh -p 2222 user@server from a second terminal to confirm it works before closing the first session.

Step 2: disable root login

Root has unlimited rights, so it should never be the account that logs in directly. Create an administrator user with sudo (adduser admin && usermod -aG sudo admin), then in sshd_config set:

PermitRootLogin no

Restart SSH. From now on you log in as the admin user and use sudo for privileged commands.

Step 3: use key-based authentication

Password logins can be guessed; keys cannot. Create a key pair on your own computer and copy the public key to the server:

ssh-keygen -t ed25519
ssh-copy-id -p 2222 admin@server_ip

Test a key login in a new terminal. When it works, turn passwords off in sshd_config and restart SSH:

PasswordAuthentication no

Keep the private key safe and backed up; it is now the only way in.

Step 4: restrict access in the firewall

If you connect from a fixed office IP, allow SSH only from there. With UFW:

sudo ufw allow from 203.0.113.10 to any port 2222 proto tcp
sudo ufw enable

Replace the example address with your own. If your IP changes, allow the port generally and rely on keys plus Fail2Ban instead. See the UFW guide for the full rule set.

Step 5: block brute-force attempts with Fail2Ban

Fail2Ban watches the authentication log and bans an address after repeated failures:

sudo apt install fail2ban
sudo nano /etc/fail2ban/jail.local

[sshd]
enabled  = true
port     = 2222
maxretry = 5
bantime  = 3600

sudo systemctl enable --now fail2ban

With these values an address that fails five times is banned for an hour. Use jail.local, not jail.conf, so updates do not overwrite your settings.

Extra measures

• Idle timeout: ClientAliveInterval 300 and ClientAliveCountMax 2 close forgotten sessions.
• Limit users: AllowUsers admin lets only named accounts log in.
• Two-factor: the libpam-google-authenticator package adds a one-time code on top of the key.
• Updates: keep OpenSSH current; unattended-upgrades installs security patches automatically.
• Logs: review /var/log/auth.log or journalctl -u sshd for unexpected logins.

Fiberserver VDS plans give you root access and the FiberVM VNC console, so if an SSH change ever locks you out you can still reach the server from the panel and repair the configuration. The first-day checklist puts these steps in order with the rest of the initial setup.