How to Enable SSH Server on Debian 11

As a versatile server OS designed for stability, Debian 11 is a popular choice for hosting web apps, databases, and other network services. However, securely managing a remote server presents cybersecurity risks. The Secure Shell (SSH) protocol enables administrators to securely access Debian servers over the internet, without exposing credentials or sensitive data.

This comprehensive guide will cover installing, configuring, hardening, and troubleshooting the OpenSSH server on Debian 11 for remote server administration.

How SSH Works

Before setting up the SSH server, it helps to understand how SSH connections are securely established between client and server:

1. The SSH client initiates a TCP handshake with the server on port 22, requesting to exchange encryption keys.

2. The server sends its public host key for verification. The client displays the key fingerprint for the user to validate.

3. Once verified, the client generates a symmetric AES-256 session key, encrypts it with the server‘s public key, then sends it.

4. The server decrypts the session key with its private key to enable a symmetrically encrypted tunnel using the one-time session key.

All data transmitted through this tunnel is now securely encrypted between client and server using the negotiated ciphers. The server authenticates the client using a password or SSH key pair.

Installing OpenSSH Server

The OpenSSH server package comes pre-installed on Debian 11. To verify, run:

dpkg -l | grep openssh-server

If not installed already for some reason, run:

sudo apt update
sudo apt install openssh-server

This will install the latest stable OpenSSH server from the Debian repositories.

Starting SSH Service

With OpenSSH installed, enable the sshd service to automatically start on system boot:

sudo systemctl enable ssh

Output:

Synchronizing state of ssh.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable ssh

Then start the sshd service to start it running for the current session:

sudo systemctl start ssh

Verify it is now active:

sudo systemctl status ssh

Output:

● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset:>
     Active: active (running) since Thu 2022-12-22 22:09:56 UTC; 1h 23min ago
       Docs: man:sshd(8)
             man:sshd_config(5)
    Process: 594 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
   Main PID: 12340 (sshd)
      Tasks: 1 (limit: 2353)
     Memory: 5.0M
     CGroup: /system.slice/ssh.service
             └─12340 /usr/sbin/sshd -D

This confirms sshd is running and listening for connections on port 22.

Connecting to SSH

To connect to the SSH server, you need the server‘s IP address and an SSH client. The SSH client comes pre-installed on Linux and macOS. For Windows, install the OpenSSH client from PowerShell.

Once ready to connect, run the following on the client:

ssh user@server_ip

• Replace user with a user that exists on the server
• Substitute server_ip with your server‘s public IP address

Example:

ssh john@192.0.2.10

You‘ll get prompted to verify and accept the host key fingerprint to establish the encrypted tunnel.

Securing OpenSSH Connections

While enabling SSH access is useful, additional steps should be taken to prevent unauthorized access and brute force attacks.

Disable Root Login

Permitting direct root logins via SSH is dangerous and should be prohibited. Disallow root login by editing /etc/ssh/sshd_config:

PermitRootLogin no 

Restart sshd after making changes:

sudo systemctl restart sshd

Now verify root login no longer works over SSH, but your regular user still can connect. This adds a layer of account isolation for security.

Use SSH Key Authentication

By default, SSH uses password authentication which transmits credentials in plaintext. This poses a risk if traffic is intercepted.

A more secure method is public key authentication using asymmetric encryption:

On the client machine, generate an RSA keypair:

ssh-keygen -t rsa

Accept defaults which saves the keys to ~/.ssh/id_rsa and prompts for a passphrase.

Then copy the public key to the ~/.ssh/authorized_keys file on the server:

ssh-copy-id user@server

Finally, edit /etc/ssh/sshd_config on the server and set:

PubkeyAuthentication yes
PasswordAuthentication no

Restart sshd. Users can now authenticate using SSH keys instead of passwords. Private keys remain safely on client devices.

Change the Listening Port

Another simple hardening technique is to change the listening port from the default of 22. Many bots and attacks specifically target port 22.

Edit sshd‘s config file to use a non-standard port like 22222:

Port 22222

Restart sshd, then connect while specifying the new port:

ssh user@server_ip -p 22222

This adds a layer of security through obscurity, hiding the service from generic network scans for port 22.

Restrict Access with UFW Firewall

Leverage Debian‘s Uncomplicated Firewall (UFW) to only allow connections from specific IP addresses.

First enable UFW:

sudo ufw enable

Then allow your client‘s public IP address, while continuing to block all other IPs:

sudo ufw allow from client_ip_address to any port 22222

Now only your explicitly allowed client can connect on the non-standard port. Combine with other hardening measures for defense in depth.

Compare Encryption Algorithms Strength

Algorithm	Key Length	Estimated Brute Force Time
AES-128	128 bits	10^18 years
AES-192	192 bits	10^36 years
AES-256	256 bits	10^56 years
3DES	168 bits	10^25 years
RC4	128 bits	10^18 years
Blowfish	128-448	10^18-10^51 years
RSA	2048+ bits	10^51+ years

AES is proven to be very secure and not feasible to brute force. RSA provides key exchange.
Using AES-256 for the tunnel and RSA-2048 for key exchange offers excellent protection.

SSH Troubleshooting Tips

If running into issues connecting to the SSH server, try the following troubleshooting steps:

1. On the server, check if sshd service is running with systemctl status ssh
2. Verify networking is working between server and client machine
3. Temporarily disable firewalls like UFW to isolate issue
4. Check /var/log/auth.log on server for permission errors
5. Ensure client has server‘s latest SSH host key fingerprint
6. Check that sshd‘s configuration permits your user
7. Try connecting on alternate port in case default port being blocked
8. Generate new SSH keypair on client in case current one compromised

Following methodical troubleshooting steps will allow you to identify and fix SSH problems.

Conclusion

Configuring SSH key-based authentication, disabling root remote access, obscuring the listening port, restricting connections via firewall policies, and using strong encryption protocols hardens Debian‘s out-of-the-box SSH server installation.

With these steps implemented, system administrators can securely manage remote Debian 11 infrastructure over an encrypted SSH tunnel without exposing credentials or sensitive data.

Properly hardened SSH connections coupled with systematic troubleshooting provides resilient remote access to servers, even over untrusted networks.