Allowing SSH access between Linux computers

To let one computer connect to another over SSH, add the connecting user's public SSH key to a particular user's ~/.ssh/authorized_keys file on the receiving computer. SSH access is granted to an account, not to the whole computer. The private key stays on the connecting computer and must never be shared.

In this example, the computer making the connection is the client and the computer accepting the connection is the server.

make sure the server accepts ssh connections

The SSH server must be installed and running on the receiving computer. On Ubuntu or Debian:

sudo apt update
sudo apt install openssh-server
sudo systemctl enable --now ssh

If ufw is enabled, allow SSH through the firewall:

sudo ufw allow OpenSSH
sudo ufw status verbose

Port 22/tcp must also be allowed by any router, VPS, or cloud-provider firewall between the two computers.

create a key on the client

On the computer that will make the connection, check for an existing public key:

ls ~/.ssh/*.pub

If there is no key, create one:

ssh-keygen -t ed25519

Press Enter to accept the default file location. Use a passphrase if desired, or press Enter twice for no passphrase.

choose the account on the server

A Linux server normally has the all-powerful root account, one or more regular human accounts, and several service accounts used by programs. The username in an SSH command tells the server which account you are trying to enter:

ssh cjm@1.2.3.4

This asks to log in as cjm. If the server accepts the key, the session starts with that account's home directory, files, groups, and permissions. The server looks for the key in cjm's ~/.ssh/authorized_keys, usually /home/cjm/.ssh/authorized_keys. It does not look in /root/.ssh/authorized_keys.

In most cases, install the key for the regular account that you normally use on the server. This is often the account created while installing Linux or creating the VPS. After logging in, use sudo for individual administrative commands when necessary:

ssh cjm@1.2.3.4
sudo apt update

This is safer than logging in directly as root: everyday commands do not automatically have permission to change or delete anything on the system, and administrative actions are associated with the regular account that requested them. Many SSH servers disable or restrict direct root login by default.

Only install a key for root when direct root access is a deliberate requirement and the server's SSH configuration permits it. Do not choose a service account such as www-data; those accounts are normally intended for programs and may not be allowed to log in.

If you are at the server and are unsure of your current regular username, run:

whoami

To inspect a proposed account, run id and ask the account database for its home directory and login shell:

id cjm
getent passwd cjm

Use the account intended for your work and confirm that you are authorized to access it. If another person administers the server, ask them which username they created for you. Different people should normally use separate accounts and install their keys into their own authorized_keys files.

For an automated task, it can be better to create a dedicated account with only the permissions that task needs. Adding the same public key to several users' authorized_keys files grants that key separate access to every one of those accounts.

first access to a rented cloud server

A VPS or cloud provider such as DigitalOcean rents you a remote Linux machine and gives you its public IP address. The provider must also give you some initial way to administer it. Common methods are installing a public SSH key while the machine is created, supplying an initial account and password, or providing a browser-based console in the provider's website.

The browser console is a shell connected through the provider's management system rather than through SSH from your computer. It is useful for the initial setup and for recovery when SSH, the firewall, or the network configuration is broken. Protect the provider account with a strong password and multi-factor authentication because someone who controls that account may also control this console.

let the provider install the key

Many providers let you paste or select a public SSH key while creating the server. On your computer, print the public key:

cat ~/.ssh/id_ed25519.pub

Copy the entire single line beginning with ssh-ed25519 and paste it into the provider's SSH-key field. Never paste the contents of ~/.ssh/id_ed25519, which is the private key. The provider installs the public key for the initial login account when it builds the machine.

The provider should tell you the initial username; it might be root, ubuntu, debian, or a username chosen during setup. Use exactly that username when connecting:

ssh ubuntu@203.0.113.10

Do not guess that the account is root. The chosen Linux image and the provider's setup process determine the initial account.

install the key through the provider console

If the server already exists and your computer's key has not been installed, open the machine's console from the provider's website and log in using the initial credentials or recovery method supplied by the provider. Decide which regular account should accept your SSH connections. If the console opens as root but the intended account is cjm, switch to that account:

su - cjm

On your own computer, print and copy the public key:

cat ~/.ssh/id_ed25519.pub

In the provider console, create the SSH directory, open the target account's authorization file, and paste the public key as one complete new line:

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

Save the file and exit the editor. Because these commands are run as the intended account, ~ refers to that account's home directory and the files have the correct owner. Each line in authorized_keys represents a separately authorized public key; do not remove keys that still belong there.

Back on your own computer, connect using that same account and the public IP address supplied by the provider:

ssh cjm@203.0.113.10

Use the provider console to obtain and verify the server's host-key fingerprint before accepting the first SSH connection, as described below. Once key login works, the browser console remains a useful recovery route, but normal work can happen through SSH.

authorize the client key with ssh-copy-id

If the key was installed during cloud-server creation or through a provider console, skip this step. Otherwise, if the server account currently permits password login, the easiest method is ssh-copy-id. Run this on the client, replacing the username and address with those of the server:

ssh-copy-id -i ~/.ssh/id_ed25519.pub cjm@1.2.3.4

The username before @ selects the account that will receive the key. In this example, the key is installed for cjm, and the password prompt asks for cjm's current server password—not the root password.

The -i option explicitly selects the public key to install. ssh-copy-id never needs to copy the private key. It opens a normal SSH connection, logs in using the selected server account's current authentication method, and normally runs commands on the server that create ~/.ssh if needed and append the public key to ~/.ssh/authorized_keys. It also avoids adding the same key again if it is already present.

verify the server before entering the password

The first time the client connects, SSH does not yet know the server's identity. It displays the server's host-key fingerprint and asks whether to continue. A prompt might contain a fingerprint shaped like this:

SHA256:long_string_of_letters_and_numbers

Before answering yes, compare that fingerprint with the one shown directly on the server. For an Ed25519 host key, run this at the server's keyboard, through a trusted management console, or ask the server's administrator to run it:

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Compare the complete SHA256: fingerprint, not just part of it. The server address alone does not prove that the computer answering is the intended server. Verifying the fingerprint through a separate trusted route protects against connecting to an impostor between the client and server.

Once accepted, the server's host key is saved in the client's ~/.ssh/known_hosts file. Future connections check it automatically. If SSH later warns that the host key has changed, investigate before entering a password or removing the old entry. A legitimate reinstall can change the key, but the warning can also indicate an attack.

why entering the password is safe

SSH negotiates an encrypted connection and verifies the server's host key before asking for the account password. The password is sent through that encrypted connection, not as readable text over the network. Someone monitoring the network cannot read it.

Encryption alone is not enough if the client has connected to the wrong machine: an impostor server could read the password after decrypting its end of the connection. That is why checking the host-key fingerprint before entering the password is important on the first connection.

After the fingerprint is verified, enter the server user's password when ssh-copy-id prompts for it. This initial password login gives ssh-copy-id permission to install the public key. Later logins can use the key instead of the account password.

If ssh-copy-id is unavailable, print the public key on the client:

cat ~/.ssh/id_ed25519.pub

Copy the entire line, then add it as a new line in ~/.ssh/authorized_keys for the user on the server. On the server, make sure the permissions are correct:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

test the connection

From the client, connect using the server user's name and the server's IP address or hostname:

ssh cjm@1.2.3.4

If the key was installed successfully, the server should accept it. You may still be asked for the key's passphrase if you assigned one when creating the key. That passphrase unlocks the private key locally and is not the server account's password.

These two files have different purposes: authorized_keys on the server lists the client keys allowed to log in, while known_hosts on the client records the identities of servers it has connected to.