Create and test an SSH key for Ubuntu access

Keep the private key private

An SSH key pair has a private key on your client and a public key that can be authorised on the server. Copy the public key only. A passphrase helps protect the private key if its file is stolen, but it still needs careful storage and backup.

Create a distinct key

On a Linux, macOS or Windows OpenSSH client:

ssh-keygen -t ed25519 -f ~/.ssh/mythosai_lab_ed25519 -C 'mythosai-lab'

Use an existing suitable key if your organisation already has a key-management policy. Do not overwrite it. Check that the destination directory exists. On Windows, PowerShell expands the home-directory path differently from a Unix shell; use the equivalent path under your user profile when needed.

Authorise the public half

On a Unix client with ssh-copy-id, use your actual username and server address:

ssh-copy-id -i ~/.ssh/mythosai_lab_ed25519.pub adminuser@192.168.50.10

These are lab example values, not a command to run against an unknown device. If ssh-copy-id is unavailable, use the server's documented process to append the .pub file's single line to the target user's ~/.ssh/authorized_keys. Preserve existing keys.

Check permissions

On the server, the target user should own the SSH directory and key file. Restrict their permissions:

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

Run those commands as the account whose keys you are configuring, not against an unrelated user's home. Incorrect ownership or overly broad permissions can cause the server to reject a key.

Verify the actual method

Keep your existing session open. In a new client session:

ssh -i ~/.ssh/mythosai_lab_ed25519 -o IdentitiesOnly=yes \
  -o PreferredAuthentications=publickey adminuser@192.168.50.10

Confirm you reach the correct account and can perform the necessary authorised sudo action. Compare the server host-key fingerprint through a trusted route before accepting a new or changed host key. A changed fingerprint should be explained, not bypassed automatically.

Common mistakes

Copying the private file to the server creates unnecessary exposure. Installing a key for root when you meant a standard sudo user changes the access model. Disabling passwords before this new connection works risks lockout. Store an independent recovery route before moving to key-only access.