Set up secure SSH access to your Linux server

Check your recovery access first

Before making changes, check how you would reach the server if SSH stopped working, for example through an available web console. Test that access and keep your existing SSH session open throughout the change. Save the current configuration and identify who can restore it if needed.

Give each administrator an individual account. On Ubuntu, authorised users can perform administrative tasks through sudo. Test those privileges in a new session before restricting the existing root login. A shared account makes it harder to attribute access and remove one person's permissions later.

Create and protect your keys

An SSH key pair has a private and a public part. Generate it on your own computer; with a compatible OpenSSH client, one option is ssh-keygen -t ed25519. Choose a new filename if a key already exists, and protect the private key used for interactive logins with a strong passphrase. The .pub file contains the public part. Never put the private key in a support ticket or copy it to the destination server.

Add the public key to the intended account, usually in its ~/.ssh/authorized_keys file. On Ubuntu, ssh-copy-id can help. Check ownership and file permissions against your distribution's instructions. Then open a fresh connection using that account and key. Automated backup or deployment access should have separate permissions limited to its purpose.

Verify the server's identity too

On a first connection, OpenSSH normally shows the server key's fingerprint. Compare it through an already trusted channel, for example against the output at the server console. Your login key and the server key serve different purposes. Do not dismiss a changed-server-key warning without checking: establish whether an event such as a reinstall explains it, then verify the new fingerprint.

Restrict login methods in stages

Only restrict password and direct root logins after testing key access and sudo. OpenSSH controls these through PasswordAuthentication and PermitRootLogin. Keyboard-interactive is a separate method and may form part of multifactor authentication. Review the complete authentication setup instead of copying individual settings blindly. Include existing maintenance and automation access in that review.

Account for included configuration files: on Ubuntu, entries in sshd_config.d can take precedence over the main file. Check the configuration with sudo sshd -t before applying it. Use sudo sshd -T to inspect effective settings; user- or address-specific Match rules also need the appropriate test context through -C. Apply changes according to your distribution's instructions only after validation, then test another login immediately. Keep the original session open until verification is complete.

Maintain access after setup

NUXOA offers Linux servers with SSH root access for applications you administer yourself. If you need operational support, agree in the quotation who manages users, keys, updates and recovery access. That keeps responsibility for changes and verification clear after the initial setup.

• Record the owner, purpose and registered public keys for each account.
• Remove obsolete keys when devices or staff change. Locking an account's password alone does not automatically prevent SSH key login on Ubuntu.
• After changes, test both permitted access and the intended rejection of old methods. Also verify that required automated jobs still work.