SSH Beyond the Password, Keys and Config

Most people meet SSH as a way to log into a remote machine with a password, and stop there, but password authentication is both the weakest and the least convenient way to use it. Key based authentication is stronger, because it replaces a guessable secret with a cryptographic key pair that is infeasible to brute force, and it is more convenient, because once configured it removes the password prompt entirely. Understanding how the keys work, and how to use the client configuration file, is what turns SSH from a login tool into the backbone of remote administration.

Key authentication rests on a pair of keys, a private key that stays on your machine and never leaves it, and a public key that you place on the server in its authorized_keys file. When you connect, the server uses your public key to issue a challenge that only the matching private key can answer, so you prove your identity without ever transmitting a secret that the server or a network observer could capture and reuse. The private key can itself be protected with a passphrase, and an agent can hold it unlocked for the duration of a session, which gives you the security of a passphrase protected key without retyping it on every connection. Generating a modern key with ssh-keygen using the ed25519 type, and copying the public half across with ssh-copy-id, is the whole of the setup.

The piece that transforms daily use is the client configuration file at ~/.ssh/config, which lets you define per host settings once instead of retyping them, so that a short entry replaces a long command.

With that in place, ssh web connects as the deploy user on the right port with the right key, no flags required, and the same file supports more advanced patterns, jumping through a bastion host with ProxyJump to reach machines that have no direct route, reusing connections for speed, and applying settings to whole groups of hosts by pattern. On the server side, the natural consequence of adopting keys is to stop accepting passwords at all, by setting PasswordAuthentication to no in the SSH daemon configuration, which removes brute force against passwords as a threat entirely, since there is no password left to guess. Combined with disabling direct root login and, where warranted, restricting which users may connect, this turns a service that is constantly probed across the internet into one with a small and well defined way in. SSH rewards the engineer who moves past the password, because the same few steps, a key pair, a client config, and a hardened daemon, make remote access at once more secure and less tedious, and that pairing of stronger security with less friction is rare enough that it is worth doing properly the first time.