SSH gives administrators a secure way to manage a remote Linux server, but an internet-facing login is also a regular target for automated password guessing. A safer setup starts with controlling who can connect and how they prove their identity. Changing the port may reduce background noise, but it does not replace those controls.

Start with the accounts that can log in

Give each administrator an individual user account. Shared logins make it harder to identify who made a change and complicate access removal when someone leaves. Grant administrative privileges only to people who need them, and review the list periodically. Remove old accounts and check their SSH key files as well as their passwords: disabling a password alone may not remove public-key access.

Where your Linux distribution supports it, restrict SSH to a named group of approved users. Ubuntu’s user management guidance shows how SSH access can be limited with an AllowGroups setting. Use the equivalent documented control for your distribution.

Use individual keys and protect the private key

With public-key authentication, the server keeps a public key while the administrator keeps the matching private key. The private key should stay on the administrator’s device and should not be emailed, copied between colleagues or placed in a shared repository. Add a passphrase to the key and use a supported agent or hardware-backed key where it suits your environment.

For new Ubuntu OpenSSH keys, the distribution documentation recommends Ed25519 as a compact, efficient option. It also documents RSA at 4096 bits as an alternative where compatibility requires it. Store each administrator’s public key against their own account so access can be removed without disrupting everyone else.

Turn off weaker access only after testing

Once key-based access works for every legitimate administrator, consider disabling direct root login and password authentication. These settings can reduce the ways an attacker can enter, but a typo or missing key can also lock out the team. Keep your current SSH session open, test a second login in a new terminal, and make sure the hosting provider’s recovery console or another approved access route is available before changing the configuration.

Ubuntu warns that an incorrect SSH configuration can prevent the daemon from starting or leave you without remote access. Follow the OpenSSH server guide for your system, back up the existing configuration, and validate changes before restarting the service.

Reduce exposure and keep access current

Allow SSH through the host or network firewall only where it is needed. If your administrators connect from stable office or VPN addresses, restricting the source addresses can reduce exposure; avoid rules that could unexpectedly block staff who work remotely. Keep OpenSSH and the operating system updated, monitor authentication logs for unusual activity, and remove a key promptly when a device is lost or an administrator’s access ends.

Moving SSH to a different port can cut down on routine bot traffic, but scanners can still find it. Treat that as a noise-reduction measure, not a security boundary. Account control, protected keys, updates, monitoring and a recovery path do the real work.

A safe change checklist

  • Confirm every administrator has an individual account and only the permissions they need.

  • Install and test each person’s key before disabling password login.

  • Keep an existing session open and confirm console or recovery access.

  • Back up the SSH configuration, validate it and then apply the change.

  • Review users, authorized keys, firewall rules and login logs regularly.

Separate human and automated access

Deploy scripts and monitoring tools should not borrow an administrator’s personal key. Give automation a dedicated identity and only the permissions it needs, then store its key in the deployment system’s secret store. That makes it easier to revoke a single credential if a runner or machine is retired. Avoid putting private keys in shell history, source control or broadly readable files.

Also decide how you will review access. Keep a record of which key belongs to which person or service, check that record when staff or infrastructure change, and investigate unexpected login sources in the SSH logs. If you suspect a key has been copied, remove it from every authorised account and replace it through your normal change process.

SSH hardening is an access-management task as much as a configuration task. A short review after staff changes, server rebuilds and key incidents helps keep the list of people who can reach a machine aligned with the people who still need to administer it.