Raspberry Pi sshd: The Beginner's Setup & Security Guide

Understanding the Raspberry Pi sshd Daemon

When diving into single-board computers, one of the first hurdles beginners face is remote access. At the core of this capability is sshd, the OpenSSH server daemon. While 'ssh' refers to the client application you use to connect, 'sshd' is the background service running on your Raspberry Pi that listens for incoming connection requests, handles cryptographic handshakes, and authenticates users.

Whether you are building a headless Home Assistant server, a Pi-hole DNS sinkhole, or a retro gaming console, mastering the raspberry pi sshd configuration is mandatory. This guide moves beyond basic tutorials, providing exact commands, security hardening techniques, and troubleshooting frameworks used by seasoned SBC engineers.

Phase 1: Enabling SSH Before the First Boot (Headless Method)

If you are deploying a Raspberry Pi without a monitor or keyboard (a 'headless' setup), you must enable the sshd daemon before the OS boots for the first time. Historically, this involved mounting the SD card on your PC and creating an empty file named ssh (with no file extension) in the root of the FAT32 boot partition.

However, the modern, safer approach utilizes the Raspberry Pi Imager. This method allows you to pre-configure the sshd service, set a secure username, and inject your public SSH keys simultaneously.

Open Raspberry Pi Imager and select your OS (e.g., Raspberry Pi OS Lite 64-bit).
Select your target SD card or NVMe drive.
Click the Advanced Settings gear icon (or press Ctrl+Shift+X).
Check Enable SSH and choose 'Use password authentication' or 'Allow public-key authentication only'.
Save and write the image. Upon first boot, the ssh.service will automatically start.

Phase 2: Activating sshd on a Running Raspberry Pi

If your Pi is already running with a desktop environment or direct terminal access, enabling the daemon takes only a few seconds. You can use the interactive configuration tool or direct systemd commands.

Method A: The raspi-config Utility

sudo raspi-config

Navigate to Interface Options > SSH and select Yes to enable the server.

Method B: Direct systemd Control (The Debian/Pi OS Quirk)

A common point of confusion for beginners migrating from CentOS or Fedora is the service name. On Raspberry Pi OS (which is Debian-based), the systemd service is typically named ssh, not sshd. Running systemctl status sshd may yield an error. Always use the following commands:

sudo systemctl enable ssh
sudo systemctl start ssh
sudo systemctl status ssh

Phase 3: Hardening Your sshd_config for Real-World Security

Leaving your Raspberry Pi exposed to the internet with default sshd settings is a guaranteed way to end up in a botnet. Automated scripts constantly scan IPv4 ranges for port 22, attempting brute-force attacks on default credentials. To secure your device, you must edit the daemon's configuration file.

Open the configuration file in your preferred text editor:

sudo nano /etc/ssh/sshd_config

Table: Default vs. Hardened sshd Parameters

Directive	Default Value	Hardened Value	Purpose & Impact
Port	22	2222	Moves the daemon off the default port, evading 90% of automated, low-effort botnet scanners.
PermitRootLogin	prohibit-password	no	Completely blocks direct root access. Users must log in as a standard user and use `sudo`.
PasswordAuthentication	yes	no	Disables text passwords entirely, forcing the use of cryptographic SSH keys.
MaxAuthTries	6	3	Drops the connection after 3 failed attempts, severely throttling brute-force scripts.
ClientAliveInterval	0	300	Sends a keep-alive packet every 300 seconds to drop dead/zombie connections.

CRITICAL WARNING: Never set PasswordAuthentication no until you have successfully generated and deployed your SSH key pair. Doing so without a key will permanently lock you out of your headless Raspberry Pi, requiring a physical reflash of the SD card.

After modifying /etc/ssh/sshd_config, always test the syntax before restarting the daemon to prevent lockouts:

sudo sshd -t

If the command returns no output, your syntax is perfect. Restart the service to apply changes:

sudo systemctl restart ssh

Phase 4: Generating and Deploying SSH Key Pairs

To satisfy the PasswordAuthentication no directive, you need an Ed25519 key pair. Ed25519 is vastly superior to older RSA keys, offering faster signature generation and smaller key sizes without compromising security.

On your host computer (not the Pi), generate the key:

ssh-keygen -t ed25519 -C 'pi@homeassistant-local'

Next, push the public key to your Raspberry Pi. If you changed the port to 2222, you must specify it:

ssh-copy-id -p 2222 username@192.168.1.50

You can now log in seamlessly without a password prompt:

ssh -p 2222 username@192.168.1.50

Troubleshooting Common Raspberry Pi sshd Failures

Even with careful configuration, you will eventually encounter connection issues. Here is a professional troubleshooting framework.

1. Connection Refused or Timeout Errors

If your client times out, the network layer or firewall is blocking you. If it says 'Connection Refused', the sshd daemon is not running or is listening on a different port.

Check the daemon status: sudo systemctl status ssh
Verify listening ports: sudo ss -tulpn | grep ssh. Ensure it matches your custom port.
Inspect UFW (Uncomplicated Firewall): If enabled, run sudo ufw allow 2222/tcp.

2. The 'Host Key Verification Failed' Trap

This error occurs when you reflash your Pi's SD card but keep the same IP address. Your host computer remembers the old Pi's cryptographic fingerprint and blocks the connection to prevent Man-in-the-Middle (MitM) attacks.

Fix this by scrubbing the old fingerprint from your host's known_hosts file:

ssh-keygen -R 192.168.1.50

3. Parsing Journalctl for Deep Diagnostics

When sshd fails silently or drops connections immediately after authentication, the standard terminal output won't help. You must query the systemd journal for the ssh service:

sudo journalctl -u ssh.service -n 50 --no-pager

Look for specific PAM (Pluggable Authentication Modules) errors or TCP wrapper rejections. This log will explicitly state if a user was rejected due to a missing public key or an invalid shell path.