Public Key Authentication and Agent Forwarding

SSH public key authentication relies on the authorized_keys file, typically located at ~/.ssh/authorized_keys on the server. Each line contains a public key in the format: algorithm base64-key comment. The server checks whether the client can prove possession of the matching private key by signing a challenge.

The ssh-keygen command creates key pairs for authentication. Running ssh-keygen -t ed25519 generates a modern Ed25519 key pair. You can specify a comment with -C for identification, such as your email. The tool saves the private key (id_ed25519) and public key (id_ed25519.pub) in ~/.ssh by default.

RSA 4096-bit keys are highly compatible with legacy systems but slower to sign. ECDSA on NIST P-256 is faster and produces smaller signatures, but some cryptographers question NIST curve parameter selection. Ed25519 based on Curve25519 is the current best practice: fast, small keys and signatures, no known weaknesses, and available in all modern SSH implementations.

The private key file should be protected with a passphrase. ssh-keygen encrypts the private key using a passphrase-derived key (bcrypt for modern keys), so an attacker who steals the file cannot use it without the passphrase. Without a passphrase, anyone with access to the file can authenticate as you to any server holding the matching public key.

The ssh-agent daemon holds decrypted private keys in memory during a login session. You load a key with ssh-add ~/.ssh/id_ed25519, which prompts for the passphrase once. Subsequent SSH connections ask the agent to sign challenges without re-entering the passphrase, combining security with convenience.

When an SSH server sends an authentication challenge, the SSH client delegates signing to ssh-agent via a Unix socket. The agent performs the cryptographic signing using the private key stored in memory and returns only the signature. The private key bytes never leave the agent process, not even to the SSH client itself.

Agent forwarding (ForwardAgent yes or ssh -A) allows a remote SSH session to use your local agent for onward authentication. This is useful for hopping through bastion hosts without copying private keys to the bastion. However, if the bastion is compromised, a root user there can access your agent socket and authenticate as you to any server.

ProxyJump (ssh -J bastion target) is the safer alternative to ForwardAgent for bastion host access. It creates a TCP tunnel through the bastion without exposing your agent socket there. The target server receives a direct connection from your local client, and the bastion only forwards encrypted TCP bytes without any ability to use your credentials.

SSH supports certificate-based authentication where a Certificate Authority (CA) signs host and user public keys. Instead of distributing individual public keys to every server, you configure servers to trust your CA. A signed user certificate grants access to all servers trusting that CA, with optional expiry and principal restrictions embedded in the certificate.

The ssh-keyscan tool connects to one or more hosts and retrieves their public host keys without authentication. This is useful for automating the population of known_hosts files in deployment scripts. Output can be piped directly into a known_hosts file: ssh-keyscan -H example.com >> ~/.ssh/known_hosts.

Public key authentication: client sends public key, server checks authorized_keys, server sends a challenge signed with the session ID, client (via agent) signs it with the private key, server verifies the signature using the stored public key. If valid, authentication succeeds without transmitting any secret credential.

Which SSH key type is the current best practice for new deployments due to its speed, small key size, and strong security properties?

Key takeaways: store public keys in authorized_keys, protect private keys with passphrases, use ssh-agent to hold decrypted keys in memory, prefer Ed25519 key type, use ProxyJump instead of ForwardAgent for bastion access to avoid exposing the agent socket, and consider SSH certificates for scalable access management.