SSH public-key authentication

What it means

SSH involves trust in two directions: your client checks the server’s identity, while the server evaluates access to the requested user account. Within public-key user authentication, a key being allowed and a client proving control of its matching private key are different conditions. Keeping those questions separate helps you interpret what a passed check actually establishes—and what it leaves unanswered.

Try it

Simulation: start with all three controls set to yes. Change only “Server host key trusted?” to no and inspect the updated result and explanation. Select Compare with baseline to view the two outcomes together. This changes local teaching inputs only; it does not connect to an SSH server or handle a credential.

With all three inputs set to yes, the result is “Synthetic trust checks satisfied.” The explanation is: “Host authentication, user authorization and proof possession are separately present in this example.” These are supplied assumptions, not observations of a connection.

Keep “User public key authorized?” = yes and “Client proves private-key possession?” = yes. Changing only host trust isolates why the other two checks cannot establish server identity.

Reset restores all three inputs to yes, removes input errors and clears the comparison with the baseline. It does not open or close any FAQ answer or the About this model panel; those disclosure choices remain yours.

How it works

The important distinction is permission versus proof. A server’s authorization configuration answers whether a public-key credential is permitted for the target account. It does not establish that the connecting client controls the corresponding private key. That requires a separate proof of possession. If a copy of the public key were enough, anyone holding that copy could satisfy the check; requiring private-key control is what makes that copy insufficient.

In real SSH public-key authentication, the client uses the matching private key to sign authentication data that includes the connection’s session identifier and user-authentication request fields. It sends the signature for the server to verify with the public key; the private key is not included in that authentication request. The server checks two different things: whether the key is permitted for the account, and whether the signature is valid. A valid signature is not permission by itself, and an authorized public key is not proof by itself. Even after this method succeeds, server policy may require another authentication step. The Simulation assumes successful proof; it does not generate or verify a signature.

Server identity runs in the other direction. The client needs evidence that the host it reached is the intended server. An account’s willingness to accept a user credential cannot supply that evidence. Likewise, trusting the server’s host key says nothing by itself about whether a particular user key is authorized or whether the client can prove private-key control.

The model represents these as three independent supplied conditions. If all are yes, it reports that the synthetic checks are satisfied. If any is no, it identifies the failed condition and retains the other supplied checks in its explanation. This makes the missing evidence visible without pretending to reproduce SSH message order, a cryptographic exchange or a complete authentication policy.

Worked example

This synthetic baseline supplies all three conditions; it is not a captured connection or a test of an actual key.

The result is “Synthetic trust checks satisfied.” The intermediate condition is that none of the three supplied checks is missing. This establishes only that the model’s requirements are present in the example, not that a real server has accepted a login.

What changes when the condition changes

Change only “Server host key trusted?” to no. Leave “User public key authorized?” and “Client proves private-key possession?” at yes.

The result becomes: “Do not treat connection as authenticated.” Its explanation is: “Failed checks: host. Passed checks: user, proof. A passed host check does not replace client authorization or proof of possession.”

The missing condition is now server identity. The two unchanged selections still supply authorization and proof assumptions, but neither establishes which server you reached. The result lists those assumptions separately; it is not evidence that an actual client would continue authentication after a host-key failure.

In practice

For an OpenSSH connection you are authorized to use, begin with read-only checks scoped to the intended host and user account. Confirm the destination and account, obtain the expected host-key evidence through a trusted administrative channel, and compare it with the server-key evidence presented by your client. The expected observation is agreement with that independently obtained evidence—not merely the absence of a warning.

If the host key is unexpected, has changed without a verified explanation, or cannot be verified, stop before proceeding. Do not disable host-key verification or remove a saved key merely to bypass the warning. Trying another user key does not resolve uncertainty about the server.

Once server identity is established, inspect the intended account’s authorization configuration only with appropriate access, or ask its administrator to do so. A permitted public key addresses authorization; it does not by itself establish successful private-key proof or satisfaction of every authentication requirement. This page calls for inspection, not edits to keys, account access or SSH configuration.

Limits and unknowns

The Simulation does not perform cryptography or contact a real server. All three controls are yes/no assumptions, not detected facts. In particular, selecting yes for private-key possession does not demonstrate possession of any actual private key, and “Synthetic trust checks satisfied” does not promise a successful login under a real server’s policy.

The controls have no unknown option. If you lack evidence about a real host or account, keep that uncertainty explicit rather than translating it into yes. Collect the missing host-identity, authorization or proof evidence before drawing a stronger conclusion.

If the interface reports invalid input, no calculated outcome applies until you correct it or use Reset. Without JavaScript, the initial example and explanation remain readable, but the interactive controls are unavailable.

What to carry forward

Treat permission, proof of credential control and server identity as separate requirements. When a connection is uncertain, identify which evidence is missing before deciding what to inspect next. An accepted user key cannot resolve an unverified server identity, and a trusted server cannot establish that the client controls an authorized credential.