Loading...

VONDS ©

Lab 64: SSH Keys - Passwordless Authentication

Back to Lab Index

Set up SSH key-based authentication so routine logins no longer depend on passwords. Generate a key pair, install the public key on the remote account, then validate that the connection succeeds without prompting.

ssh auth core

Scenario

You connect to the same server frequently and want to remove repeated password entry from your workflow. Your task is to generate an SSH key pair locally, copy the public key to the remote account, and confirm that you can log in using the key. This improves efficiency and security when the private key is protected and server policy is configured correctly.

Operator context

In production, key-based access is typically paired with a passphrase, an agent (ssh-agent), and tighter server-side controls (often disabling password auth after validation). This lab focuses on the core setup and proof.

Objective

  • Generate a new SSH key pair for the local user.
  • Install the public key on the remote account using ssh-copy-id.
  • Validate that SSH login completes without a password prompt.
  • Exit the remote session cleanly.

Concepts

  • The private key stays on your machine and proves identity. The public key is installed on the server.
  • Server-side authorization is controlled by ~/.ssh/authorized_keys for that account.
  • Correct permissions matter. SSH may ignore keys if ~/.ssh or authorized_keys is too permissive.
  • “Passwordless” usually means “no password prompt” because the key is used. In real setups, you still protect the private key with a passphrase and an agent.

Walkthrough

Step 1 : Generate an SSH key pair.
Command 
ssh-keygen -t ed25519

This generates a new private/public key pair in ~/.ssh/. The private key stays local and must be protected. The public key is what you install on the remote server. 

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/lab/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/lab/.ssh/id_ed25519
Your public key has been saved in /home/lab/.ssh/id_ed25519.pub
Recommendation

Use a passphrase. Pair it with ssh-agent so you keep usability without leaving the private key unprotected.

Step 2 : Copy the public key to the remote server.
Command 
ssh-copy-id -i ~/.ssh/id_ed25519.pub labuser@192.168.1.50

This appends your public key to the remote user's ~/.ssh/authorized_keys file. You typically enter the remote password once during this step. 

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/lab/.ssh/id_ed25519.pub"
Number of key(s) added: 1
Now try logging into the machine, with:
  ssh 'labuser@192.168.1.50'
Step 3 : Log in using key-based authentication.
Command 
ssh labuser@192.168.1.50

If the key is accepted and permissions are correct, the session should start without prompting for the account password. If you set a key passphrase, you may be prompted for the passphrase (or your agent will handle it). 

Welcome to 192.168.1.50.
Last login: Tue Feb 10 21:03:11 2026 from 192.168.1.10
Step 4 : Confirm the key is being used.
Command 
echo "$SSH_CONNECTION"

This prints connection metadata for the current SSH session. If you are logged in, SSH authentication has already succeeded. This is a simple “sanity check” that you are in a remote session. 

192.168.1.10 53422 192.168.1.50 22
Step 5 : Exit the SSH session.
Command 
exit

This cleanly closes the remote shell and returns you to the local session. 

Connection to 192.168.1.50 closed.

Common breakpoints

Still prompted for the account password

The key may not be installed, or the server may be refusing it. Confirm the public key exists in ~/.ssh/authorized_keys on the remote account and verify permissions are not too open.

ssh-copy-id fails or command not found

Some minimal systems do not ship ssh-copy-id. You can manually append the public key to ~/.ssh/authorized_keys on the remote host.

Permission denied (publickey)

The server is requiring a key, but it is not accepting yours. Ensure you are using the correct private key and the matching public key is installed for that user.

Key ignored due to permissions

SSH can ignore keys if ~/.ssh or authorized_keys is group/world-writable. Fix permissions and try again.

Cleanup checklist

If you want to remove access, delete the key line from the remote user’s ~/.ssh/authorized_keys. If this was a throwaway key, remove the local key pair from ~/.ssh.

Commands 
# remote (on 192.168.1.50 as labuser)
vim ~/.ssh/authorized_keys

# local (on your machine)
rm -f ~/.ssh/id_ed25519 ~/.ssh/id_ed25519.pub

Reference

  • ssh-keygen -t ed25519 : Generates a new Ed25519 key pair in ~/.ssh/.
    • -t ed25519 : Selects the Ed25519 key type.
  • ~/.ssh/id_ed25519 : Private key file. Keep protected and never copy to remote systems.
  • ~/.ssh/id_ed25519.pub : Public key file. Install this on remote systems.
  • ssh-copy-id -i <pubkey> user@host : Installs a public key into the remote user’s ~/.ssh/authorized_keys.
    • -i <pubkey> : Selects the public key file to install.
  • ~/.ssh/authorized_keys : Remote file containing public keys allowed to authenticate for the account.
  • ssh user@host : Initiates an SSH session. If key-based authentication is configured correctly, it can succeed without prompting for the account password.
  • exit : Closes the remote shell session and terminates the SSH connection.