How to Enable SSH on Ubuntu

Why Enabling SSH on Ubuntu Matters for Your System Administration

Remote access to your Ubuntu system isn't just a convenience—it's a fundamental requirement for modern server management and development workflows. Whether you're managing a cloud-based server, working from multiple locations, or administering systems for your organization, the ability to securely connect to your Ubuntu machine from anywhere transforms how you interact with your infrastructure. Without proper remote access capabilities, you're tethered to physical proximity, limiting flexibility and responsiveness when issues arise or when you need to perform routine maintenance tasks.

SSH, or Secure Shell, represents the industry-standard protocol for establishing encrypted connections between computers over potentially insecure networks. Unlike older remote access methods that transmitted data in plain text, SSH wraps everything in layers of cryptographic protection, ensuring that your commands, passwords, and data remain confidential even when traveling across the public internet. This article explores multiple approaches to enabling and configuring SSH on Ubuntu systems, addressing various use cases from basic home setups to enterprise-grade security configurations.

Throughout this guide, you'll discover step-by-step instructions for installing and activating SSH services, learn how to configure security settings that protect your system from unauthorized access, and understand troubleshooting techniques when connections don't work as expected. We'll examine firewall configurations, key-based authentication methods, and best practices that balance accessibility with security—giving you the knowledge to implement remote access solutions tailored to your specific requirements and risk tolerance.

Understanding SSH Fundamentals Before Installation

Before diving into configuration commands, grasping what SSH actually does helps you make informed decisions about your setup. The SSH protocol operates on a client-server architecture where one machine (the server) listens for incoming connections while another (the client) initiates the connection request. When you enable SSH on your Ubuntu system, you're essentially configuring it to act as a server that accepts these connection requests.

The OpenSSH package, which Ubuntu uses by default, consists of several components working together. The SSH daemon (sshd) runs continuously in the background, monitoring network traffic for connection attempts on a specific port—typically port 22. When a valid connection request arrives, the daemon handles the authentication process, verifies credentials, and establishes an encrypted communication channel. On the client side, the ssh command-line tool initiates connections and manages the interaction between your local terminal and the remote system.

"Security should never be an afterthought when implementing remote access solutions. The moment you open a port to the network, you create a potential entry point that requires careful management and ongoing vigilance."

Different Ubuntu versions may have slightly varying default configurations, but the core SSH functionality remains consistent across releases. Ubuntu Server editions typically include OpenSSH Server pre-installed since remote administration is expected, while Ubuntu Desktop versions usually require manual installation since they're primarily designed for direct, physical interaction. Understanding this distinction helps you anticipate whether you'll need to install packages or simply enable existing services.

Installing OpenSSH Server on Ubuntu Systems

The installation process begins with ensuring your package repositories contain current information. Opening a terminal window, you'll need to refresh the package index to guarantee you're installing the latest available version of OpenSSH Server. This step prevents potential security vulnerabilities that might exist in outdated packages and ensures compatibility with current authentication standards.

Execute the following command to update your package information:

sudo apt update

After the update completes, proceed with installing the OpenSSH Server package. The apt package manager handles all dependencies automatically, downloading and configuring everything required for SSH functionality:

sudo apt install openssh-server

During installation, the system configures default settings, generates host keys used for encryption, and creates the necessary service files. This process typically completes within a minute or two, depending on your internet connection speed and system performance. The installation script automatically starts the SSH service and configures it to launch automatically whenever your system boots.

Once installation finishes, verify that the SSH service is running correctly with this command:

sudo systemctl status ssh

The output should indicate that the service is active (running) with a green status indicator. If you see any errors or the service shows as inactive, the installation may have encountered issues that require troubleshooting. Common problems include port conflicts with other services or insufficient system permissions.

Verifying SSH Service Status and Functionality

Confirmation that SSH is properly enabled involves more than just checking service status. You'll want to verify that the daemon is actually listening on the expected network port and ready to accept connections. The netstat or ss command provides detailed information about active network listeners on your system.

Check which ports SSH is monitoring with this command:

sudo ss -tulpn | grep ssh

This command filters network statistics to show only SSH-related listeners. You should see an entry indicating that sshd is listening on port 22 (or whatever custom port you've configured) for both IPv4 and IPv6 connections. The output displays the local address, port number, and the process ID of the SSH daemon.

"Testing connectivity from the local machine first eliminates network variables and confirms that the SSH service itself is functioning correctly before investigating firewall or routing issues."

Testing a connection from the local system itself provides immediate feedback about SSH functionality without introducing network complexity. Attempt to connect to localhost using this command:

ssh localhost

If this is your first connection, you'll see a message about the authenticity of the host and a fingerprint of the server's key. Type "yes" to continue, then enter your user password when prompted. Successfully logging in confirms that SSH is accepting connections and authenticating users properly. Exit the session by typing exit or pressing Ctrl+D.

Configuring Firewall Rules for SSH Access

Ubuntu systems running the UFW (Uncomplicated Firewall) require explicit rules allowing SSH traffic through the firewall. Even with SSH running perfectly, blocked firewall ports prevent external connections from reaching your system. Configuring these rules correctly balances security with accessibility, allowing legitimate connections while blocking unauthorized access attempts.

Check your current firewall status first:

sudo ufw status

If the firewall is inactive, you might consider enabling it for enhanced security, though this requires careful rule configuration to avoid locking yourself out. When the firewall is active, you'll see a list of currently allowed services and ports. If SSH isn't listed, you need to add it explicitly.

Allow SSH connections through the firewall with this command:

sudo ufw allow ssh

Alternatively, if you've configured SSH to use a non-standard port, specify the port number directly:

sudo ufw allow 2222/tcp

After modifying firewall rules, reload UFW to apply the changes:

sudo ufw reload

Verify that the SSH rule appears in your firewall configuration by checking the status again. The output should show SSH or your custom port number in the list of allowed services, indicating that incoming connections on that port will pass through the firewall to reach the SSH daemon.

Advanced Firewall Configuration Options

🔒 Limiting connection attempts helps protect against brute-force attacks by restricting the number of connection attempts from a single IP address within a specific timeframe. The UFW limit rule automatically blocks addresses that attempt more than six connections within thirty seconds:

sudo ufw limit ssh

🌐 Restricting access by IP address provides additional security when you know which networks should have SSH access. This approach works well for static IP addresses or known network ranges:

sudo ufw allow from 192.168.1.0/24 to any port 22

🛡️ Denying all other traffic creates a default-deny policy where only explicitly allowed services can receive incoming connections. This security-first approach minimizes your attack surface:

sudo ufw default deny incoming

⚡ Allowing specific protocols enables you to differentiate between TCP and UDP traffic, though SSH exclusively uses TCP. Being explicit about protocols follows security best practices:

sudo ufw allow 22/tcp

📝 Commenting firewall rules helps document why specific rules exist, making future administration easier. While UFW doesn't support inline comments, maintaining separate documentation of rule purposes proves invaluable for complex configurations.

Establishing Your First Remote SSH Connection

With SSH enabled and firewall rules configured, you're ready to connect from another machine. The basic SSH connection syntax requires specifying the username and hostname or IP address of the target system. Understanding this syntax and its variations allows you to adapt connections for different scenarios and authentication methods.

The standard connection command follows this format:

ssh username@hostname_or_ip

For example, connecting to a server with IP address 192.168.1.100 as user "admin" would look like:

ssh admin@192.168.1.100

During your first connection to a new server, SSH displays the server's key fingerprint and asks you to verify its authenticity. This security measure helps prevent man-in-the-middle attacks where a malicious actor intercepts your connection. In a trusted environment, you can accept this fingerprint by typing "yes" when prompted. The fingerprint is then stored in your local known_hosts file for future verification.

"The first connection to any SSH server represents a trust decision. In high-security environments, verifying the server's fingerprint through an out-of-band communication channel before accepting it prevents sophisticated interception attacks."

After accepting the fingerprint, SSH prompts for the password associated with the specified username. Enter your password carefully—SSH typically allows three authentication attempts before disconnecting. Once authenticated successfully, you'll see a command prompt indicating you're now operating on the remote system. Any commands you type execute on that remote machine rather than your local computer.

Connection Troubleshooting When Access Fails

When SSH connections fail, systematic troubleshooting identifies the problem quickly. Start by verifying basic network connectivity using ping to ensure the target system is reachable across the network. If ping fails, the issue lies in network configuration, routing, or the remote system being offline rather than with SSH specifically.

Confirm the SSH service is running on the remote system. If you have physical or console access, check the service status directly. Without direct access, attempt to telnet to port 22 to verify something is listening:

telnet remote_host 22

If the connection succeeds, you should see SSH version information. If it times out or is refused, either SSH isn't running, the firewall is blocking connections, or you're attempting to connect to the wrong port. Check verbose SSH output for detailed connection information:

ssh -v username@hostname

The verbose output shows each step of the connection process, revealing where failures occur. Multiple levels of verbosity exist (-vv, -vvv) providing increasingly detailed information useful for diagnosing complex issues.

Implementing Key-Based Authentication for Enhanced Security

Password authentication, while convenient, represents a security vulnerability. Passwords can be guessed, intercepted, or compromised through various attack vectors. Key-based authentication eliminates these risks by using cryptographic key pairs—a private key you keep secure and a public key you place on servers you want to access. This authentication method provides substantially stronger security while simultaneously improving convenience since you won't need to enter passwords for each connection.

Generate an SSH key pair on your local machine (the client) using the ssh-keygen utility:

ssh-keygen -t rsa -b 4096

This command creates a 4096-bit RSA key pair, which provides excellent security for most use cases. The utility prompts you to specify a location for saving the keys—pressing Enter accepts the default location (~/.ssh/id_rsa). You'll then have the option to set a passphrase protecting the private key. While optional, using a passphrase adds an additional security layer, requiring both possession of the key file and knowledge of the passphrase for authentication.

After generation completes, you'll have two files: the private key (id_rsa) which must remain secure and never be shared, and the public key (id_rsa.pub) which you'll copy to servers you want to access. The next step involves transferring your public key to the remote server.

Copy your public key to the remote server using the ssh-copy-id utility, which handles the process automatically:

ssh-copy-id username@remote_host

This command prompts for your password one final time, then appends your public key to the remote server's authorized_keys file. Future connections will authenticate using your private key instead of requiring password entry. If ssh-copy-id isn't available, you can manually append your public key to the remote ~/.ssh/authorized_keys file.

Disabling Password Authentication After Key Setup

Once key-based authentication works reliably, disabling password authentication entirely eliminates the risk of password-based attacks. This configuration change requires editing the SSH daemon configuration file on the server. Before making this change, ensure you can successfully connect using key-based authentication and have a backup access method available in case something goes wrong.

Edit the SSH configuration file with elevated privileges:

sudo nano /etc/ssh/sshd_config

Locate the line containing "PasswordAuthentication" and modify it to:

PasswordAuthentication no

Additionally, ensure that public key authentication is explicitly enabled:

PubkeyAuthentication yes

After saving your changes, restart the SSH service to apply the new configuration:

sudo systemctl restart ssh

"Disabling password authentication transforms your SSH security posture dramatically, but only implement this change after thoroughly testing key-based access and establishing emergency access procedures."

Test your connection from another terminal session before closing your existing connection. This precaution ensures you haven't accidentally locked yourself out. If key-based authentication fails after the configuration change, you'll need console access to revert the settings.

Customizing SSH Configuration for Specific Requirements

The SSH daemon configuration file (/etc/ssh/sshd_config) contains numerous options controlling server behavior. Understanding these settings allows you to tailor SSH functionality to your specific security requirements and operational needs. While default settings work adequately for many situations, customization often provides significant security or usability improvements.

Common configuration modifications include changing the listening port, restricting which users can connect, and adjusting timeout values. Each modification serves specific purposes—port changes reduce automated attack attempts, user restrictions limit potential attack vectors, and timeout adjustments balance security with usability.

Changing the Default SSH Port

Running SSH on a non-standard port reduces exposure to automated scanning and brute-force attacks targeting port 22. While this provides "security through obscurity" rather than true security improvement, it dramatically reduces log noise and server load from constant attack attempts. Choose a port number above 1024 to avoid conflicts with well-known services.

Edit the SSH configuration file and locate the Port directive:

Port 2222

After changing the port, update your firewall rules to allow traffic on the new port and optionally remove the rule for port 22. Remember to specify the custom port when connecting:

ssh -p 2222 username@hostname

Restricting Root Login Access

Allowing direct root login via SSH creates unnecessary security risks. Attackers know the root username exists on all systems, eliminating half the authentication puzzle. Disabling root login forces attackers to guess both a valid username and password, significantly increasing difficulty.

Modify the PermitRootLogin directive in the configuration file:

PermitRootLogin no

With this setting, users must connect with regular accounts and use sudo for administrative tasks. This approach provides better accountability through audit logs showing which user performed administrative actions. Alternatively, setting this to "prohibit-password" allows root login via key-based authentication while blocking password attempts.

Implementing Connection Timeout Settings

Idle SSH sessions consume server resources and potentially expose systems if users leave authenticated sessions unattended. Configuring timeout values automatically disconnects inactive sessions after specified periods. Two parameters work together to control this behavior: ClientAliveInterval and ClientAliveCountMax.

Add or modify these settings in sshd_config:

ClientAliveInterval 300
ClientAliveCountMax 2

These settings send keepalive messages every 300 seconds (5 minutes). If the client fails to respond after 2 messages (10 minutes total), the server terminates the connection. Adjust these values based on your usage patterns and security requirements.

Limiting User Access to Specific Accounts

Restricting SSH access to specific users or groups reduces your attack surface by limiting potential targets. This configuration proves particularly valuable on systems with many local accounts where only a subset requires remote access capabilities.

Use the AllowUsers directive to specify permitted accounts:

AllowUsers admin developer

Alternatively, use AllowGroups to permit all members of specific groups:

AllowGroups ssh-users

The DenyUsers and DenyGroups directives provide inverse functionality, explicitly blocking specified accounts or groups. When both allow and deny directives exist, deny rules take precedence.

"Every configuration change to SSH requires careful testing before closing your current session. Maintaining an active connection while testing new settings from a separate terminal prevents accidental lockouts."

Monitoring SSH Access and Security Events

Tracking who connects to your system and identifying suspicious activity forms an essential component of SSH security. Ubuntu logs all SSH authentication attempts and connections, providing valuable information for security auditing and troubleshooting. Regular log review helps identify unauthorized access attempts, compromised accounts, and configuration issues.

SSH logs are typically stored in /var/log/auth.log on Ubuntu systems. View recent SSH activity with this command:

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

This command filters the authentication log for SSH-related entries and displays the most recent 50 lines. Successful connections show "Accepted password" or "Accepted publickey" entries, while failed attempts appear as "Failed password" messages. Patterns of repeated failures from the same IP address often indicate brute-force attack attempts.

Implementing Fail2Ban for Automated Protection

Fail2Ban monitors log files for suspicious patterns and automatically implements temporary firewall rules blocking offending IP addresses. This automated response system significantly reduces the impact of brute-force attacks without requiring manual intervention. Installing and configuring Fail2Ban provides an additional security layer complementing strong authentication methods.

Install Fail2Ban using the package manager:

sudo apt install fail2ban

After installation, Fail2Ban automatically monitors SSH logs using default settings that work well for most situations. The default configuration bans IP addresses for 10 minutes after 5 failed login attempts within 10 minutes. Customize these settings by creating a local configuration file:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

Locate the [sshd] section and adjust parameters as needed:

enabled = true
port = ssh
maxretry = 3
bantime = 3600

These settings enable SSH protection, monitor the standard SSH port, ban after 3 failed attempts, and maintain bans for 1 hour. Restart Fail2Ban after configuration changes:

sudo systemctl restart fail2ban

Advanced SSH Features and Capabilities

Beyond basic remote shell access, SSH provides powerful features enabling secure file transfers, port forwarding, and tunneling. Understanding these capabilities expands SSH's utility far beyond simple command-line access, making it an indispensable tool for various networking and administrative tasks.

Secure File Transfer with SCP and SFTP

SSH includes protocols for transferring files securely between systems. SCP (Secure Copy Protocol) provides command-line file copying similar to the traditional cp command but operating across network connections. SFTP (SSH File Transfer Protocol) offers more sophisticated file management capabilities including directory listing, file deletion, and resume functionality for interrupted transfers.

Copy a file to a remote system using SCP:

scp localfile.txt username@remote_host:/path/to/destination/

Copy a file from a remote system to your local machine:

scp username@remote_host:/path/to/file.txt /local/destination/

Transfer entire directories recursively using the -r flag:

scp -r /local/directory username@remote_host:/remote/path/

SFTP provides an interactive file transfer session similar to traditional FTP but with SSH encryption:

sftp username@remote_host

Within the SFTP session, use commands like get, put, ls, cd, and rm to manage files on both local and remote systems.

SSH Port Forwarding and Tunneling

Port forwarding creates encrypted tunnels routing traffic through SSH connections. This capability enables secure access to services running on remote networks, bypassing firewall restrictions, and encrypting otherwise insecure protocols. Three types of port forwarding exist: local, remote, and dynamic.

Local port forwarding redirects connections to a local port through the SSH connection to a remote destination. This technique allows accessing remote services as if they were running locally:

ssh -L 8080:localhost:80 username@remote_host

This command forwards local port 8080 through the SSH connection to port 80 on the remote host. Accessing localhost:8080 on your local machine actually connects to port 80 on the remote system through the encrypted tunnel.

Remote port forwarding works inversely, making services on your local machine accessible from the remote system:

ssh -R 9090:localhost:3000 username@remote_host

This forwards port 9090 on the remote host to port 3000 on your local machine, useful for allowing remote access to locally-running development servers.

Dynamic port forwarding creates a SOCKS proxy, routing all traffic from applications configured to use it through the SSH tunnel:

ssh -D 1080 username@remote_host

Configure your web browser or other applications to use localhost:1080 as a SOCKS proxy, and all their traffic routes through the encrypted SSH tunnel.

"SSH tunneling transforms the protocol from a simple remote access tool into a versatile networking swiss army knife, enabling secure communication channels for virtually any TCP-based protocol."

Maintaining SSH Security Over Time

Security isn't a one-time configuration but an ongoing process requiring regular attention and updates. SSH implementations occasionally have vulnerabilities discovered, configuration best practices evolve, and your security requirements may change. Establishing maintenance routines ensures your SSH access remains both functional and secure.

Regularly update your system packages to receive security patches:

sudo apt update && sudo apt upgrade

This command updates package information and installs available updates, including security fixes for OpenSSH and related components. Consider enabling automatic security updates for critical patches, though manual updates provide more control over when changes occur.

Periodically review authorized_keys files to ensure only current, legitimate public keys have access. Remove keys for former employees, decommissioned systems, or keys you no longer use:

nano ~/.ssh/authorized_keys

Each line in this file represents one authorized public key. Delete entire lines to revoke access for specific keys. Consider adding comments identifying key owners and purposes to simplify future audits.

Rotating SSH Host Keys

SSH host keys identify your server to connecting clients. If these keys become compromised, attackers could impersonate your server. While rare, rotating host keys periodically or after suspected compromise improves security. This process requires careful communication since clients will see warnings about changed host keys.

Remove existing host keys:

sudo rm /etc/ssh/ssh_host_*

Generate new host keys:

sudo ssh-keygen -A

Restart the SSH service:

sudo systemctl restart ssh

After rotation, connecting clients will display warnings about changed host keys. Users must remove old fingerprints from their known_hosts files before connecting. Communicate key changes to legitimate users to distinguish this expected warning from potential security incidents.

Troubleshooting Common SSH Issues

Despite careful configuration, SSH connections sometimes fail or behave unexpectedly. Systematic troubleshooting identifies problems quickly, minimizing downtime and frustration. Understanding common issues and their solutions enables rapid problem resolution.

Permission Denied Errors

Permission denied errors typically indicate authentication failures. Several factors might cause this issue. Verify you're using the correct username—SSH usernames must match accounts on the remote system exactly, including case sensitivity. Confirm your password is correct, remembering that SSH typically allows only three authentication attempts before disconnecting.

For key-based authentication failures, check that your private key has correct permissions. SSH refuses to use private keys with overly permissive access:

chmod 600 ~/.ssh/id_rsa

Verify your public key exists in the remote system's authorized_keys file and that the file has appropriate permissions:

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

Connection Timeout Issues

Connection timeouts suggest network connectivity problems or firewall blocking. Verify basic network connectivity using ping. If ping succeeds but SSH times out, firewall rules likely block SSH traffic. Check both local and remote firewall configurations, ensuring rules allow traffic on the SSH port.

Network address translation (NAT) or routing issues might prevent connections in complex network environments. Verify you're connecting to the correct IP address—systems behind NAT require connecting to their public IP address rather than private addresses. Port forwarding configurations on routers must direct SSH traffic to the appropriate internal system.

Too Many Authentication Failures

When SSH presents multiple keys during authentication and the server rejects them all, you might see "Too many authentication failures" errors. This occurs when you have numerous private keys and the server's MaxAuthTries limit is exceeded before presenting the correct key.

Specify which private key to use explicitly:

ssh -i ~/.ssh/specific_key username@hostname

Alternatively, configure your SSH client to use specific keys for specific hosts by editing ~/.ssh/config:

Host remote_host
HostName 192.168.1.100
User username
IdentityFile ~/.ssh/specific_key
IdentitiesOnly yes

Connection Drops or Hangs

SSH connections that drop unexpectedly or hang without responding often result from network instability or aggressive timeout settings. Configure keepalive messages in your client configuration to maintain connections through periods of inactivity:

Edit ~/.ssh/config and add:

Host *
ServerAliveInterval 60
ServerAliveCountMax 3

These settings send keepalive messages every 60 seconds, disconnecting only after three consecutive failures. This configuration prevents most timeout-related disconnections while still eventually terminating truly dead connections.

SSH Configuration Best Practices Summary

Implementing SSH securely requires balancing accessibility with security. Following established best practices creates robust remote access while minimizing vulnerability to attacks. Consider these recommendations when configuring SSH on your Ubuntu systems.

• Use key-based authentication exclusively whenever possible, disabling password authentication entirely after confirming key-based access works reliably
• Change the default SSH port to reduce automated attack attempts and log noise, though remember this provides only minimal actual security improvement
• Disable root login via SSH forcing users to connect with regular accounts and use sudo for administrative tasks, improving accountability and security
• Implement Fail2Ban or similar tools to automatically respond to brute-force attack attempts by temporarily blocking offending IP addresses
• Keep systems updated with security patches, especially for OpenSSH and related components that form your remote access infrastructure
• Monitor authentication logs regularly to identify suspicious activity, unauthorized access attempts, and potential security incidents requiring investigation
• Use strong passphrases on private keys to protect them from unauthorized use if the key files are compromised
• Restrict SSH access to specific users or groups who actually require remote access capabilities rather than allowing all system accounts
• Configure appropriate timeout values to automatically disconnect idle sessions while avoiding premature disconnections during legitimate use
• Regularly audit authorized_keys files removing obsolete keys for former users or decommissioned systems that no longer require access

Frequently Asked Questions About SSH on Ubuntu

How do I check if SSH is already installed on my Ubuntu system?

Run the command dpkg -l | grep openssh-server to check if the OpenSSH server package is installed. If installed, you'll see package information including version number. Alternatively, try checking the service status with sudo systemctl status ssh—if the command returns service information rather than an error, SSH is installed. Ubuntu Server editions typically include SSH by default, while Desktop editions usually require manual installation.

Can I use SSH to connect from Windows to Ubuntu?

Yes, Windows 10 and 11 include a built-in SSH client accessible from Command Prompt or PowerShell using the same ssh command syntax as Linux systems. For older Windows versions or enhanced functionality, consider third-party clients like PuTTY, which provides a graphical interface for managing SSH connections, or Windows Subsystem for Linux (WSL) which includes native SSH tools. The connection process remains identical regardless of client operating system—specify username and hostname or IP address.

What should I do if I forget my SSH password?

SSH passwords are the same as your Ubuntu user account passwords. If you have physical or console access to the system, log in directly and change your password using the passwd command. Without direct access, you'll need someone with administrative privileges on that system to reset your password. This situation highlights why key-based authentication proves valuable—you can store backup copies of private keys securely, though you must still remember passphrases if you've set them.

How can I transfer files between systems using SSH?

SSH provides two primary file transfer methods: SCP for simple copying operations and SFTP for more complex file management. Use SCP for straightforward file transfers with syntax like scp file.txt user@host:/destination/. For interactive file management with capabilities like browsing directories and resuming interrupted transfers, use SFTP by running sftp user@host which provides an interactive session with commands similar to traditional FTP. Both methods encrypt all data during transfer using SSH encryption.

Is it safe to enable SSH on a server exposed to the internet?

SSH can be safely exposed to the internet when properly configured with strong security measures. Essential precautions include disabling password authentication in favor of key-based authentication, changing from the default port to reduce automated attacks, implementing Fail2Ban to block brute-force attempts, keeping systems updated with security patches, and monitoring logs for suspicious activity. Many servers run SSH exposed to the internet successfully by following these security practices. However, if your use case allows it, restricting SSH access to specific IP addresses or VPN connections provides additional security layers.