How to Use SSH Keys for Passwordless Login on Ubuntu

SSH keys provide a safer and more convenient way to connect to an Ubuntu computer, server, virtual machine, or Raspberry Pi without typing the account password every time. Instead of proving your identity with a reusable password, your SSH client uses a private key stored on your device and a matching public key saved on the remote system.

This setup is useful for Ubuntu users managing a home server over an NBN connection, maintaining a cloud instance in an Australian data centre, or accessing a desktop from a laptop while working in Melbourne, Sydney, or Brisbane. “Passwordless” does not have to mean unprotected: your private key can have a passphrase, while an SSH agent remembers it during your session.

How SSH Keys Authenticate Your Connection

An SSH key pair contains two related files. The private key stays on your local Ubuntu computer and must never be uploaded or emailed. The public key can be copied to servers, shared with hosting providers, and placed in the remote account’s ~/.ssh/authorized_keys file.

During login, the SSH server sends a challenge that can be answered only with the private key corresponding to the stored public key. Your private key is not transmitted across the network. This makes key-based authentication considerably harder to attack through password guessing, especially when the server is exposed to the internet.

A passphrase protects the private key if somebody obtains a copy of the file. You enter the passphrase when loading the key into an SSH agent, rather than for every connection. If you are connecting from a shared office, university, or café network, SSH still encrypts the session, but the security of the endpoint and the private key remains your responsibility.

Before starting, make sure you have:

• An Ubuntu computer with the OpenSSH client installed
• A remote Ubuntu or Linux system running an SSH server
• The remote username and hostname or IP address
• An existing way to log in, usually the account password
• Permission to modify the remote account

For a home server, a local address such as 192.168.1.50 may work inside your network. Connecting from outside the house requires more planning. Many NBN services use changing public IP addresses, and some connections use carrier-grade NAT, which prevents direct inbound connections unless your provider offers a suitable option.

Create An Ed25519 Key Pair

Open Terminal on your Ubuntu machine and run:

ssh-keygen -t ed25519 -C "ubuntu-laptop"

The -t ed25519 option creates a modern, compact key type supported by current Ubuntu releases. The comment helps identify the key later; it is only a label and does not affect authentication. When prompted for a file location, press Enter to use the default path:

/home/your-name/.ssh/id_ed25519

You will then be asked for a passphrase. Set one unless the key will be used by an unattended process that cannot respond to a prompt. A strong, memorable passphrase is generally more practical than a short password. Never send the private key file to a server; only the .pub file belongs on the remote system.

The command creates two files:

~/.ssh/id_ed25519       private key
~/.ssh/id_ed25519.pub   public key

Check their permissions with:

ls -l ~/.ssh

The private key should be readable only by your user. If required, correct the permissions with:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

If you already have keys in ~/.ssh, do not overwrite them without checking what uses them. You can create a separate key with a custom filename, such as ~/.ssh/id_ed25519_server, to keep access to Git hosting, work systems, and personal servers separate.

Copy The Public Key To Ubuntu

The simplest method is ssh-copy-id. Replace the example username and address with those for your server:

ssh-copy-id username@server-address

Enter the remote account password when prompted. The utility appends your public key to the remote user’s ~/.ssh/authorized_keys file and applies suitable directory and file settings. Test the new key immediately:

ssh username@server-address

If you created a key with a non-default filename, specify it explicitly:

ssh-copy-id -i ~/.ssh/id_ed25519_server.pub username@server-address
ssh -i ~/.ssh/id_ed25519_server username@server-address

You can also copy the key manually if ssh-copy-id is unavailable. Display the public key with:

cat ~/.ssh/id_ed25519.pub

Copy the entire single line, including the ssh-ed25519 beginning and the identifying comment. On the server, create the SSH directory and append the key:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys

Paste the key on its own line, save the file, and then run:

chmod 600 ~/.ssh/authorized_keys

Do not paste the private key, which is the file without the .pub ending. Also avoid sending a key through an untrusted chat or storing it in a public issue tracker.

Australian users may connect to a virtual machine hosted in an AWS Sydney region, an Azure Australia East region, or another local data centre. A nearby region can reduce latency, although the key process is identical regardless of where the server is located. If the remote host is behind a home router, confirm that port forwarding, firewall rules, and the ISP’s network configuration permit the connection.

Make Key-Based Login Convenient

When the private key has a passphrase, use ssh-agent so you do not repeatedly type it during the same desktop session. Start the agent and load the key with:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Ubuntu’s desktop environment often integrates with a keyring, so the key may be remembered after you unlock it. Check loaded identities with:

ssh-add -l

For frequent connections, create an SSH client configuration file:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/config

Add an entry like this:

Host my-server
    HostName server.example.com
    User ubuntu
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Save the file and secure it:

chmod 600 ~/.ssh/config

You can then connect with the shorter command:

ssh my-server

The IdentitiesOnly yes setting tells SSH to use the selected identity rather than trying many keys held by the agent. That can prevent confusing “too many authentication failures” messages on servers with strict authentication limits.

For scripts and automated backups, a dedicated key with no interactive passphrase may be necessary, but it should be restricted carefully. A backup key can be limited to a specific command or directory in authorized_keys. Interactive administration keys should generally use passphrases and should not be reused for automation.

Disable Password Authentication Safely

Key login should be tested in a second terminal before password authentication is disabled. Keep the original session open in case a configuration mistake locks you out. Use verbose output to investigate failures:

ssh -v username@server-address

A successful key login usually shows that the public key was accepted. If it fails, check the username, the selected identity, the remote authorized_keys file, and permissions. On the server, inspect recent SSH messages with:

sudo journalctl -u ssh

Ubuntu’s SSH server configuration is usually stored in /etc/ssh/sshd_config or in files under /etc/ssh/sshd_config.d/. A drop-in file is convenient:

sudo nano /etc/ssh/sshd_config.d/60-key-auth.conf

Add:

PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

Before applying changes, validate the configuration:

sudo sshd -t

If there is no error, reload the service:

sudo systemctl reload ssh

Open a new terminal and test a fresh connection. Do not close the working session until the new login succeeds. If you manage a cloud server, confirm that the provider’s web console or recovery console is available before making authentication changes.

A firewall adds another layer of protection. With Ubuntu’s uncomplicated firewall, check the current rules:

sudo ufw status

If SSH is not already allowed, add a rule before enabling the firewall:

sudo ufw allow OpenSSH
sudo ufw enable

For an internet-facing server, consider restricting SSH to a known office or home address where practical, moving administration behind a VPN, and using fail2ban or equivalent monitoring. Changing the SSH port can reduce background noise, but it is not a replacement for key authentication and a properly configured firewall.

Maintain Keys And Troubleshoot Access

Treat a private SSH key like a house key that can open a server. Keep it out of cloud-sync folders shared with other people, public Git repositories, screenshots, and support tickets. If a laptop is lost, revoke access promptly by removing the corresponding public-key line from the remote user’s ~/.ssh/authorized_keys.

Use distinctive comments when creating keys so you can identify them later. A server may contain keys for a desktop in Perth, a laptop used in Adelaide, and an automated backup host. Remove old keys rather than leaving an untracked collection in place. You can list fingerprints with:

ssh-keygen -lf ~/.ssh/id_ed25519.pub

For stronger separation, create a different key for each server or role. A key used for a personal Raspberry Pi should not also grant access to a production application. Hardware security keys supported through FIDO2 can provide additional protection for higher-value systems, although they require compatible client and server configuration.

Common errors are usually straightforward. “Permission denied (publickey)” often means the key was copied to the wrong account, the client selected a different key, or the remote permissions are too open. “Connection timed out” generally points to routing, a firewall, port forwarding, DNS, or carrier-grade NAT rather than the key itself. Run:

ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes -v username@server-address

If your home internet address changes, a dynamic DNS service can provide a stable hostname. If your NBN provider uses CGNAT, ordinary port forwarding may not work; a VPN, reverse tunnel, or VPS can provide a safer route. Avoid exposing administrative SSH directly just because a router makes port forwarding easy.

Security obligations can also matter in Australian workplaces. SSH encrypts administration traffic, but organisations handling personal information still need to consider the Privacy Act 1988, internal access controls, logging, backups, and breach procedures. Key authentication is one control within that wider system, not a substitute for a complete security policy.

With the public key installed, the private key protected by a passphrase, and a second login verified, the immediate next step is to run ssh-copy-id for your Ubuntu account and test the new connection before changing the server’s password settings.