SSH Public Key Authentication: Secure Remote Management Guide

Replace fragile password SSH logins with secure public key authentication. A step‑by‑step guide to generating Ed25519 keys, copying them to the server, testing access, and understanding trade‑offs like passphrase use and agent forwarding.

Problem: Password‑Based SSH is Fragile and Hard to Automate

When you log into a server with ssh user@host, the remote machine asks for a password. That password must be typed, stored in shell history, and is vulnerable to brute‑force attacks. For automated builds, backups, or configuration management, typing a password is simply not an option.

Thesis: Use Public Key Authentication to Replace Passwords

SSH’s public key system lets a client prove its identity with a cryptographic key pair. The private key stays on the client, never leaving the machine, while the public key is copied to the server’s ~/.ssh/authorized_keys. Once set up, you can connect without typing a password, and you can script the connection safely.

Why Key‑Based Auth Beats Passwords

Security – No password is sent over the network, eliminating interception risk.
Brute‑Force Protection – SSH will refuse to accept a key that isn’t in authorized_keys, stopping dictionary attacks.
Automation Friendly – Scripts can run SSH commands without human intervention.
Auditability – Each key can be traced to a specific user or service.

Step‑by‑Step Example: Setting Up Ed25519 Keys on Ubuntu 24.04

Generate the key pair on the client. Run the command below and follow the prompts. The placeholder ~/.ssh/id_ed25519 is the default location.
```
ssh-keygen -t ed25519 -b 256 -f ~/.ssh/id_ed25519
```
Ed25519 is recommended over RSA: it uses a 256‑bit curve, offers 128‑bit security, and performs faster with smaller keys.
Copy the public key to the server. The ssh-copy-id utility automates this, ensuring proper permissions.
```
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@hostname
```
After this step, the server’s authorized_keys file will contain your public key.
Test the connection. Attempt to log in:
```
ssh user@hostname
```
If the key is accepted, you will be prompted for the key’s passphrase (if you set one) and then granted shell access. No password prompt should appear. If you see a password prompt, double‑check that the public key is in authorized_keys and that the .ssh directory and file permissions are correct (700 and 600 respectively).
Enable ssh-agent (optional but handy). The agent stores decrypted keys in memory, so you only enter the passphrase once per session.
```
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
```
You can now open multiple SSH sessions without re‑entering the passphrase.

Trade‑Offs and Limitations

Key Passphrase vs. Convenience – A passphrase protects the private key if the local machine is compromised, but it requires entering the passphrase each time the key is loaded into ssh-agent or used directly. Consider using a strong passphrase and ssh-agent for a balance.
Agent Forwarding Risks – If you enable ForwardAgent yes in ~/.ssh/config, the remote host can use your key to authenticate to other hosts. A malicious or compromised remote user could then impersonate you elsewhere. Disable agent forwarding unless you trust the remote host.
Permission Errors – SSH will refuse key authentication if ~/.ssh is group‑writeable or if authorized_keys is not owned by the user. Ensure chmod 700 ~/.ssh and chmod 600 ~/.ssh/authorized_keys.

When to Use RSA Instead of Ed25519

Some legacy systems or specific compliance requirements still mandate RSA. RSA keys are larger (2048‑bit or 4096‑bit) and can be slower, but they are widely supported. Use ssh-keygen -t rsa -b 4096 if you must.

Actionable Checklist

Generate a modern key pair (Ed25519). ssh-keygen -t ed25519
Copy the public key with ssh-copy-id.
Verify directory and file permissions.
Test login without a password prompt.
Enable ssh-agent for convenience.
Restrict ForwardAgent unless absolutely necessary.

By replacing password authentication with SSH public keys, you reduce attack surface, enable secure automation, and maintain a clear audit trail. Follow the checklist above to get your environment fully configured and ready for reliable, secure remote management.

SSH Public Key Authentication: A Practical Guide to Secure Remote Management