SSH key authentication uses a public and private key pair instead of relying on a reusable server password. The private key stays on your local computer, while the public key is added to the Ubuntu account you want to access.
In this tutorial, you will generate an Ed25519 SSH key, copy it to Ubuntu 24.04, verify the correct identity is used, configure ssh-agent, disable password authentication safely, and rotate or revoke keys later.
This workflow is written for a Raff Technologies Ubuntu 24.04 VM, but the OpenSSH key-management steps also apply to standard Ubuntu 24.04 servers. Keep a working SSH session or browser-console recovery path open before changing authentication settings.
Step 1 — Check for Existing SSH Keys
Run this on your local computer:
Common key files include:
id_ed25519
id_ed25519.pub
id_rsa
id_rsa.pub
Do not overwrite an existing private key unless you intentionally want to replace it. You can create a separate key for Raff servers, a specific environment, or a specific team member.
Step 2 — Generate an Ed25519 Key Pair
Generate a new key on your local computer:
ssh-keygen -t ed25519 -a 100 -C "raff-ubuntu-access"
When prompted for a file name, press Enter for the default path or choose a descriptive name such as:
Set a passphrase for interactive administrator keys. The passphrase protects the private key if the local device or key file is copied.
The two generated files have different roles:
id_ed25519 or your custom filename is the private key. Do not upload or share it.- The matching
.pub file is the public key. This is the file copied to servers.
Ed25519 is the preferred default for modern OpenSSH systems. Use RSA only when a legacy system or policy specifically requires it.
Step 3 — Inspect the Public Key and Fingerprint
Display the public key:
cat ~/.ssh/id_ed25519.pub
For a custom filename:
cat ~/.ssh/raff_ed25519.pub
Display its fingerprint:
ssh-keygen -lf ~/.ssh/id_ed25519.pub
Fingerprints help identify keys during audits and rotation without comparing the entire public-key string.
Step 4 — Copy the Public Key to Ubuntu
The simplest method is ssh-copy-id:
ssh-copy-id your_user@your_server_ip
For a custom public key:
ssh-copy-id -i ~/.ssh/raff_ed25519.pub your_user@your_server_ip
The command authenticates using the server's current access method and appends the public key to the user's ~/.ssh/authorized_keys file.
When ssh-copy-id is unavailable, use this fallback from your local computer:
cat ~/.ssh/id_ed25519.pub | \
ssh your_user@your_server_ip \
'umask 077; mkdir -p ~/.ssh; cat >> ~/.ssh/authorized_keys'
On the server, verify ownership and permissions:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R "$USER":"$USER" ~/.ssh
Step 5 — Verify Key Authentication in a New Session
Keep the original SSH session open and test a separate connection:
ssh your_user@your_server_ip
When using a custom key, specify it explicitly:
ssh -i ~/.ssh/raff_ed25519 your_user@your_server_ip
Use verbose output when troubleshooting:
ssh -vv -i ~/.ssh/raff_ed25519 your_user@your_server_ip
Look for output showing that the client offered the intended public key and that authentication succeeded. Exact wording varies by OpenSSH version.
Confirm the server stored the expected public key:
nl -ba ~/.ssh/authorized_keys
Do not disable passwords until a new key-based session succeeds.
Step 6 — Load the Key into ssh-agent
Start an agent in the current local shell when one is not already available:
Add the key:
ssh-add ~/.ssh/id_ed25519
Or add the custom key:
ssh-add ~/.ssh/raff_ed25519
List loaded identities:
The agent keeps the decrypted key available for the session so you do not have to re-enter its passphrase for every connection. Desktop operating systems may provide their own agent or secure key integration.
Step 7 — Disable Password Authentication Safely
Ubuntu's OpenSSH package includes /etc/ssh/sshd_config.d/*.conf near the start of the main configuration. For most sshd_config keywords, OpenSSH uses the first value it obtains, so a later file such as 99-something.conf does not reliably override an earlier drop-in.
Inspect the existing authentication settings first:
sudo grep -RniE \
'^[[:space:]]*(PubkeyAuthentication|PasswordAuthentication|KbdInteractiveAuthentication|PermitRootLogin)[[:space:]]' \
/etc/ssh/sshd_config /etc/ssh/sshd_config.d 2>/dev/null
Create an early drop-in for the key-only policy:
sudo nano /etc/ssh/sshd_config.d/00-raff-key-auth.conf
Add:
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
Validate the complete configuration:
Check the effective values rather than assuming the drop-in won:
sudo sshd -T | grep -E '^(pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication) '
The expected values are:
pubkeyauthentication yes
passwordauthentication no
kbdinteractiveauthentication no
If an effective value is still different, inspect the earlier matching directive and correct the file that wins. Do not keep adding higher-numbered drop-ins and assume the last filename overrides earlier settings.
Reload the service only after sshd -t succeeds:
sudo systemctl reload ssh
Keep the existing session open and test a new key-based connection. Then explicitly test that password-only authentication is rejected:
ssh -o PreferredAuthentications=password \
-o PubkeyAuthentication=no \
your_user@your_server_ip
The connection should be denied rather than presenting a usable password login.
Verify: a new key-based session succeeds, sshd -T reports password and keyboard-interactive authentication disabled, and a password-only test is rejected.
Step 8 — Disable Root SSH Login After Sudo Access Works
First confirm the regular account can run sudo:
The result should be root.
Add the following to the same early drop-in file:
sudo nano /etc/ssh/sshd_config.d/00-raff-key-auth.conf
Add:
Validate and reload again:
sudo sshd -t
sudo systemctl reload ssh
Test the normal administrative account in another terminal before closing the current session. Root-login restrictions and password restrictions should be applied only after the replacement access path is proven.
Step 9 — Create a Local SSH Config Entry
Create or edit the config file on your local computer:
Add:
Host raff-production
HostName your_server_ip
User your_user
IdentityFile ~/.ssh/raff_ed25519
IdentitiesOnly yes
ServerAliveInterval 60
Protect the file:
Connect using the alias:
IdentitiesOnly yes is useful when your agent contains several keys because it tells the client to use the configured identity rather than offering many unrelated keys.
Step 10 — Add a Second Administrator Without Sharing Keys
Each person should generate and control their own private key. Add only their public key to the appropriate server account.
For a separate Linux account:
sudo adduser secondadmin
sudo usermod -aG sudo secondadmin
sudo install -d -m 700 -o secondadmin -g secondadmin /home/secondadmin/.ssh
Add the person's public key to:
/home/secondadmin/.ssh/authorized_keys
Then set ownership and permissions:
sudo chown secondadmin:secondadmin /home/secondadmin/.ssh/authorized_keys
sudo chmod 600 /home/secondadmin/.ssh/authorized_keys
Separate accounts and keys make access review, revocation, and log attribution clearer.
Step 11 — Rotate or Revoke an SSH Key
List authorized keys with line numbers:
nl -ba ~/.ssh/authorized_keys
Before removing an old key, add and test the replacement key in a separate session. Then edit the file:
nano ~/.ssh/authorized_keys
Delete only the line belonging to the key being revoked.
You can identify a public key's fingerprint by saving the line to a temporary file or by checking the original .pub file:
ssh-keygen -lf ~/.ssh/raff_ed25519.pub
If a private key is lost or suspected to be copied, remove its public key from every server that trusts it. Changing the key's local passphrase does not revoke a copy that may already exist elsewhere.
Step 12 — Troubleshoot Common SSH Key Problems
The server still asks for a password
Check the local key being offered:
ssh -vv -i ~/.ssh/raff_ed25519 your_user@your_server_ip
Check server-side permissions:
namei -l ~/.ssh/authorized_keys
The home directory must not be writable by unrelated users, .ssh should normally be 700, and authorized_keys should normally be 600.
Too many authentication failures
Specify the key and prevent the client from offering unrelated agent identities:
ssh -o IdentitiesOnly=yes \
-i ~/.ssh/raff_ed25519 \
your_user@your_server_ip
OpenSSH ignores a configuration change
Validate syntax and inspect effective settings:
sudo sshd -t
sudo sshd -T | grep -E '^(permitrootlogin|pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication) '
Review all drop-ins:
sudo grep -RniE '^(PermitRootLogin|PubkeyAuthentication|PasswordAuthentication|KbdInteractiveAuthentication)' \
/etc/ssh/sshd_config /etc/ssh/sshd_config.d
You lose normal SSH access
Use the Raff browser console to inspect SSH configuration, restore an authorized public key, or correct firewall rules. Keep a tested recovery method available before making remote-access changes.
Conclusion
You now have an Ed25519 SSH key, verified public-key authentication, optional agent and client configuration, disabled password access, and a safe process for adding, rotating, and revoking administrator keys.
Continue with How to Set Up UFW Firewall on Ubuntu 24.04 and How to Harden an Ubuntu 24.04 Server to complete the initial security baseline.
SSH key access is included with Raff Linux VMs. Check the Raff pricing page for the current VM sizes and billing terms instead of relying on a hard-coded tutorial price.
Sources
