How to Install OpenSSH on Ubuntu (26.04, 24.04, 22.04)

Installing SSH on Ubuntu enables secure remote server administration through encrypted connections. Secure Shell (SSH) encrypts all data transmitted between client and server, preventing eavesdropping during remote sessions. Whether you need to execute commands on a remote machine, transfer files securely via SCP or SFTP, or tunnel other protocols through encrypted connections, OpenSSH provides the foundation for secure Linux server management.

This guide walks through installing and configuring OpenSSH on Ubuntu, including package installation, security hardening (custom ports, key-based authentication, disabled root login), and firewall configuration. By the end, you will have a production-ready SSH server accepting secure remote connections.

These steps cover Ubuntu 22.04 LTS, 24.04 LTS, and 26.04 LTS. Ubuntu 24.04 and 26.04 use socket-based activation for SSH, while 22.04 runs a traditional persistent daemon. The commands are largely identical across releases, with version-specific differences noted where applicable.

Check If OpenSSH Is Already Installed

Most Ubuntu Server installations include OpenSSH server by default, while Ubuntu Desktop only ships with the client binary. Before installing, check whether SSH components are already present on your system.

Check for the SSH client:

ssh -V

If the client is installed, the command displays your OpenSSH version:

OpenSSH_10.2p1 Ubuntu-2ubuntu1, OpenSSL 3.5.3 16 Sep 2025

Check whether the server component is installed:

dpkg -l | grep openssh-server

If the server is installed, you see output showing the package status:

ii  openssh-server  1:10.2p1-2ubuntu1  amd64  secure shell (SSH) server

The ii prefix indicates the package is installed and configured. If this command returns no output, the SSH server is not installed and you need to proceed with installation. If the client or server is missing, continue with the steps below.

Update Ubuntu Before SSH Installation

Before installing SSH, update your Ubuntu system’s package list and upgrade existing packages. This ensures your system has the latest security patches and prevents potential conflicts during installation.

Open a terminal and run the following command:

sudo apt update && sudo apt upgrade

The first command refreshes your package index with the latest available versions, while the second command upgrades any outdated packages on your system.

Install OpenSSH on Ubuntu

Install the OpenSSH server and client packages using APT. OpenSSH is a suite of secure networking utilities based on the SSH protocol, providing encrypted communication channels over untrusted networks.

sudo apt install openssh-server openssh-client

This command is safe to run even when the packages already exist because APT simply verifies and refreshes them. Once installed, the openssh-server component allows your Ubuntu machine to accept SSH connections, while the openssh-client enables it to initiate SSH connections to other machines.

Verify OpenSSH Installation

After installation completes, verify that systemd is managing the OpenSSH service properly. The verification command differs between Ubuntu versions because of how the SSH daemon is activated.

On Ubuntu 24.04 LTS and 26.04 LTS (socket-activated):

sudo systemctl status ssh.socket

Expected output showing the socket is active and listening:

● ssh.socket - OpenBSD Secure Shell server socket
     Loaded: loaded (/lib/systemd/system/ssh.socket; enabled; preset: enabled)
     Active: active (listening) since Mon 2025-01-15 10:30:00 UTC; 5min ago
   Triggers: ● ssh.service
     Listen: 0.0.0.0:22 (Stream)
            [::]:22 (Stream)
   Accepted: 0; Connected: 0

On socket-activated systems, ssh.service appears inactive until the first SSH connection triggers it. This behavior is normal; the socket listens for connections and starts the service on demand.

On Ubuntu 22.04 LTS (traditional daemon):

sudo systemctl status ssh

Expected output showing the service is active:

● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; enabled; preset: enabled)
     Active: active (running) since Mon 2025-01-15 10:30:00 UTC; 5min ago
       Docs: man:sshd(8)
             man:sshd_config(5)
   Main PID: 1234 (sshd)
      Tasks: 1 (limit: 4096)
     Memory: 2.5M
     CGroup: /system.slice/ssh.service
             └─1234 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups"

Check the OpenSSH version to confirm installation:

ssh -V

Version numbers vary by Ubuntu release:

Ubuntu 26.04 LTS:

OpenSSH_10.2p1 Ubuntu-2ubuntu1, OpenSSL 3.5.3 16 Sep 2025

Ubuntu 24.04 LTS:

OpenSSH_9.6p1 Ubuntu-3ubuntu13.14, OpenSSL 3.0.13 30 Jan 2024

Ubuntu 22.04 LTS:

OpenSSH_8.9p1 Ubuntu-3ubuntu0.13, OpenSSL 3.0.2 15 Mar 2022

Test SSH Connection Locally

Before configuring security settings, verify SSH accepts connections by connecting to localhost. This confirms the server is running and responding properly.

ssh localhost

On first connection, SSH displays the server’s host key fingerprint and asks you to verify it:

The authenticity of host 'localhost (127.0.0.1)' can't be established.
ED25519 key fingerprint is SHA256:AbCdEfGhIjKlMnOpQrStUvWxYz1234567890.
This key fingerprint is SHA256:AbCdEfGhIjKlMnOpQrStUvWxYz1234567890.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Type yes and press Enter to add the host key to your ~/.ssh/known_hosts file. SSH then prompts for your user account password. After successful authentication, you see your shell prompt, confirming SSH is working. Type exit to close the connection.

Configure SSH Security Settings

The default OpenSSH configuration provides solid security, but customizing settings hardens your server against common attack vectors. The following sections walk through essential security improvements: changing the default port, limiting authentication attempts, disabling root login, and requiring SSH key authentication.

Understand Socket Activation on Ubuntu 24.04 and 26.04

Ubuntu 24.04 LTS and 26.04 LTS use systemd socket-based activation for OpenSSH. A systemd generator reads Port and ListenAddress directives from /etc/ssh/sshd_config and configures ssh.socket to listen on those addresses and ports. Ubuntu 22.04 LTS runs ssh.service directly at boot without socket activation.

The practical impact: when you change Port or ListenAddress directives on Ubuntu 24.04 or 26.04, run systemctl daemon-reload to regenerate the socket configuration, then restart the socket. For other configuration changes (authentication settings, login limits), restart the service. Ubuntu 22.04 LTS only requires restarting the SSH service directly.

Edit SSH Server Configuration

The primary SSH configuration file lives at /etc/ssh/sshd_config across all Ubuntu versions. The OpenSSH manual documents every configuration directive in detail. Open the configuration file with your preferred text editor:

sudo nano /etc/ssh/sshd_config

Make all desired configuration changes in the sections below (port, authentication attempts, root login, etc.) before saving and closing the file. After completing modifications, always test the syntax before restarting SSH:

sudo sshd -t

If the command returns no output, the configuration is valid. If errors exist, SSH displays the line number and problem so you can fix it before applying changes. This prevents locking yourself out with a broken configuration.

Change SSH Port from Default

Changing the default SSH port from 22 to a custom port reduces automated attack attempts targeting the standard port. Combined with login attempt restrictions and disabled root login, this hardens your server against brute-force attacks. While this is not a substitute for strong authentication, it significantly reduces noise in your logs from automated scanners.

To change the SSH port, locate the Port line in the sshd_config file (around line 15). If the line begins with #, remove the comment character. Set your preferred port number:

Port 2222

If UFW or another firewall already enforces rules, allow the new SSH port before restarting SSH to avoid locking yourself out of remote sessions. Remove the old port 22 rule only after you confirm the new port works. Keep an active SSH session open while testing the new port in a separate terminal window.

Allow the new port through UFW:

sudo ufw allow 2222/tcp

Verify the firewall rule was added:

sudo ufw status numbered

Expected output showing the new rule:

Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     ALLOW IN    Anywhere
[ 2] 2222/tcp                   ALLOW IN    Anywhere
[ 3] 22/tcp (v6)                ALLOW IN    Anywhere (v6)
[ 4] 2222/tcp (v6)              ALLOW IN    Anywhere (v6)

After updating the port number in sshd_config and testing the syntax with sudo sshd -t, apply the changes using the appropriate commands for your Ubuntu version:

On Ubuntu 24.04 LTS and 26.04 LTS:

sudo systemctl daemon-reload
sudo systemctl restart ssh.socket

The daemon-reload triggers the systemd generator that reads the new port from sshd_config and updates the socket configuration. Restarting ssh.socket applies the change. You do not need to restart ssh.service separately because it starts automatically when the first connection arrives.

Verify the socket is listening on the new port:

sudo ss -tlnp | grep 2222

Expected output confirming SSH listens on port 2222:

LISTEN 0      4096         0.0.0.0:2222       0.0.0.0:*    users:(("systemd",pid=1,fd=123))
LISTEN 0      4096            [::]:2222          [::]:*    users:(("systemd",pid=1,fd=124))

Until the first connection triggers ssh.service, the output shows systemd as the listener rather than sshd. This is expected behavior for socket activation.

Test the new port from the same machine before closing your existing session:

ssh -p 2222 localhost

If the connection succeeds, remove the old port 22 rule:

sudo ufw delete allow ssh

On Ubuntu 22.04 LTS:

sudo systemctl restart ssh

Verify the service is listening on the new port:

sudo ss -tlnp | grep 2222

Expected output:

LISTEN 0      128          0.0.0.0:2222       0.0.0.0:*    users:(("sshd",pid=12345,fd=3))
LISTEN 0      128             [::]:2222          [::]:*    users:(("sshd",pid=12345,fd=4))

Limit SSH Authentication Attempts

Restricting the maximum authentication attempts per connection mitigates brute-force attacks by disconnecting clients that fail multiple login attempts. Locate the MaxAuthTries directive in your open sshd_config file (around line 38) and set a reasonable limit:

MaxAuthTries 3

This setting allows three authentication attempts per connection before disconnecting the client. If someone is using an SSH agent with multiple keys, a lower number may cause legitimate connection failures. The default is 6, which balances security and usability.

Apply the configuration change:

sudo systemctl restart ssh

On socket-activated systems (Ubuntu 24.04 LTS and 26.04 LTS), use systemctl restart ssh rather than reload. The reload command fails if ssh.service is not running, which is the normal state before the first connection.

Disable SSH Root Login

Preventing direct root login via SSH forces attackers to compromise a regular user account before attempting privilege escalation, adding a critical security layer. Ensure you have a non-root user account with sudo privileges on Ubuntu before disabling root login to avoid locking yourself out of the server.

Locate the PermitRootLogin directive in your open sshd_config file (around line 34) and set it to no:

PermitRootLogin no

Restart the SSH service to apply the setting:

sudo systemctl restart ssh

Test root login is blocked by attempting to connect as root:

ssh root@localhost

Expected output showing root login is disabled:

root@localhost: Permission denied (publickey).

Require SSH Key Authentication

Key-based authentication removes password prompts and relies on cryptographic key pairs stored in ~/.ssh/authorized_keys. This forces SSH to reject password login attempts, requiring SSH keys instead. Keep an existing session open and confirm at least one sudo-capable user can sign in with a key before disabling passwords.

Locate these directives in sshd_config and set them as follows:

PasswordAuthentication no
KbdInteractiveAuthentication no

The PasswordAuthentication no directive disables password-based login, while KbdInteractiveAuthentication no prevents keyboard-interactive challenges that could bypass the password restriction.

To restrict SSH access even further, allow only specific users or groups. Add these lines if you want user-level restrictions:

AllowUsers alice deploy
AllowGroups sshusers

Restart the SSH service to apply these authentication changes:

sudo systemctl restart ssh

Test that password authentication is disabled by attempting to connect with a password from another terminal:

ssh -o PreferredAuthentications=password localhost

Expected output showing password authentication is disabled:

user@localhost: Permission denied (publickey).

Configure UFW Firewall for SSH

The Uncomplicated Firewall (UFW) on Ubuntu provides straightforward firewall management. Configuring UFW rules ensures only authorized traffic reaches your SSH service. For additional brute-force protection, consider installing Fail2ban on Ubuntu to automatically ban IPs with repeated failed login attempts.

If UFW is not installed, add it with this command:

sudo apt install ufw

Allow incoming SSH connections on the default port:

sudo ufw allow ssh

Alternatively, for a custom port (adjust the port number to match your sshd_config setting):

sudo ufw allow 2222/tcp

To restrict SSH access to a specific IP address, specify the source IP in the rule (replace 203.0.113.10 with the client you want to allow):

sudo ufw allow from 203.0.113.10 to any port 22

Enable UFW if not already active. See the guide to enable or disable the firewall on Ubuntu for detailed UFW management:

sudo ufw enable

Verify your firewall rules:

sudo ufw status

Expected output (the port shown depends on your configuration):

Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere
22/tcp (v6)                ALLOW       Anywhere (v6)

If you changed SSH to a custom port, your output shows that port instead (for example, 2222/tcp).

Connect to Remote Servers with SSH

After configuring your SSH server, use the SSH client to establish remote connections, transfer files, and execute commands on other systems.

Establish Basic SSH Connection

Connect to a remote server using SSH with the following command syntax:

ssh username@remote_server

Replace username with your account username and remote_server with the server’s hostname or IP address. The system prompts you for your password to authenticate the connection (unless key-based authentication is configured).

Set Up Public Key Authentication

Public key authentication provides stronger security than password-based authentication by using cryptographic key pairs. This method eliminates password transmission over the network and enables automated connections without interactive prompts.

Create a new key pair with ssh-keygen if the ~/.ssh directory does not already contain one. Accept the default file path (~/.ssh/id_ed25519) or specify a custom location, then set a strong passphrase when prompted:

ssh-keygen -t ed25519

The command generates a private key (id_ed25519) and public key (id_ed25519.pub) in your ~/.ssh/ directory. Copy the public key to the remote server so it is appended to ~/.ssh/authorized_keys. Replace username@remote_server with your actual SSH login:

ssh-copy-id username@remote_server

If ssh-copy-id is unavailable, manually upload the contents of ~/.ssh/id_ed25519.pub to the server using SFTP or any existing SSH session, then append it to ~/.ssh/authorized_keys on the remote machine.

To connect using public key authentication, specify your private key file with the -i flag:

ssh -i /path/to/private_key username@remote_server

Replace /path/to/private_key with the actual path to your private key file (typically ~/.ssh/id_rsa or ~/.ssh/id_ed25519), username with your remote username, and remote_server with the server’s IP address or hostname.

Verify the key permissions are correct:

ls -l ~/.ssh/id_ed25519

Expected output showing the private key is readable only by you:

-rw------- 1 user user 419 Jan 15 10:00 /home/user/.ssh/id_ed25519

If permissions are incorrect, fix them with:

chmod 600 ~/.ssh/id_ed25519

Specify Custom SSH Port

When the remote server uses a non-standard SSH port, specify it with the -p flag:

ssh -p PORT_NUMBER username@remote_server

Replace PORT_NUMBER with the actual port configured on the remote server. For example, if the server listens on port 2222:

ssh -p 2222 username@remote_server

Transfer Files with SCP

Secure Copy Protocol (SCP) transfers files securely over SSH. To copy a local file to a remote server:

scp /path/to/local/file username@remote_server:/path/to/remote/directory

To copy a directory recursively, add the -r flag:

scp -r /path/to/local/directory username@remote_server:/path/to/remote/directory

For servers listening on a custom SSH port, specify it with the uppercase -P flag (note the capital P, not lowercase):

scp -P 2222 /path/to/local/file username@remote_server:/path/to/remote/directory

Execute Remote Commands

Run commands on a remote server without maintaining an interactive session. Enclose the command in quotes:

ssh username@remote_server 'command_to_run'

For example, to check disk usage on the remote server:

ssh username@remote_server 'df -h'

The command output appears in your local terminal, and the connection closes automatically after execution completes.

Troubleshoot SSH Connection Issues

When SSH connection or authentication issues occur, systematic troubleshooting helps identify the root cause. This section covers common SSH errors and their solutions.

Verify SSH Service Is Running

On Ubuntu 24.04 LTS and 26.04 LTS (socket-activated):

sudo systemctl status ssh.socket

Expected output when the socket is active and listening:

● ssh.socket - OpenBSD Secure Shell server socket
     Loaded: loaded (/lib/systemd/system/ssh.socket; enabled; preset: enabled)
     Active: active (listening)

Check ssh.service as well:

sudo systemctl status ssh.service

On socket-activated systems, ssh.service shows as inactive before any SSH connections have been made. This behavior is expected because the socket handles the listening and triggers the service on demand. You only need to investigate when the socket itself is not active.

Verify the socket is listening on the correct port:

sudo ss -tlnp | grep :22

Expected output showing SSH listening:

LISTEN 0      4096         0.0.0.0:22         0.0.0.0:*    users:(("systemd",pid=1,fd=123))
LISTEN 0      4096            [::]:22            [::]:*    users:(("systemd",pid=1,fd=124))

On Ubuntu 22.04 LTS:

sudo systemctl status ssh

Expected output when the service is running:

● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; enabled; preset: enabled)
     Active: active (running)

Fix Connection Refused Error

If you see “Connection refused” when connecting, the SSH service is not running or the firewall is blocking the port:

ssh: connect to host 192.168.1.100 port 22: Connection refused

Check whether SSH is listening:

sudo ss -tlnp | grep :22

If no output appears, start the SSH service:

sudo systemctl start ssh.socket   # Ubuntu 24.04 LTS and 26.04 LTS
sudo systemctl start ssh          # Ubuntu 22.04 LTS

Verify the service started successfully:

sudo systemctl status ssh.socket  # Ubuntu 24.04 LTS and 26.04 LTS
sudo systemctl status ssh         # Ubuntu 22.04 LTS

If SSH is running but connections fail, check UFW firewall rules:

sudo ufw status

If SSH is not allowed, add a rule:

sudo ufw allow ssh

Resolve Permission Denied (Publickey) Error

This error appears when key-based authentication fails:

Permission denied (publickey).

Verify your key permissions on the client machine. Private keys must be readable only by you:

ls -la ~/.ssh/

Expected permissions:

drwx------  2 user user 4096 Jan 15 10:00 .ssh
-rw-------  1 user user  419 Jan 15 10:00 id_ed25519
-rw-r--r--  1 user user  105 Jan 15 10:00 id_ed25519.pub

Fix permissions if incorrect using chmod:

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

Verify the permissions changed correctly:

ls -l ~/.ssh/id_ed25519

Expected output after fixing:

-rw------- 1 user user 419 Jan 15 10:00 /home/user/.ssh/id_ed25519

On the server, check that your public key exists in ~/.ssh/authorized_keys and that the directory has correct permissions:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

If the problem persists, verify your public key is correctly copied to the server’s authorized_keys file:

cat ~/.ssh/authorized_keys

Each key should appear on a single line starting with the key type (e.g., ssh-ed25519 or ssh-rsa).

Fix Connection Timeout

Connection timeouts indicate network issues, firewall blocks, or incorrect IP addresses:

ssh: connect to host 192.168.1.100 port 22: Connection timed out

Verify the IP address or hostname is correct:

ping 192.168.1.100

If ping fails, the host is unreachable or the IP is incorrect. Check your network configuration. If ping succeeds but SSH times out, verify SSH is listening and accessible using telnet:

telnet 192.168.1.100 22

If the connection succeeds, you see the SSH banner:

Trying 192.168.1.100...
Connected to 192.168.1.100.
Escape character is '^]'.
SSH-2.0-OpenSSH_10.2p1 Ubuntu-2ubuntu1

If telnet times out, check firewall rules on both the client and server, or verify the SSH port number matches your configuration.

Review SSH Authentication Logs

Check the authentication log for detailed error messages when troubleshooting failed connections. Use grep to filter SSH-related entries:

sudo tail -50 /var/log/auth.log | grep sshd

Common log entries and their meanings:

Failed password for user from 192.168.1.50 port 54321 ssh2

This indicates incorrect password attempts. If you see many failed attempts from unknown IPs, consider installing Fail2ban on Ubuntu to automatically block attackers after repeated failures.

Connection closed by authenticating user root 192.168.1.50 port 54321 [preauth]

This appears when root login is disabled and someone attempts to connect as root, confirming your security settings are working correctly.

Test SSH Configuration Syntax

If SSH fails to start after configuration changes, test the syntax for errors:

sudo sshd -t

If the configuration has errors, SSH displays the problem and line number:

/etc/ssh/sshd_config line 42: Bad configuration option: InvalidDirective
/etc/ssh/sshd_config: terminating, 1 bad configuration options

Open /etc/ssh/sshd_config, correct the error on the specified line, then test again until the command returns no output (indicating a valid configuration).

Remove OpenSSH from Ubuntu

If you no longer need the SSH server, remove the packages and clean up configuration files. This section covers complete removal, including host keys, user keys, and firewall rules.

Uninstall OpenSSH Packages

Remove the OpenSSH server package while keeping the client for outbound connections:

sudo apt remove openssh-server

To remove both server and client components along with configuration files, use the purge option:

sudo apt purge openssh-server openssh-client

Remove orphaned dependencies that were installed alongside OpenSSH:

sudo apt autoremove

Remove SSH Configuration and Host Keys

The following commands permanently delete SSH keys and configuration files. Back up any files you may need before proceeding. If you reinstall OpenSSH later, new host keys will be generated, and existing clients will show host key verification warnings when reconnecting.

To remove only the server host keys (preserves your custom sshd_config):

sudo rm /etc/ssh/ssh_host_*

For a complete reset, remove all system-wide SSH configuration and host keys:

sudo rm -rf /etc/ssh

Remove Personal SSH Keys (Optional)

Deleting ~/.ssh removes all your personal SSH keys, including keys used to access GitHub, GitLab, remote servers, and other services. Only proceed if you want to completely reset your personal SSH data. If you only want to remove the known_hosts file to clear old host fingerprints, run rm ~/.ssh/known_hosts instead.

Back up your SSH directory before deletion:

cp -r ~/.ssh ~/.ssh.backup

Then remove the SSH directory (only if you want to completely reset your personal SSH data):

rm -rf ~/.ssh

Remove UFW SSH Rules

If you added firewall rules for SSH, remove them to complete the cleanup:

sudo ufw delete allow ssh
sudo ufw delete allow 2222/tcp   # If you used a custom port

Verify the rules were removed:

sudo ufw status numbered

Verify Complete Removal

Confirm OpenSSH is no longer installed:

dpkg -l | grep openssh

If the package was properly purged, this command returns no output (empty). If you see entries marked rc (removed but config files remain), the output looks like:

rc  openssh-server  1:9.6p1-3ubuntu13  amd64  secure shell (SSH) server

The rc prefix means “removed, config files remain.” Run sudo apt purge openssh-server again to remove the remaining configuration files.

Verify SSH is no longer listening on any ports:

sudo ss -tlnp | grep ssh

This command should return no output, confirming SSH is fully removed.

Frequently Asked Questions

Why does ssh.service show as inactive on Ubuntu 24.04 and 26.04?

This is normal behavior for socket-activated systems. Ubuntu 24.04 and 26.04 use ssh.socket to listen for connections, which only starts ssh.service when a connection arrives. Check ssh.socket status instead – it should show active (listening). The service activates on-demand and may appear inactive until someone connects.

Why doesn’t changing Port in sshd_config work on Ubuntu 24.04?

Socket-activated systems require daemon-reload after port changes. Edit Port in /etc/ssh/sshd_config, test syntax with sshd -t, then run systemctl daemon-reload and systemctl restart ssh.socket. The daemon-reload regenerates socket configuration from sshd_config. Without it, the socket continues listening on the old port.

Can I disable socket activation and use traditional SSH daemon mode?

Yes, but it is not recommended. You can disable ssh.socket with systemctl disable --now ssh.socket and enable ssh.service with systemctl enable --now ssh. However, socket activation improves boot times and resource efficiency. Most users should keep the default socket-activated configuration unless they have specific requirements for persistent daemon mode.

How do I fix permission denied publickey errors after copying SSH keys?

Check file permissions on both client and server. Client private keys need 600 permissions (chmod 600 ~/.ssh/id_ed25519), public keys need 644, and the .ssh directory needs 700. On the server, ~/.ssh/authorized_keys must be 600 and owned by the user. Also verify your public key appears correctly in authorized_keys – each key should be on a single line starting with ssh-ed25519 or ssh-rsa.

What is the difference between OpenSSH and Telnet on Ubuntu?

OpenSSH encrypts all communication including passwords and commands, while Telnet transmits everything in plain text. Telnet is fundamentally insecure for any modern use – anyone monitoring network traffic can see your passwords and data. OpenSSH should always be used instead of Telnet for remote server access. Telnet remains available only for legacy systems or local troubleshooting of network services.

Conclusion

OpenSSH provides secure remote server access with strong encryption and flexible authentication options. This guide covered package installation, security hardening (custom ports, login attempt limits, disabled root login, key-based authentication), and UFW firewall configuration. Ubuntu 24.04 LTS and 26.04 LTS use socket-based activation requiring daemon reloads and socket restarts for port changes, while Ubuntu 22.04 LTS uses traditional service restarts. Your Ubuntu server now accepts hardened SSH connections for secure administration, file transfers, and remote command execution.

Relevant Links

Explore the following external resources for additional information related to the OpenSSH package on Ubuntu.

Leave a Comment

Let us know you are human: