Amazon.co.uk Widgets

Log in

X
Enabling SSH and key based login in Ubuntu 25.10

SSH (Secure Shell) key-based authentication is a secure method for logging into remote servers without using passwords. It involves a pair of keys: a public key stored on the server and a private key kept on the client machine It is quite simple in practice but can be confusing to set up.

TL:DR – With SSH keys properly managed and passwords disabled, Ubuntu 25.10 can deliver both remote convenience and hardened security.

1. Introduction

1.1 Why SSH remains essential

Secure Shell (SSH) continues to be the backbone of remote system administration. It enables encrypted command-line access, file transfers, and automation between machines without exposing sensitive data to the network. Whether managing servers or IoT devices, SSH is indispensable in any secure computing environment.

Image1

1.2 Overview of Ubuntu 25.10’s security environment

Ubuntu 25.10, with its updated kernel and strengthened security defaults, places emphasis on encryption and system hardening. Out of the box, SSH is not enabled, reflecting Canonical’s principle of minimising attack surfaces.

Enabling and configuring SSH correctly ensures both accessibility and safety.

2. Understanding SSH on Modern Ubuntu

2.1 The OpenSSH server package

Ubuntu ships with the OpenSSH suite — a robust and widely audited implementation of the SSH protocol. The client tools are usually pre-installed, but the server component (openssh-server) must be added explicitly.

2.2 Default security features in Ubuntu 25.10

Ubuntu integrates AppArmor profiles and the Uncomplicated Firewall (UFW) by default. These layers restrict unauthorised network access, meaning SSH ports are blocked until explicitly opened. This default posture is ideal for preventing opportunistic attacks.

3. Installing and Enabling SSH Access

3.1 Installing OpenSSH server via APT

Open a terminal and execute:

sudo apt update
sudo apt install openssh-server -y

This installs the server daemon (sshd), service scripts, and configuration files.

3.2 Verifying the SSH service status

Confirm the service is running:

sudo systemctl status ssh

If inactive, enable it:

sudo systemctl enable --now ssh

3.3 Allowing SSH through the firewall

UFW can be adjusted easily:

sudo ufw allow ssh
sudo ufw enable

This rule opens port 22, allowing incoming connections.

4. Configuring SSH for Secure Operation

4.1 Editing the sshd configuration file

The main configuration resides at /etc/ssh/sshd_config. Open it with:

sudo vi /etc/ssh/sshd_config

4.2 Key options that enhance security

Adjust the following lines:

PermitRootLogin no
PasswordAuthentication yes
PubkeyAuthentication yes

 This prevents direct root logins while still allowing password-based authentication for initial setup.

4.3 Restarting and validating configuration changes

After editing:

sudo systemctl restart ssh
sudo sshd -t

 The -t option checks syntax validity before applying changes.

5. Generating SSH Keys on the Client

5.1 RSA, ED25519, and other key types

While RSA remains compatible, ED25519 is preferred for its compact size and superior performance. It also resists timing attacks.

5.2 Creating a new key pair

On your client machine:

ssh-keygen -t ed25519 -C "This email address is being protected from spambots. You need JavaScript enabled to view it."

When prompted, accept defaults and optionally set a passphrase for added security.

5.3 Managing key permissions

Ensure proper permissions: 

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

 Incorrect permissions will cause key rejections.

6. Copying Keys to the Server

6.1 Using ssh-copy-id

This is the simplest method If ssh-copy-id is available:: 

ssh-copy-id user@server_ip

This tool automatically appends your public key to ~/.ssh/authorized_keys.

6.2 Manual key installation and permissions

If ssh-copy-id is unavailable:

scp ~/.ssh/id_ed25519.pub user@server_ip:~
ssh user@server_ip
mkdir -p ~/.ssh
cat ~/id_ed25519.pub >> ~/.ssh/authorized_keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

6.3 Testing key-based authentication

Reconnect:

ssh user@server_ip

You should be prompted for the key’s passphrase, not the system password.

7. Disabling Password Authentication

7.1 Editing sshd_config to enforce key-only login

Once key access is confirmed, edit:

PasswordAuthentication no
ChallengeResponseAuthentication no

This prevents all password-based logins.

7.2 Restarting SSH service securely

Apply and verify:

sudo systemctl restart ssh
sudo sshd -t

7.3 Handling lockout scenarios

Keep an open session when making these changes. If you misconfigure SSH, you can correct errors before disconnecting. Always test new sessions before closing existing ones.

8. Hardening SSH for Production Use

8.1 Restricting users and root access

Limit which accounts can connect:

AllowUsers admin backup

Disabling root access further reduces risk.

8.2 Enabling fail2ban or UFW rules

Install fail2ban:

sudo apt install fail2ban -y

This automatically bans repeated failed login attempts.

8.3 Monitoring and auditing SSH logs

SSH logs are found at /var/log/auth.log. Use:

sudo tail -f /var/log/auth.log

Regularly auditing these logs helps detect brute-force attempts or suspicious activity.

9. Troubleshooting Common SSH Issues

9.1 Permission and ownership errors

Permissions must be exact. Directories or files owned by the wrong user cause silent authentication failures.

9.2 Connection refused or timeouts

If connections fail, verify firewall rules and ensure the SSH daemon is active:

sudo systemctl restart ssh

9.3 Debugging SSH with verbose output

Run:

ssh -vvv user@server_ip

The verbose flags show detailed debug information useful for diagnosing handshake or authentication issues.

10. Conclusion

10.1 Benefits of key-based authentication

Key-based authentication eliminates the weaknesses of passwords. It offers superior cryptographic protection and integrates seamlessly with automation and configuration management tools.

10.2 Maintaining a secure SSH environment

Regular updates, log monitoring, and configuration audits are vital.