This guide covers the process of establishing passwordless SSH authentication between two Ubuntu servers using public key cryptography. By the end, you will have configured key-based authentication for unattended tasks such as scheduled backups or monitoring scripts, tested the connection, and optionally locked down the server to reject password-based logins entirely. This approach eliminates the need to store passwords in scripts while maintaining security through cryptographic keys.
What SSH Key-Based Authentication Does
SSH key-based authentication replaces password prompts with a cryptographic challenge-response system. A private key stored on the client machine mathematically proves identity to a server that holds the corresponding public key. This allows automated processes to authenticate without embedding passwords in scripts or configuration files. The method is more secure than password authentication because private keys are never transmitted over the network and brute-force attacks become computationally infeasible.
The terms client and server refer to the direction of connection initiation. The client is the machine initiating the SSH connection. The server is the machine receiving it. Any computer can function as either, depending on the task.
Prerequisites and Environment
This guide was tested on Ubuntu 22.04 LTS in September 2023. The specific kernel version referenced in the source material is 5.15.0-83-generic. Current Ubuntu 22.04 systems may ship with newer kernel versions. This does not affect the SSH configuration steps.
You need command line access as the user who will initiate connections on the client side, and as the user who will receive connections on the server side. No elevated privileges are required for key generation or copying, though some steps require sudo access.
Implementation Steps
Step 1: Generate a Key Pair on the Client
Log in to the client machine as the user who will initiate SSH connections. Generate a 4096-bit RSA key pair. The comment field should identify the key’s origin for future reference.
ssh-keygen -t rsa -b 4096 -C "username@computername"Note that the command shown in the source material includes sudo, which is not necessary and causes the key to be created in the root user’s home directory rather than the current user’s directory. Omit sudo unless you specifically need root to initiate connections.
When prompted for a file location, press Enter to accept the default path of ~/.ssh/id_rsa. When prompted for a passphrase, press Enter twice to leave it empty. Setting a passphrase here would require manual entry at each connection, defeating the purpose of passwordless automation.
This creates two files: ~/.ssh/id_rsa contains the private key and must never be shared. ~/.ssh/id_rsa.pub contains the public key and will be copied to the server.
If you are connecting from a Windows client, use PuTTYgen to generate the key pair. PuTTYgen is included with PuTTY. Save both the public and private keys in a secure location and limit their use to specific, documented purposes.
Step 2: Copy the Public Key to the Server
Log in to the server as the user account that will receive the connection. The public key from the client must be appended to the file ~/.ssh/authorized_keys on the server. This file is a plaintext list of public keys, one per line, that are permitted to authenticate without a password challenge.
If the ~/.ssh directory or authorized_keys file does not exist, create them with appropriate permissions:
mkdir -p ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keysCopy the contents of ~/.ssh/id_rsa.pub from the client and paste it as a new line in ~/.ssh/authorized_keys on the server. Each key occupies a single line beginning with the key type (such as ssh-rsa), followed by the key material, and ending with the comment.
An example authorized_keys file with two keys looks like this:
ssh-rsa AAAAB3Nz...xXliXR6cf+fqHSYKFw== root@server15
ssh-rsa AAAAB3Nz...l9BVFpVDTIs4rlvLYQ== monitoringuserStep 3: Test the Connection
From the client, attempt to connect to the server as the user whose authorized_keys file now contains the public key:
ssh admin@server32Replace admin and server32 with the appropriate username and hostname or IP address. If this is the first connection to this server from this client, SSH will prompt you to verify the server’s host key fingerprint. Type yes to accept and continue. This prompt will reappear if the server’s hostname, IP address, or SSH host key changes.
If the configuration is correct, you will receive a shell prompt on the server without entering a password. Successful output resembles:
Welcome to Ubuntu 22.04.3 LTS (GNU/Linux 5.15.0-83-generic x86_64)
...
admin@server32:~#If the connection fails or prompts for a password, verify that the public key was copied correctly and that file permissions are correct. The ~/.ssh directory should be mode 700 and authorized_keys should be mode 600.
Step 4: Disable Password Authentication (Optional)
Once key-based authentication is confirmed working, you can disable password authentication entirely. This prevents brute-force password attacks and enforces key-based access for all users.
On the server, edit /etc/ssh/sshd_config and locate the line containing PasswordAuthentication. Change it to:
PasswordAuthentication noIf the line is commented out with a hash symbol, remove the hash. Save the file and restart the SSH service:
sudo systemctl restart sshd.serviceFrom this point forward, all SSH logins to this server require a valid private key matching a public key in the target user’s authorized_keys file. Password-based authentication will be rejected.
Before enabling this setting on a production server, ensure that at least one user has working key-based access and that you have an alternative method to regain access (such as console access or a management interface) in case of misconfiguration.
Using Key-Based Authentication in Scripts
With passwordless authentication configured, you can use SSH-based tools in automated scripts without handling credentials.
To copy a file from the client to the server using scp:
scp test.file admin@server32:/tmpThis transfers test.file from the current directory on the client to /tmp on the server. The command completes without a password prompt.
To execute a command on the remote server and capture its output:
ssh admin@server32 "cat /etc/hosts"This runs the command in quotes on the remote system and returns the output to the client. The output can be redirected to a file or processed by other commands in a script.
These capabilities allow scheduled tasks to perform remote operations such as file transfers, backups, or status checks without storing passwords in cron jobs or shell scripts.
Troubleshooting and Tips
If you accidentally lock yourself out by disabling password authentication before testing key-based access, you will need console access to the server to reverse the change. Edit /etc/ssh/sshd_config, set PasswordAuthentication yes or comment out the line entirely, then restart sshd:
sudo systemctl restart sshd.serviceCommon issues include incorrect file permissions on ~/.ssh or authorized_keys, whitespace or line break errors when copying the public key, or attempting to connect as the wrong user. Check /var/log/auth.log on the server for detailed error messages if authentication fails.
For debugging, run the SSH client with verbose output:
ssh -v admin@server32This shows the authentication methods attempted and where the process fails.
Testing and Validation
Verify that key-based authentication is working by connecting from the client to the server without receiving a password prompt. After disabling password authentication, verify that the setting is active by attempting to connect from a machine that does not have a valid key. The connection should be immediately rejected with a “Permission denied” error.
To confirm that the SSH service is using the updated configuration, check the service status:
sudo systemctl status sshd.serviceThe output should show the service as active and indicate the time of the most recent restart.
For reference on SSH key management and configuration:
AI assistance is used on this site for language, formatting, and turning research into a consistent template. It is not used to perform the underlying research or verify technical claims. Every command, configuration, and step in this post is tested by hand before publication.
Categories and Tags
Categories: Linux, Security, System Administration
Tags: SSH, authentication, Ubuntu, public key cryptography, automation, passwordless login, sshd configuration, key management