SSH Authentication Methods in sshd_config (Password, Public Key, PAM)

sshd_config decides how users prove who they are when they SSH in—password, key, PAM prompt, or something stricter per group. If you have ever flipped PasswordAuthentication and hoped you would not lock yourself out, this page is for you.

Below are copy-paste recipes first, then the directives for each method and the ssh -v lines you should expect. I re-ran sshd -T and local key login on Ubuntu 26.04; the longer ssh -v traces for pubkey failure, keyboard-interactive, and host-based auth come from my earlier RHEL 7 client → RHEL 8 server lab and still match what OpenSSH prints today.

Tested on: Ubuntu 26.04 LTS (Resolute Raccoon); kernel 7.0.0-27-generic; OpenSSH 10.2p1.

Quick answer: SSH authentication methods in sshd_config

Read effective values (after Include drop-ins and Match rules):

sshd -T | grep -iE 'passwordauthentication|pubkeyauthentication|kbdinteractive|authenticationmethods|hostbased|gssapi|kerberos|permitemptypasswords'

Running that on Ubuntu 26.04:

passwordauthentication yes
pubkeyauthentication yes
kbdinteractiveauthentication no
hostbasedauthentication no
gssapiauthentication no
kerberosauthentication no
authenticationmethods any
permitemptypasswords no

Common sshd_config authentication recipes

Key-only SSH login

Use this for most hardened Linux servers after key login is tested:

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
AuthenticationMethods publickey
PermitEmptyPasswords no

Validate and reload:

sudo sshd -t
sudo systemctl reload ssh || sudo systemctl reload sshd

Password login only for a lab server

Use only on private/lab systems:

PasswordAuthentication yes
PubkeyAuthentication no
KbdInteractiveAuthentication no
PermitEmptyPasswords no

Public key plus password

Require both a valid SSH key and the account password:

PubkeyAuthentication yes
PasswordAuthentication yes
AuthenticationMethods publickey,password

Public key plus PAM/OTP

Use this when PAM provides OTP or another challenge:

PubkeyAuthentication yes
KbdInteractiveAuthentication yes
UsePAM yes
AuthenticationMethods publickey,keyboard-interactive

Different rule for an SFTP group

PasswordAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey

Match Group sftpusers
    PasswordAuthentication yes
    AuthenticationMethods password
    ForceCommand internal-sftp

How sshd chooses an authentication method

When you run ssh, the client and sshd negotiate until one authentication method succeeds or the connection is refused. Server policy lives in /etc/ssh/sshd_config, often with snippets under /etc/ssh/sshd_config.d/ on Ubuntu, Debian, and RHEL 8+. Client defaults sit in /etc/ssh/ssh_config and ~/.ssh/config — see SSH client config (ssh_config) when you need client-side tweaks.

Commented-out lines in sshd_config still matter: OpenSSH applies built-in defaults. Run sshd -T when you want the merged result after drop-ins and Match blocks. Throughout this page, client means the machine where you type ssh; server is the host running sshd.

PasswordAuthentication vs KbdInteractiveAuthentication

These two settings confuse people because both can end with a Password: prompt on the client.

Since OpenSSH 8.7 documentation, KbdInteractiveAuthentication is the preferred name; ChallengeResponseAuthentication is kept as a deprecated alias for compatibility.

Setting PasswordAuthentication no alone does not guarantee users will never see a password prompt. If KbdInteractiveAuthentication yes and UsePAM yes, PAM may still ask for a password through the keyboard-interactive path. Check all three on the server:

sshd -T | grep -iE 'passwordauthentication|kbdinteractiveauthentication|usepam'

passwordauthentication yes
kbdinteractiveauthentication no
usepam yes

Password authentication

Password authentication sends the user password over the encrypted SSH channel. PAM still handles account checks when UsePAM yes (the default on Ubuntu and RHEL).

On the server, confirm the setting in /etc/ssh/sshd_config:

egrep '^PasswordAuthentication' /etc/ssh/sshd_config

When the line is present and uncommented:

PasswordAuthentication yes

If it is commented out, check what sshd actually applies:

sshd -T | grep passwordauthentication

passwordauthentication yes

To allow password logins explicitly, add to /etc/ssh/sshd_config or a drop-in under /etc/ssh/sshd_config.d/:

PasswordAuthentication yes
UsePAM yes
PermitEmptyPasswords no

sshd -T | grep -iE 'passwordauthentication|kbdinteractiveauthentication|usepam'

On the server, a successful password login is logged as Accepted password for:

Nov 22 08:53:15 rhel-8.example.com sshd[8482]: Accepted password for root from 10.10.10.10 port 42182 ssh2
Nov 22 08:53:15 rhel-8.example.com systemd-logind[1057]: New session 39 of user root.
Nov 22 08:53:15 rhel-8.example.com systemd[1]: Started Session 39 of user root.

Public key authentication

Public key authentication is the standard hardening step: users prove possession of a private key; the server checks ~/.ssh/authorized_keys (or paths from AuthorizedKeysFile).

On the server, enforce key-only access:

PasswordAuthentication no
PubkeyAuthentication yes

Verify on the server:

egrep '^PasswordAuthentication|^PubkeyAuthentication' /etc/ssh/sshd_config

PasswordAuthentication no
PubkeyAuthentication yes

Before you harden a fresh Ubuntu install, both are usually still on:

sshd -T | grep -E 'pubkeyauthentication|passwordauthentication'

pubkeyauthentication yes
passwordauthentication yes

The default key file paths:

sshd -T | grep authorizedkeysfile

authorizedkeysfile .ssh/authorized_keys .ssh/authorized_keys2

Generate a key pair on the client, copy the public key to the server, then test before disabling passwords. See generate SSH key on Linux and the SSH command cheat sheet for ssh-keygen and ssh-copy-id.

Pubkey-only server, no key configured (failure)

If the server allows only public keys and authorized_keys is empty, login fails:

ssh -v rhel-8

debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Trying private key: /root/.ssh/id_ed25519
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Public key configured (success)

After you copy the public key to the server:

ssh -v rhel-8

debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Authentication succeeded (publickey).
Authenticated to rhel-8 ([10.10.10.7]:22).

On OpenSSH 10.x the success line often reads Authenticated to host using "publickey". Same flow on Ubuntu 26.04:

ssh -i ~/.ssh/id_rsa -v [email protected] exit

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /root/.ssh/id_rsa RSA SHA256:QctH5c77yvxCJMG6WUQfAfwvfxRR4VBhFK+1rAFsoCY
debug1: Server accepts key: /root/.ssh/id_rsa RSA SHA256:QctH5c77yvxCJMG6WUQfAfwvfxRR4VBhFK+1rAFsoCY
Authenticated to 127.0.0.1 ([127.0.0.1]:22) using "publickey".

A pubkey-only public host (GitHub) advertises only publickey:

ssh -o PreferredAuthentications=none -v [email protected] 2>&1 | grep 'Authentications that can continue'

debug1: Authentications that can continue: publickey

Keyboard-interactive and PAM

KbdInteractiveAuthentication enables keyboard-interactive authentication—a multi-step challenge/response dialog between client and server. On most Linux systems this path goes through PAM, so it can prompt for a password, a one-time code, or multiple factors.

Since OpenSSH 8.7 documentation, KbdInteractiveAuthentication is the preferred name; ChallengeResponseAuthentication is kept as a deprecated alias for compatibility. Ubuntu 26.04 ships with keyboard-interactive off:

grep KbdInteractiveAuthentication /etc/ssh/sshd_config
sshd -T | grep kbdinteractiveauthentication

KbdInteractiveAuthentication no
kbdinteractiveauthentication no

To use PAM-based two-factor authentication, enable keyboard-interactive and configure a PAM stack (for example Google Authenticator or offline OTP). See offline two-factor SSH authentication for a full walkthrough.

KbdInteractiveAuthentication yes
UsePAM yes

With other methods turned off and only keyboard-interactive left, negotiation looks like this:

ssh -vvv rhel-8.example.com

debug1: Authentications that can continue: keyboard-interactive
debug3: start over, passed a different list keyboard-interactive
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug3: send packet: type 50
debug2: we sent a keyboard-interactive packet, wait for reply
debug3: receive packet: type 60
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password:
debug1: Authentication succeeded (keyboard-interactive).
Authenticated to rhel-8.example.com ([10.10.10.7]:22).

With only PAM password modules configured, that single Password: prompt looks the same as plain password auth. Check the server log to tell them apart—keyboard-interactive:

Nov 22 08:49:30 rhel-8.example.com sshd[8434]: Accepted keyboard-interactive/pam for root from 10.10.10.10 port 42180 ssh2
Nov 22 08:49:30 rhel-8.example.com systemd-logind[1057]: New session 38 of user root.
Nov 22 08:49:30 rhel-8.example.com systemd[1]: Started Session 38 of user root.

Versus plain password auth on the same setup:

Nov 22 08:53:15 rhel-8.example.com sshd[8482]: Accepted password for root from 10.10.10.10 port 42182 ssh2

Require multiple factors with AuthenticationMethods

AuthenticationMethods sets which methods must succeed and in what combination.

Example key-only policy in a drop-in file /etc/ssh/sshd_config.d/99-hardening.conf:

PasswordAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey

Validate syntax before reload:

sudo sshd -t

No output means the file parses cleanly. To preview that drop-in before you install it, point sshd -T at a minimal standalone config (Ubuntu 26.04):

sshd -T -f /tmp/sshd-hardening.conf | grep -iE 'passwordauthentication|authenticationmethods'

passwordauthentication no
authenticationmethods publickey

After you add the drop-in and reload sshd, confirm on the live server with sshd -T | grep -iE 'passwordauthentication|authenticationmethods'.

Per-user and per-group rules with Match

Match blocks at the end of sshd_config override global settings for specific users, groups, or source addresses.

Example: global key-only access, but password auth for an SFTP group:

PasswordAuthentication no
PubkeyAuthentication yes

Match Group sftpusers
    PasswordAuthentication yes
    AuthenticationMethods password
    ForceCommand internal-sftp

Preview effective settings for a specific user and group:

sshd -T -C user=deploy,group=sftpusers,host=myserver,addr=203.0.113.10 \
  | grep -iE 'passwordauthentication|authenticationmethods|forcecommand'

Use this after every Match change. If AuthenticationMethods publickey is set globally, a Match group that needs passwords must also set AuthenticationMethods password (or any) inside the block—otherwise only public keys work even when PasswordAuthentication yes is present.

Host-based authentication

Host-based authentication trusts a client host (via /etc/ssh/shosts.equiv or .shosts files) plus host keys—not just a user key. It is rare in production because it can enable passwordless access for many users from a trusted host.

Keep it disabled unless you have a documented need:

HostbasedAuthentication no
IgnoreRhosts yes

Defaults on the Ubuntu test host:

sshd -T | grep -E 'hostbasedauthentication|ignorerhosts'

hostbasedauthentication no
ignorerhosts yes

For a full host-based setup, see configure SSH host-based authentication.

With host-based auth wired up, ssh -v shows the host key path succeeding:

ssh -v rhel-8.example.com

debug1: Next authentication method: hostbased
debug1: userauth_hostbased: trying hostkey ecdsa-sha2-nistp256 SHA256:/r/FWD0IwFpOcuqEnFrkcNQZKI23vOzb94ZWjevwpMc
debug1: Authentication succeeded (hostbased).
Authenticated to rhel-8.example.com ([10.10.10.7]:22).
debug1: Remote: Accepted for rhel-7.example.com [10.10.10.10] by /etc/ssh/shosts.equiv.
Last login: Thu Nov 21 21:23:52 2019 from rhel-7.example.com

GSSAPI and Kerberos authentication

GSSAPI authentication integrates SSH with Kerberos (Active Directory, FreeIPA, or MIT Kerberos). Users with valid Kerberos tickets can SSH without typing a password or uploading a key.

Relevant directives:

GSSAPIAuthentication no
GSSAPIKeyExchange no
KerberosAuthentication no

Check effective values:

sshd -T | grep -iE 'gssapi|kerberos'

gssapiauthentication no
gssapikeyexchange no
kerberosauthentication no

Enable GSSAPI only when the host is joined to a realm—join Linux to Active Directory or install FreeIPA—and Kerberos is working (klist shows a valid ticket). Misconfigured Kerberos often produces debug1: No credentials forwarded in ssh -v output while password or key auth still works.

Related hardening setting: PermitRootLogin

PermitRootLogin controls whether root can log in over SSH. It is separate from PasswordAuthentication.

Common hardened value:

PermitRootLogin prohibit-password

This allows root login with keys but blocks root password and keyboard-interactive login for root. To block root SSH completely:

PermitRootLogin no

The upstream sshd_config(5) built-in default is prohibit-password, not yes. Your distribution, cloud image, or local drop-in may override that.

Check the effective value:

sshd -T | grep permitrootlogin

On this test host:

permitrootlogin yes

Your distribution or image may set a different value. Always confirm the effective setting with sshd -T | grep permitrootlogin instead of relying on commented defaults in /etc/ssh/sshd_config.

Apply and verify changes safely

Do not reload sshd until sshd -t is happy.

Edit /etc/ssh/sshd_config or a file under /etc/ssh/sshd_config.d/, then validate:

sudo sshd -t

Reload while keeping your current session open:

sudo systemctl reload ssh

On RHEL and CentOS the service name is usually sshd:

sudo systemctl reload sshd

Open a second terminal and log in before you close the first. ssh -v user@server should show which methods were offered and which one succeeded.

For connection debugging, see test SSH connection. Broader hardening ideas are in prevent brute-force SSH attacks.

Troubleshooting

References

• sshd_config(5) — OpenSSH server configuration
• ssh_config(5) — OpenSSH client configuration
• sshd(8) — OpenSSH daemon
• Ubuntu OpenSSH server guide

Summary

Start from the recipe that matches your goal—key-only, password lab, key plus password, or SFTP Match—then confirm with sshd -T and sshd -t before reload. Turn off both PasswordAuthentication and KbdInteractiveAuthentication when you want no password prompts at all. Keep a second SSH session open while you test, and use Match at the bottom of the file when one group needs different rules.