Enable SSH on Ubuntu Linux and Set Up Key Authentication

SSH and the server access path

Remote Linux administration needs an encrypted connection and a way to avoid locking yourself out while changing access settings. SSH provides that connection. On Ubuntu, this guide installs openssh-server, verifies key authentication in a fresh session, and then applies login restrictions.

Account, console and package requirements

Installation commands and service names target Ubuntu Server 24.04 LTS. Record the installed OpenSSH version. Other distributions require their own package manager and service names.

Enabling SSH requires no particular VM sizing. An independent console and an open administrator session provide recovery access. Check TCP/22 through the actual management path.

The server needs sudo and openssh-server, and the client needs openssh-client. Create opsadmin beforehand and test its sudo privileges separately. Include every required human and automation account in AllowUsers.

Service names and effective settings

On RHEL the service is usually sshd and apt commands do not apply. For many OpenSSH options, the first obtained value wins. Check include order and cloud snippets with sshd -T rather than inferring precedence from the new filename.

Source restrictions and MFA compatibility

Restrict TCP/22 to management sources. Add a suitable rule when UFW is already deployed. Enabling an unconfigured firewall over SSH risks lockout. A port change does not replace keys or account controls. Review KbdInteractiveAuthentication no against PAM MFA before applying it. For FIPS environments, check Ed25519 support and use RSA with SHA-2 signatures where required.

Install the service and test key login

Run this stage on the Ubuntu server: install SSH, then check its version, service state and listening port. Keep a full system upgrade separate so each change remains traceable. Save the configuration once to a new backup path without overwriting an earlier copy.

sudo apt-get update
sudo apt-get install -y openssh-server
dpkg-query -W openssh-server
systemctl status ssh.service ssh.socket --no-pager
sudo ss -lntp '( sport = :22 )'
sudo cp -a /etc/ssh /root/ssh-before-change

Generate a passphrase-protected client key and install its public key for the existing account. Compare the host fingerprint before acceptance. The third command tests password-free login.

ssh-keygen -t ed25519 -f "$HOME/.ssh/ops_ed25519"
ssh-copy-id -i "$HOME/.ssh/ops_ed25519.pub" opsadmin@10.20.30.10
ssh -i "$HOME/.ssh/ops_ed25519" -o PasswordAuthentication=no opsadmin@10.20.30.10

Check .ssh permissions as the target account. After independent login and sudo succeed, write the snippet from an administrator session. Adapt AllowUsers to actual accounts first.

chmod 700 "$HOME/.ssh"
chmod 600 "$HOME/.ssh/authorized_keys"
sudo tee /etc/ssh/sshd_config.d/00-enterprise.conf >/dev/null <<'EOF'
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
AllowUsers opsadmin
X11Forwarding no
MaxAuthTries 3
EOF
sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T | grep -E 'permitrootlogin|passwordauthentication|allowusers'
sudo systemctl reload ssh.service

A successful sshd -t syntax check produces no output. Then inspect the effective settings with sshd -T; PasswordAuthentication should be no. Keep the current administrative session open while testing key login and sudo in a fresh session. A configuration filename alone does not establish which value the service accepted.

Login records and access probes

Inspect ssh.service logs for successful and rejected authentication. A TCP probe and an authorized login test measure different things. Include host, source and timestamp in alerts. Set failure thresholds from observed traffic and keep keys and tokens out of logs.

From connection failure to rejected keys

Separate a connection failure from a login failure. Connection refused calls for checking the listener and reject rules; a timeout calls for checking routing and firewall drops. Once a connection reaches SSH but key authentication fails, focus on the account, key and sshd settings.

sudo journalctl -u ssh.service -n 100 --no-pager
sudo /usr/sbin/sshd -T
ssh -vvv -i "$HOME/.ssh/ops_ed25519" opsadmin@10.20.30.10

Ownership errors point to HOME or .ssh. Check permissions and the account owner. For a valid key rejected by policy, inspect AllowUsers, Match and sshd -T -C output. On Ubuntu with ssh.socket, systemd manages the listener, so port changes also require socket checks.

Roll back while a session remains open

The /etc/ssh copy contains host keys and needs restricted, encrypted storage. To undo this change, move only the new include file out, validate syntax and reload. Use the console or an existing session.

sudo mv /etc/ssh/sshd_config.d/00-enterprise.conf /root/00-enterprise.conf.failed
sudo /usr/sbin/sshd -t
sudo systemctl reload ssh.service

Restore any pre-existing files you also changed from their recorded copies. Before closing the old session, test key login and sudo in a fresh session. Avoid duplicate host keys when cloning servers.

Keys throughout the account lifecycle

A successful SSH setup begins the access-management process. Give each person a distinct account and key, protect private keys with passphrases, and remove keys when people leave the team. Review sudo privileges periodically; successful authentication does not establish that an account has appropriate permissions.

The account-management guide covers sudo permissions and access revocation. Related guide

Best Practices

Conclusion