How to SSH to Raspberry Pi Without a Monitor

Enable SSH on Raspberry Pi without a monitor. Step-by-step headless setup using Raspberry Pi Imager, static IP, SSH keys, and troubleshooting when it fails.

The Pi is sitting on a desk, powered on, green light blinking. No monitor. No keyboard. The plan was to SSH in, but `ssh pi@raspberrypi.local` returns 'Connection refused' or just times out. This is where most first-time headless setups stall.

This guide covers the full path: enabling SSH before first boot, finding the Pi on the network, connecting from Windows, macOS, or Linux, setting up SSH keys so passwords stop mattering, and fixing the things that commonly break. By the end, a monitor is optional, permanently.

What 'Headless' Actually Means Here

Headless means no display, no keyboard, no mouse. The Pi boots, joins the network, and accepts an SSH connection. That is the entire setup. SSH (Secure Shell) is the protocol that opens an encrypted terminal session from another machine to the Pi. Every command typed in that terminal executes on the Pi.

This works over a local network, over a VPN, or over the open internet if ports are configured correctly. For most people reading this, the Pi is on the same LAN as the computer they are connecting from. That is the simple case this guide starts with.

Step 1: Enable SSH Before First Boot

SSH is disabled by default on Raspberry Pi OS. It has been since 2016, when default password logins created a wave of compromised devices. There are two ways to enable it before the Pi has ever booted.

**Option A: Raspberry Pi Imager (recommended).** Download [Raspberry Pi Imager](https://www.raspberrypi.com/software/), select the OS and SD card, then click the gear icon (or press Ctrl+Shift+X) before writing. This opens the 'Advanced options' panel. Check 'Enable SSH', set a username and password or paste a public key, configure Wi-Fi if needed, and set the hostname. Write the card. SSH will be enabled on first boot with those credentials.

**Option B: Manual file method.** After writing the SD card, the boot partition is visible on any computer as a FAT32 volume (usually called 'bootfs' or 'boot'). Create an empty file named exactly `ssh` (no extension) in the root of that partition. On Linux or macOS: `touch /Volumes/bootfs/ssh`. On Windows: create a new text file, rename it to `ssh`, and confirm removing the `.txt` extension. This file is read on boot, SSH is enabled, and the file is deleted. The default user on Raspberry Pi OS Bookworm is 'pi' with no default password set this way, so use Imager instead for clean credential setup.

Raspberry Pi OS Bookworm (released 2023) removed the default 'pi' / 'raspberry' credentials entirely. If using the manual file method, a 'userconf.txt' file is also required in the boot partition containing a username and hashed password. Imager handles this automatically. Use Imager.

Step 2: Get the Pi on the Network

For wired Ethernet: plug in a cable connected to the same router or switch as the computer. The Pi will get a DHCP address automatically. For Wi-Fi: configure the SSID and password in Imager's advanced options before writing the card. The `wpa_supplicant.conf` manual method still works but Imager is cleaner.

A wired connection is more reliable for initial setup. Wi-Fi on Raspberry Pi 4 and 5 requires the correct country code set in Imager or the interface will not bring up. If the Pi is a Compute Module variant without onboard wireless, wired is the only option anyway.

Step 3: Find the Pi's IP Address

This is where most people get stuck. The Pi has an IP address assigned by the router, but there is no screen to read it from.

**Method 1: mDNS hostname.** If the hostname was set to 'raspberrypi' (the default), try `ssh pi@raspberrypi.local` from macOS or Linux. Windows 10 and 11 support mDNS natively. This works on most home networks but fails if there are multiple Pis with the same hostname, or if the network blocks mDNS traffic.

**Method 2: Router DHCP table.** Log into the router admin panel (usually 192.168.1.1 or 192.168.0.1). Look for a DHCP client list or connected devices list. The Pi will appear with its hostname and the assigned IP. This is the most reliable method.

**Method 3: Network scan.** On Linux or macOS: `nmap -sn 192.168.1.0/24` (adjust subnet to match the network). This pings all hosts and lists those that respond. The Pi's MAC address vendor will show as 'Raspberry Pi Trading' or similar. On Windows, 'Advanced IP Scanner' is a free GUI tool that does the same thing.

**Method 4: Serial console.** If none of the above work, a USB-to-TTL serial adapter connected to the Pi's UART pins can give a console login without SSH. This is a fallback, not a first approach.

Assign a static IP via DHCP reservation in the router once the Pi's MAC address is known. This prevents the IP from changing after a reboot and makes all future connections predictable.

Step 4: Connect via SSH

**macOS and Linux.** Open a terminal and run: `ssh username@ip_address` (example: `ssh pi@192.168.1.45`). Accept the host key fingerprint on first connection. Enter the password set during Imager configuration.

**Windows.** Windows 10 (build 1809 and later) and Windows 11 include OpenSSH Client. Open Command Prompt or PowerShell and run the same command: `ssh pi@192.168.1.45`. No third-party tools needed. PuTTY still works if preferred, but it is no longer required.

**Port.** SSH defaults to port 22. If the Pi's SSH is configured to run on a different port, specify it with `-p`: `ssh -p 2222 pi@192.168.1.45`.

Step 5: Set Up SSH Keys

Passwords work, but SSH keys are faster and more secure. Generate a keypair on the connecting machine if one does not exist: `ssh-keygen -t ed25519`. Accept the default path (`~/.ssh/id_ed25519`). Set a passphrase or leave blank.

Copy the public key to the Pi: `ssh-copy-id pi@192.168.1.45`. Enter the password once. After this, `ssh pi@192.168.1.45` connects without a password prompt.

On Windows, `ssh-copy-id` is not built into OpenSSH Client. Run this instead from PowerShell: `type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh pi@192.168.1.45 'cat >> ~/.ssh/authorized_keys'`.

Once key authentication is confirmed to work, disable password authentication on the Pi for better security. Edit `/etc/ssh/sshd_config`, set `PasswordAuthentication no`, and restart SSH with `sudo systemctl restart ssh`. After this, only machines with the private key can connect. This is the correct configuration for any Pi that will be [accessible from the internet or deployed in a field location](raspberry-pi-ssh-unattended-remote-nodes).

Troubleshooting: When SSH Does Not Connect

These are the actual failure modes, in order of how often they occur.

• **SSH not enabled.** The `ssh` file was not present in the boot partition before first boot, or Imager did not write the configuration. Re-flash the card with Imager and confirm the SSH checkbox is checked.
• **Wrong IP address.** The router assigned a different address than expected. Check the DHCP table rather than guessing.
• **Firewall blocking port 22.** Less common on home networks, but some routers have this enabled. Check firewall rules if `nmap` shows the host is up but port 22 is closed.
• **Pi did not finish booting.** The green activity LED will blink during boot. Wait 60 seconds from power-on before attempting to connect. A fast SD card matters here.
• **Hostname collision.** Two Pis with the same hostname on the same network cause mDNS to behave unpredictably. Use IP addresses directly, or set unique hostnames.
• **'Host key verification failed'.** The Pi was re-flashed but the old host key is cached on the connecting machine. Run `ssh-keygen -R raspberrypi.local` or `ssh-keygen -R 192.168.1.45` to clear it.
• **Wrong username.** Raspberry Pi OS Bookworm uses whatever username was set in Imager. 'pi' is the conventional default but is not forced. Check what was typed during setup.
• **Wi-Fi country code not set.** The wireless interface will not initialize without a country code. Re-flash with Imager and set the country in Locale settings.

If `ssh -v pi@192.168.1.45` (verbose mode) shows the connection being refused at the TCP level, the SSH service is not running. If it shows a timeout, the Pi is either unreachable at that IP or the network path is blocked. These two symptoms have different root causes and require different fixes.

Making SSH Persistent Across Reboots and Power Loss

For a Pi that needs to be reliably accessible after unexpected power loss, a few additional configurations matter.

SSH starts automatically at boot via systemd on Raspberry Pi OS. Confirm it is enabled: `sudo systemctl enable ssh`. This is set by default when SSH is enabled through Imager, but worth verifying if the SSH service was ever manually stopped.

File system corruption from unclean shutdowns can break SSH. Using a quality SD card or, better, NVMe via CM4 carrier reduces this risk significantly. An overlay filesystem (read-only root) is the production-grade solution for nodes that must survive abrupt power cycles. See the Raspberry Pi OS documentation on 'overlay file system' in raspi-config.

For devices in locations that are hard to reach physically, consider a static DHCP reservation plus a remote access tunnel (such as [Tailscale](https://tailscale.com) or WireGuard) so the Pi remains reachable even if the local network topology changes. This is covered in more depth for production deployments in [SSH for Raspberry Pi: Headless Access in the Field](ssh-raspberry-pi-headless-field-access).

SSH Config File: Stop Typing Long Commands

The SSH client config file at `~/.ssh/config` (create it if it does not exist) lets connections be aliased. Example entry:

`Host mypi` ` HostName 192.168.1.45` ` User pi` ` IdentityFile ~/.ssh/id_ed25519`

After saving this, `ssh mypi` is all that is needed. This also works with `scp` and `rsync`. For managing multiple Pis or [headless CM4 deployments](raspberry-pi-ssh-setup-headless-cm4), one entry per device keeps connections organized.

Beyond the Home Lab: SSH in Production Deployments

SSH configured on a single Pi on a desk is straightforward. The same setup in a deployed fleet, at a remote site, or inside a panel introduces additional requirements: the device must come back up after power loss without intervention, the network interface must reliably connect before SSH is needed, and physical access for recovery must be planned for or eliminated.

For Compute Module-based deployments where cable count and reliability matter, [Poepi](https://poepi.dev) is a CM4/CM5 carrier that runs power and network over a single Ethernet cable, built for exactly these unattended scenarios.

For cases where SSH alone is not enough, such as a broken bootloader or a misconfigured network interface that prevents SSH from being reachable at all, [IP KVM on CM4](ip-kvm-cm4-headless-remote-access) or a hardware serial console provides out-of-band access. That is a separate layer from SSH, but the two complement each other in serious deployments.