Secure remote access to elementary OS with SSH keys

Setting up SSH keys and remote access to elementary OS lets you operate a desktop from another computer without exposing its graphical login screen. SSH creates an encrypted terminal connection, while public-key authentication proves possession of a private key instead of sending your account password with every login. This is useful when an elementary OS computer acts as a home server, development machine or quiet workstation.

Think of the pair as a matched lock and key. The public key can live in the remote account’s ~/.ssh/authorized_keys file; the private key stays on the computer used to connect. A passphrase can protect that private key if the file is stolen. This separation supports revocable access and scripted jobs without relying on a password that may be weak, reused or awkward to rotate.

The workflow below uses OpenSSH from elementary OS’s Ubuntu-compatible package repositories. You will prepare the remote computer, create a key pair on a client, authorise its public key, and choose how the connection crosses your network. Keep physical or provider-console access until key-only sign-in has been tested; it provides a recovery path if a firewall or configuration change locks you out.

Why key-based SSH suits elementary OS

Remote administration over SSH is not desktop sharing. It provides terminal access to the same users, files and applications managed by elementary OS, and administration can use familiar tools such as apt and systemctl. The traffic is lightweight, making SSH practical on metropolitan NBN connections and regional fixed-wireless links as well as fast fibre services.

Password-only SSH can be secured, but every internet-facing server remains subject to automated sign-in attempts. A modern Ed25519 key is designed to resist brute-force attacks, and access can be granted or removed one authorised key at a time. Keys also suit automated backup jobs, although they do not remove the need to patch the operating system and the SSH daemon.

Create a normal user for daily work and use sudo for privileged commands rather than logging in as root. Keep the original session open while testing changes in a second terminal. SSH configuration affects new connections, so an established session is not dependable recovery when a firewall or daemon setting is wrong.

Prepare the remote elementary computer

On the elementary OS computer that will receive connections, open Terminal. Record the login name and local address, then install the OpenSSH server:

whoami
hostname -I
sudo apt update
sudo apt install openssh-server

If hostname -I lists several addresses, use the IPv4 address on the same local network as the client. The login shown by whoami is the account that will own the SSH key and receive incoming connections.

Enable the service at boot and check its current state. The status should include active (running); if it does not, read the reported error before proceeding.

sudo systemctl enable --now ssh
systemctl status ssh

If UFW is active, allow OpenSSH and inspect the result. An inactive firewall is not a broken SSH setup; it simply means UFW is not enforcing rules. If policy requires UFW, enable it only after permitting SSH. The graphical elementary OS Firewall can create the equivalent incoming rule.

sudo ufw allow OpenSSH
sudo ufw status verbose

Create and install the key pair

On the client computer, which may be another elementary OS installation, a Linux system or macOS, ensure the OpenSSH client is present and generate a key pair:

ssh -V
ssh-keygen -t ed25519 -C "elementary-admin"

Accept the default file location when prompted. The private key remains under ~/.ssh and must never be copied to the server. Give it a strong passphrase, especially on a portable computer; the passphrase protects the local private-key file and is not sent to the remote system.

While password sign-in is still available, copy the public key to the server, replacing the example name and address:

ssh-copy-id yourusername@192.168.1.50

If ssh-copy-id is unavailable, use this manual fallback once:

cat ~/.ssh/id_ed25519.pub | ssh yourusername@192.168.1.50 \
  'umask 077; mkdir -p ~/.ssh; cat >> ~/.ssh/authorized_keys'

Check permissions on the server, then test from a new terminal on the client. The directory must be private and the authorisation file readable only by its owner. If sign-in fails, confirm ownership as well as these modes while signed in locally. Do not disable password authentication until the key works.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
ssh yourusername@192.168.1.50

Configure the SSH server safely

After a successful key login, make key-only access the server policy. Open the effective SSH configuration for editing:

sudoedit /etc/ssh/sshd_config

If the main file includes files from /etc/ssh/sshd_config.d, check those drop-ins too because an earlier matching directive can take precedence. Add or change these values in the global section:

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
AuthenticationMethods publickey

Validate the syntax, inspect the effective values and reload rather than restart. An empty result from the syntax test means the file parses correctly. Open a second client terminal and reconnect before closing the original session.

sudo sshd -t
sudo sshd -T | grep -E 'permitrootlogin|pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|authenticationmethods'
sudo systemctl reload ssh

An AllowUsers directive can restrict sign-in to named accounts, and Fail2ban can reduce repeated attacks, although neither is essential once key-only access works. Keep the SSH daemon and elementary OS packages updated. Moving the daemon to another port may reduce scanner noise, but obscurity is not security and every client must use the new port.

Connect across Australian home networks

Outside the local network, the internet does not normally know which device owns your private address. Give the server a DHCP reservation based on its MAC address so an address such as 192.168.1.50 stays stable. In homes in Sydney, Melbourne, Brisbane or Perth, the router gateway is often 192.168.1.1, although its documentation is more reliable than that assumption. Menus on routers supplied by Telstra, Optus and Aussie Broadband vary, but look for DHCP reservation, port forwarding and dynamic DNS.

Create a router rule that forwards external TCP port 22 to 192.168.1.50:22 on the server’s private address. Forward only SSH, not the router administration service, and avoid placing the computer in the router’s DMZ. Test from a phone using mobile data rather than the same Wi-Fi network. An outside client then uses ssh yourusername@public-address. If you change the listening port, update both the firewall and every client’s connection details.

Some Australian NBN connections, along with many fixed-wireless and mobile broadband services, sit behind carrier-grade NAT. A port-forwarding rule can look correct while traffic never arrives because the router shares one public IPv4 address with other customers. Compare the router’s WAN address with a public IP lookup; if they differ, ask the ISP whether it can supply a public IPv4, use a full VPN, or install an overlay network client such as Tailscale or ZeroTier on both machines. IPv6 can also provide direct reachability, but only when the service supplies it and the firewall is configured deliberately.

If the public address changes, dynamic DNS keeps a memorable name current. For an Australian .au domain, a subdomain such as ssh.example.au can carry an A record for IPv4 or AAAA for IPv6. Point it at the reachable public address and let the router or a trusted updater refresh it. DNS supplies the address; it does not create the port-forwarding or firewall permission.

Operate and troubleshoot the connection

A client alias removes repeated server details. Put this in ~/.ssh/config, replacing the example values:

Host elementary-box
    HostName 192.168.1.50
    User yourusername
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Use the local address on your LAN or the dynamic DNS name while away, then connect with ssh elementary-box. Restrict the client file to your own account:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/config

Keep an encrypted backup of the private key in more than one secure place. The public key can be copied to each server account, but the private key belongs only with authorised clients. When SSH reports an unknown or changed host key, verify it instead of accepting it automatically. At the elementary OS console, compare the presented fingerprint with ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub.

Use ssh -v yourusername@ssh.example.au to separate authentication failures from routing failures. A timeout points towards Wi-Fi isolation, router forwarding, DNS or carrier-grade NAT; Permission denied points towards the account, key selection or server permissions. A successful local connection followed by an external timeout is strong evidence that the server itself is healthy. Review diagnostic logs before sharing them because they can contain usernames and file paths.

Australian systems span several time zones, including AEST/AEDT, ACST/ACDT and AWST. Daylight-saving changes do not alter SSH authentication, but accurate time keeps audit trails and time-based safeguards aligned. Check synchronisation with timedatectl status and use sudo timedatectl set-ntp true when appropriate. The practical access choices can be compared as follows:

Access method	Authentication	Network requirement	Advantage	Trade-off
Password-only SSH	User password	Public address and forwarding, or a VPN	Simple when keys cannot be used	Brute-force exposure and awkward automation
Key-only SSH	Private key, usually unlocked by a local passphrase	Public IPv4 and forwarding, or reachable IPv6	Strong standard authentication with revocable keys	The port remains discoverable when forwarded
Key-only over an overlay	Private key plus device membership in the overlay	Both machines reach the coordination service; normally no inbound rule	Works cleanly through CGNAT	Adds a client and trust in the overlay operator
VPN then SSH keys	VPN credentials plus a private key	Reachable VPN gateway	Hides SSH behind a private network	More configuration and potentially more latency

---

A dependable arrangement has three linked parts: the correct public key in the remote account, a safely configured SSH daemon, and a network path that reaches the intended machine. Recovery access should remain available until every change has survived a fresh login, including one made from outside the local network.

The private key stays with its authorised client, the public key can be replaced or revoked, and password-only access can be disabled after testing. Routine maintenance still matters because a stale client, altered account or broken router rule can end an otherwise sound connection.

Remember that reliable SSH access rests on a protected private key, the correct public key on the server, current software on both systems, and a network path that reaches a properly configured sshd service.