How to Make SSH Use a Password Instead of a Key

Need to test password-based SSH login, or connect to a host without offering your usual key? You can override the client’s authentication choices for a single connection without changing or deleting any keys.

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no user@host

Replace user and host with the account and server you want to reach. These options apply only to this invocation of ssh.

What the options do

PreferredAuthentications=password tells the client to use the SSH password authentication method. It doesn’t simply move password ahead of public-key authentication; it selects the preferred method list for this connection.

PubkeyAuthentication=no explicitly prevents the client from attempting public-key authentication. With the preferred method already set to password, that second option isn’t strictly required, but it makes the intent clear.

Your key files remain untouched, and other SSH connections are unaffected.

Client preference is not server permission

The command controls what your client tries. The server controls which methods it will accept.

If the server allows only public-key authentication, asking the client to use a password cannot make password login available. The connection may fail with a message such as:

Permission denied (publickey).

That message describes authentication methods the server is still offering during the negotiation. It doesn’t necessarily mean your client ignored the command or tried a key.

Enabling password login is a separate server-side decision. It involves settings such as PasswordAuthentication in the SSH server configuration, and should only be done deliberately. Don’t weaken a server’s authentication policy just to make a client-side test prompt for a password. If you do administer the server and need to change its settings, follow a safe process for editing and applying sshd_config.

Password and keyboard-interactive are different

SSH has separate password and keyboard-interactive authentication methods. On many Linux systems, keyboard-interactive is connected to PAM and can display a prompt that looks like a regular password prompt.

If the server accepts keyboard-interactive rather than the SSH password method, the first command won’t select it. Include both methods in the preference list instead:

ssh -o PreferredAuthentications=keyboard-interactive,password \
    -o PubkeyAuthentication=no user@host

The server still has to offer one of those methods. This command only tells the client which methods to try; it cannot enable either method on the server.

See what the server offers

When there’s no password prompt, use verbose output to inspect the authentication negotiation:

ssh -vvv -o PreferredAuthentications=password \
    -o PubkeyAuthentication=no user@host

Look for lines like these:

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password

The Authentications that can continue line reports methods the server will still accept at that point in the connection. It isn’t a complete display of every server setting. If password isn’t listed, check whether keyboard-interactive is offered instead. The ssh -v output guide explains how to read the diagnostic stages in more detail.

Save the setting for one host

For a host you regularly connect to this way, put the options in a matching block in ~/.ssh/config:

Host password-test
    HostName example.com
    User user
    PreferredAuthentications password
    PubkeyAuthentication no

Then connect with:

ssh password-test

SSH uses the first value it finds for each setting, so place this block above broader matching defaults such as Host *. Command-line options can override values from the client configuration files, which makes the one-off command useful for testing an existing setup.

A couple of common mix-ups

IdentityFile and IdentitiesOnly control which keys are offered when public-key authentication is enabled. They don’t disable public-key authentication. Use PubkeyAuthentication=no when you want to turn that method off for this connection.

And don’t remove or rename your private keys to force a password prompt. A per-connection option is easier to undo and avoids disrupting other hosts that rely on those keys.

The key distinction is simple: your SSH client can choose which authentication methods to try, but only the server can decide which methods it accepts.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.