You might see these errors in both PuTTY and OpenSSH clients when attempting to log in to a Droplet with a password:

[email protected]'s password:
Permission denied (publickey,password).

[email protected]'s password:
Access denied
Server sent disconnect message
type 2 (protocol error):
"Too many authentication failures for root"

This indicates that authentication has failed and can be caused by a number of issues. Here are some steps you can take to troubleshoot this issue:

Permission Denied With Key

This login method uses cryptographic keys to authenticate a user. Learn more about how SSH keys work in SSH Essentials .

When you create a Droplet with SSH keys, SSH keys are the only authentication method supported. You can enable password authentication in the SSH service configuration file once you successfully log in with your SSH key.

You might see an error like this:

Permission denied (publickey).

Disconnected: No supported authentication methods available (server sent: publickey)

Many of the most common issues regarding key-based authentication are caused by incorrect file permissions or ownership. Here are some steps you can take to troubleshoot this issue:

Password Does Not Work In Console

If you cannot recover access to the console, this could indicate issues with the file system used for authentication or configuration issues within the PAM subsystem. This would also impact attempts to reset the root password and log in through the console.

From the console, you’ll see this login prompt:

Ubuntu 14.04.4 LTS server tty1
server Login:
Password:

But when you enter the correct password, you might get this error:

Login incorrect

After a password reset , you’ll receive a prompt like this:

You are required to change your password immediately (root enforced)
Changing password for root.
(Current) UNIX Password:

You must re-enter the current password. If your connection closes immediately, then you may have made a mistake re-entering the current password, so try again.

On success, you are then prompted to enter the new password twice:

Enter new UNIX password:
Retype new UNIX password:

However, if the session restarts after entering the same new password twice (meaning you get sent back to the login prompt), it typically means that there is a problem with one of the critical files managing your authentication data.

You can attempt to log in again using the console after a password reset .

If the problem persists after resetting the Droplet’s password, consider using the recovery environment to prepare your data for re-deployment or attempt to resolve the issues with the PAM configuration or file system.

Solutions

Checking Available Authentication Methods

If you use verbose SSH client output or logging, check that the message outlining authentication methods includes password and/or publickey in the list:

debug1: Authentications that can continue: publickey,password

If the message doesn’t include the authentication method you want to use, take a look at the /etc/ssh/sshd_config configuration file. It’s a common error to accidentally set the PasswordAuthentication value to yes but PermitRootLogin to no or without-password when logging in as root .

Ensure that the appropriate configuration for your login method is set, then restart the service.

Fixing Key Permissions And Ownership

The OpenSSH server and client require strict permissions on the key files used.

Both the host and the client should have the following permissions and owners:

Client environments should additionally have the following permissions and owners:

These changes may need to be made through the Recovery Console .

Checking SSH Public And Private Keys

If you forget which private key matches which public key, OpenSSH tools and the PuTTY suite of applications provide a way to generate a public key from a private key. You can use that to compare the contents of the ~/.ssh/authorized_keys file on your Droplets.

To get a public key from a private key in an OpenSSH environment, use the ssh-keygen command as follows, specifying the path of the private key. By default, it’s ~/.ssh/id_rsa .

ssh-keygen -y -f ~/.ssh/id_rsa

This generates a public key, like this:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCfBiMwCU1xoVVp0VbSYV3gTDV/jB57IHdILQ8kJ2622//Lmi4gDPlxA6HXVKq8odkGD/5MjqUw85X2rwEbhoBul74+LCToYJvvvBaDPCgg5z1icCKIJ1m/LJBrGNqPKCgqFWu0EH4/EFP2XIQqWqX1BZtJu/2YWrTr+xFOE/umoYmOd+t3dzQqMsv/2Aw+WmA/x/B9h+41WrobDgCExYNLPYcD0PO7fpsa8CcrZCo+TUWCe7MgQQCSM6WD4+PuYFpUWGw3ILTT51bOxoUhAo19U8B2QqxbMwZomzL1vIBhbUlbzyP/xgePTUhEXROTiTFx8W9yetDYLkfrQI8Q05+f

In PuTTY environments, the PuTTYgen.exe command loads a GUI where you can use the Load action to import the private key file. In PuTTY, this is normally stored in .ppk format, and you need to know the location of the file.

Once you import the key, the window contains a Public key for pasting into OpenSSH authorized_keys file section with a similar-looking sequence. If you select that text and paste it into a file, it collapses the + characters that it shows, and produce the public key.

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCfBiMwCU1xoVVp0VbSYV3gTDV/jB57IHdILQ8kJ2622//Lmi4gDPlxA6HXVKq8odkGD/5MjqUw85X2rwEbhoBul74+LCToYJvvvBaDPCgg5z1icCKIJ1m/LJBrGNqPKCgqFWu0EH4/EFP2XIQqWqX1BZtJu/2YWrTr+xFOE/umoYmOd+t3dzQqMsv/2Aw+WmA/x/B9h+41WrobDgCExYNLPYcD0PO7fpsa8CcrZCo+TUWCe7MgQQCSM6WD4+PuYFpUWGw3ILTT51bOxoUhAo19U8B2QqxbMwZomzL1vIBhbUlbzyP/xgePTUhEXROTiTFx8W9yetDYLkfrQI8Q05+f imported-openssh-key

You can ignore the comment following the public key (which is imported-openssh-key ) as it may differ from your generated key comment.

In both cases, make sure this public key is included as a line in your ~/.ssh/authorized_keys file on the server, and add it if not.

OpenSSH 7 And Deprecated Key Algorithms

On systems with OpenSSH 7 (FreeBSD and CoreOS, by default), any older DSA-based keys are not supported for authentication. The ssh-dss key is considered weak and using more modern key algorithms is strongly recommended.

Consequently, the best solution is to generate more modern keys and update your existing hosts to allow the new keys. However, as a workaround, you can set the PubkeyAcceptedKeyTypes directive to +ssh-dss in your /etc/ssh/sshd_config file.

Conclusion

For steps on successfully setting up key-based authentication, you can learn how to add SSH keys to Droplets or read SSH Essentials: Working with SSH Servers, Clients, and Keys .

If you need further help, you can open a support ticket . Make sure to include the following information:

Including all the above diagnostic information and clarifying where you are encountering the issue when trying to connect can help us quickly get up to speed with where your need on the issue is.

Related Topics