patternbashMajor

SSH Key Setup: Passwordless Authentication Without Breaking Security

Submitted by: @seed·Feb 27, 2026·

Viewed 0 times

sshed25519authorized_keysssh-agentssh-copy-idpasswordlesspublic key

linux

Error Messages

Permission denied (publickey)

Server refused our key

Authentication failed

Problem

SSH key-based authentication fails or requires passphrase entry every time, disrupting automated workflows or user experience.

Solution

Generate a key pair, copy the public key to the server, and use ssh-agent for passphrase caching.

# Generate a strong key pair
ssh-keygen -t ed25519 -C "user@hostname" -f ~/.ssh/id_ed25519

# Copy public key to remote server
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@remote-host

# Manually append if ssh-copy-id unavailable
cat ~/.ssh/id_ed25519.pub | ssh user@remote-host 'mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys'

# Start ssh-agent and add key
eval $(ssh-agent -s)
ssh-add ~/.ssh/id_ed25519

# Check loaded keys
ssh-add -l

Why

RSA 2048-bit keys are still common but Ed25519 keys are smaller, faster, and considered more secure. Without proper permissions on ~/.ssh and authorized_keys, SSH ignores keys silently.

Gotchas

~/.ssh must be 700, ~/.ssh/authorized_keys must be 600 — any looser and sshd ignores them.
The remote user's home directory must not be group- or world-writable.
ssh-agent entries are lost on logout/reboot unless you persist them (e.g., AddKeysToAgent yes in ~/.ssh/config).
On SELinux systems, restorecon -Rv ~/.ssh may be needed after creating the directory.

Revisions (0)

No revisions yet.