What Is the "Authentication Private Key" in SSH, and What Does It Actually Authenticate?

Many people see an "authentication private key" in SSH-related settings and naturally assume it means the private key used by the user to log in. In most cases, that understanding is incorrect.

Two Kinds of Private Key in SSH

The key point is that SSH may involve two different kinds of private keys:

• the server's own private key
• the user's own private key

They are both called private keys, but they serve different purposes.

If the "authentication private key" in a configuration screen refers to an SSH server setting, it usually is not the user's login key. Instead, it is the SSH server identity private key. Its job is not to prove who the user is, but to prove who the server is.

In other words, it authenticates the server itself, not the user.

Once you understand that distinction, many common questions become easier to answer. For example:

• Why does the system still need this private key even when username/password login is enabled?
• Why does the server still need its own private key when the user logs in with SSH public key authentication?
• Why does the SSH client ask you to confirm the host fingerprint on first connection?

At their core, all of these questions are about server identity authentication.

Which Layer the "Authentication Private Key" Belongs To

When SSH establishes a connection, it does not usually begin by checking the user's password. A more typical flow is this: the client first completes the handshake with the server and verifies the server's identity; after that, the two sides establish an encrypted channel; only then does the client submit a username and password, or use the user's own SSH key to complete login authentication.

So in SSH, there are at least two distinct phases:

• First, confirm "am I connecting to the intended server?"
• Second, confirm "is this user allowed to log in to this server?"

The first depends on the server identity private key. The second depends on the user password or the user private key.

That is why "authentication private key" and "username/password" are not alternatives. They address different layers.

To be more concrete: when a client connects to an SSH server, the server uses its identity private key to sign the handshake. The client then verifies that signature against the server's public key. Only after verification can the client trust that it is talking to the holder of the expected server private key.

At this stage, the server is proving its own identity.

Only after that does client-side user authentication proceed — submitting username/password or signing a challenge with the user's private key for public-key authentication.

Therefore:

• Server identity private key answers "which server is this?"
• User password / user SSH private key answers "which user is this?"

They sound similar but have entirely different responsibilities.

The split is visible in the effective server configuration. sshd -T prints the configuration the daemon actually loaded, not the commented file on disk, so it is the fastest way to see which user authentication methods a host really accepts. Real output from a Debian 12 host running OpenSSH 9.2p1:

$ sshd -T 2>/dev/null | grep -E 'pubkeyauthentication|passwordauthentication|kbdinteractive|authenticationmethods|authorizedkeysfile'
pubkeyauthentication yes
passwordauthentication no
kbdinteractiveauthentication no
authorizedkeysfile .ssh/authorized_keys .ssh/authorized_keys2
authenticationmethods any

Note what is missing from that output: there is no line governing the server identity key at all. User authentication methods can be switched on and off freely, while the host key is configured separately through hostkey entries and cannot be "disabled" the same way.

Host Fingerprints and the First-Connection Prompt

This also explains a common misconception: some people think "since I already use password login, the server private key is no longer needed." In fact, even with password login, the server must first prove its identity. Otherwise, the client cannot reliably confirm it is connected to the intended server.

When connecting to an SSH server for the first time, the client often prompts to confirm the host fingerprint for this very reason. At first connection, the client can verify "the peer holds some private key," but it does not yet know whether that key belongs to the intended server. User confirmation is required. After that, the client records the server public key and uses it to detect future host identity changes.

The fingerprints you are asked to confirm are exactly the host public keys configured on the server, and they can be read back locally with ssh-keygen:

$ ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub
256 SHA256:634U97WwhXykruLOW0jgNCRjId8I6YWjpLJYlaic2Iw root@work (ED25519)
$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
3072 SHA256:pGBXexCOLhPzMcFEGXv7JuF5zB+SqIB4rUXeIuJbjfA root@work (RSA)

If the client later warns that the host fingerprint has changed, it usually means one of:

• Server reinstalled or regenerated host keys
• Connection is not to the original server
• Potential man-in-the-middle risk

This is why the server identity private key must not be replaced casually or leaked.

If the user authenticates with an SSH public key rather than a password, the picture is similar. The difference is that during user authentication, the user signs challenge data with their own private key and the server verifies it with the registered public key.

But in either case, the earlier server identity authentication step still exists. In other words:

• User password can be replaced by a user private key
• But the server identity private key cannot be removed

Password, Public Key, Certificates and OTP

In a product configuration UI, a more accurate label than just "authentication private key" would be:

SSH server identity private key

It is less likely to be misread as a user login key.

Switching between password, public key, certificate and OTP changes only how the second layer proves who the user is; none of them touches the first layer. A certificate goes one step further than a plain authorized key: a CA signs the user's key, so the server only needs to trust the CA instead of maintaining every individual public key. The certificate also carries an identity, a validity window and a set of principals, all of which can be inspected without connecting to the target:

$ ssh-keygen -t ed25519 -N '' -C 'alice@bastion' -f /tmp/ntdemo_1789174156/user_key -q
$ ssh-keygen -t ed25519 -N '' -C 'demo-ca' -f /tmp/ntdemo_1789174156/ca_key -q
$ ssh-keygen -s /tmp/ntdemo_1789174156/ca_key -I alice -n alice,webassets -V +12w /tmp/ntdemo_1789174156/user_key.pub
Signed user key /tmp/ntdemo_1789174156/user_key-cert.pub: id "alice" serial 0 for alice,webassets valid from 2026-09-12T08:48:00 to 2026-12-05T08:49:16
$ ssh-keygen -L -f /tmp/ntdemo_1789174156/user_key-cert.pub
/tmp/ntdemo_1789174156/user_key-cert.pub:
        Type: ssh-ed25519-cert-v01@openssh.com user certificate
        Public key: ED25519-CERT SHA256:XOpbC+9d91JQOcykc3tthQde8qG7KOA8I3qzZ5GhFOc
        Signing CA: ED25519 SHA256:dQzh8TvYLWvxDzZUeh1dQq8AJSMYtjKPkTRSmILmQAE (using ssh-ed25519)
        Key ID: "alice"
        Serial: 0
        Valid: from 2026-09-12T08:48:00 to 2026-12-05T08:49:16
        Principals: 
                alice
                webassets
        Critical Options: (none)
        Extensions: 
                permit-X11-forwarding
                permit-agent-forwarding
                permit-port-forwarding
                permit-pty
                permit-user-rc

That is the whole point of centralised control: the private key never leaves the user's machine, the serial and validity are recorded by the CA, and revocation happens at the CA rather than on every host. In an open source bastion host the same separation shows up as credential management — the asset's login secret is stored once and handed to the session, see Credential Management and SSH Server.

So the takeaway can be summarized in one sentence:

If the "authentication private key" in SSH is a server-side setting, it typically authenticates the server, not the user.

Who the user is is proven by username/password or the user's own SSH private key. Who the server is is proven by the server's own identity private key.

Common Misconceptions and Troubleshooting

Three checks resolve most of the confusion, and each one answers a different question.

• Which user authentication methods does this host accept? Use sshd -T and filter for passwordauthentication / pubkeyauthentication; the effective value is what counts, not the commented line in sshd_config.
• Which key is the server presenting? Read the host key fingerprint with ssh-keygen -l and compare it against what the client shows on first connection. A mismatch is a fact, not a warning to click through.
• Which implementation is on each end? ssh -V and sshd -V report the client and the daemon separately, and the strings often differ even on a fully patched host:

$ ssh -V
OpenSSH_9.2p1 Debian-2+deb12u5, OpenSSL 3.0.15 3 Sep 2024
$ sshd -V
OpenSSH_9.2, OpenSSL 3.0.15 3 Sep 2024

In an open source bastion host like Next Terminal, this separation is reflected in asset credential management and host fingerprint handling. See Asset Management, Asset Access, and Termark native client for direct access to authorized SSH assets.