SSH Key Authentication in a Windows Terminal Client

Passwords on every connect are slow and weak. Key-based auth is the standard for field equipment and automation alike.

Public-key authentication replaces the per-connection password with a key pair: a private key that stays on your machine and a public key placed on the target. For equipment you connect to repeatedly, or script against, it is both more convenient and stronger than a password.

This article covers generating a key pair on Windows, loading it into a terminal client, and the host-verification step that keeps you from connecting to the wrong or impersonated machine.

Choosing a key type

The two key types you will meet are Ed25519 and RSA. Ed25519 is modern, smaller, and fast, and is a sound default for new deployments. RSA remains widely supported on older devices and is the fallback when an embedded target's SSH server predates Ed25519 support.

When a legacy device rejects an Ed25519 key, generating an RSA key for that target specifically is normal. Keep key types per-target rather than forcing one standard across a mixed fleet.

• Ed25519. Modern default; compact and fast.
• RSA. Broad compatibility, needed by older SSH servers.
• Passphrase. Protects the private key if the file is copied.

Generating and placing the key

Generate the pair, then copy the public key to the target's authorized-keys store. On a Linux or embedded target this is typically a file under the user's ssh directory; on network gear it may be a CLI command that accepts the public key block.

The private key stays local. Protect it with a passphrase so a stolen laptop does not immediately grant access, and keep a backup of the key pair in a safe place because losing the private key locks you out of every target that trusts it.

Loading the key into the client

A terminal client needs the private key available for the session. Some clients hold keys in an agent so you unlock once and reuse for many connections; others load the key file per session. Either works, but an agent avoids retyping the passphrase across a fleet.

If a connection still prompts for a password after you added the public key, the usual causes are a mismatched key loaded, a misplaced authorized-keys entry on the target, or the target's sshd configured to disallow key auth.

Understanding known_hosts

The first time you connect, the client records the server's host key in a known_hosts store and asks you to confirm. On later connections it compares the presented key to the stored one; a mismatch is a warning that the machine may have changed or be impersonating the host.

Treat a known_hosts mismatch seriously rather than auto-accepting it. A reinstalled device, a changed SSH server key, or a device replaced under warranty all legitimately change the host key, but so does a man-in-the-middle attempt.

Operational hygiene

Name keys after their purpose and keep them in a clear local layout. For a fleet, a single agent-loaded key per role beats scattering unlabeled key files across desks. Rotate keys when staff leave or a machine is decommissioned by removing the public key from the affected targets.

Disable password authentication on internet-facing targets once key auth is proven, but keep it available on isolated lab gear where convenience matters more than exposure. The right setting depends on where the device sits.

Avoid sharing one private key across the team. Per-user keys mean a departure is a single revocation rather than a scramble to re-key everything, and they make the authorized-keys file a record of who can reach what. A shared key quietly removes accountability, which is exactly what audit trails are meant to preserve.

Once keys work, tunnel device interfaces with SSH port forwarding, apply the pattern to network gear, and compare with Telnet versus SSH for older equipment.

Common questions

Which SSH key type should I use?

Ed25519 is a good modern default. Use RSA when a target's SSH server is old enough not to support Ed25519; keep key types per target rather than forcing one standard.

Why am I still asked for a password after adding my key?

Usually the target did not accept the key: the public key may be in the wrong place, the wrong key may be loaded, or the server may disallow key authentication. Verify the authorized-keys entry on the device.

What is known_hosts for?

It stores the server's host key so the client can detect if the machine changes or is impersonated. A mismatch warning should be investigated, not blindly accepted.

Should I protect my private key with a passphrase?

Yes. A passphrase keeps the key useless if the file is copied from your machine. Pair it with an agent so you unlock once per session instead of per connection.

Can I use one key for my whole fleet?

You can, but per-role keys make rotation and revocation cleaner. When a key must be revoked, only the targets trusting it are affected if keys are scoped by role.

Keep reading