How To Troubleshoot SSH Authentication Issues On Your Droplet
This is a continuation of our SSH troubleshooting article series.
The first article will help you determine when to troubleshoot an issue instead of migrating or redeploying, and provides resources for the information you'll need to have to troubleshoot effectively. The other parts of this series cover how to identify and resolve specific SSH errors, and are broken down by which phase of a successful SSH connection you need to debug:
- Troubleshooting SSH Connectivity. This deals with errors such as connections being refused or timing out.
- Troubleshooting SSH Protocol Initiation. This includes the client suddenly getting dropped or closed, the client complaining about cipher negotiation, or issues with an unknown or changed remote host.
- Troubleshooting SSH Authentication, which is this tutorial. This includes issues with password authentication or SSH key authentication denial.
- Troubleshooting SSH Shell Environment. This includes issues like being unable to fork a process, the system reporting it's not a valid shell, or issues reaching the home directory.
Once the connection is established and the protocol is initiated to communicate securely, the system can then verify the user connecting to the system. A wide variety of authentication mechanisms are supported. This walkthrough will cover the two most common: password and private/public key pair.
To troubleshoot SSH issues, you will need to make sure your Droplet is responding normally from the web console with a working network configuration. You can do this by following the How and When To Troubleshoot SSH Issues tutorial.
Before troubleshooting SSH, you should always check your cloud panel for ongoing issues in the region impacting your Droplet, the hypervisor status, and the state of the Droplet through the web console.
Below are some common SSH authentication errors you might encounter.
Permission Denied With Password
Note: If you assigned an SSH key when creating your Droplet,
PasswordAuthentication is disabled for your Droplet, and you will need to use your SSH key to login.
You might see these errors in both PuTTY and OpenSSH clients when attempting to log in to a Droplet with a password:
Error email@example.com's password: Permission denied (publickey,password).
PuTTY Error firstname.lastname@example.org'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:
- Make sure you're using the right username. On CoreOS, use the core user. On FreeBSD, use the freebsd user.
- User password authentication might be broken, so check if the Droplet web console supports password login. If it doesn't, you will need to attempt a password reset or request the recovery environment to try to recover access.
- Check that password authentication is allowed by the server.
Permission Denied With Key
This login method uses cryptographic keys to authenticate a user. You can learn more about how SSH keys work in our SSH Essentials tutorial.
This is the only authentication method supported when you create a Droplet using SSH keys. You can enable password authentication in the SSH service configuration file once you successfully login with your SSH key.
You might see an error like this:
Error outputPermission denied (publickey).
PuTTY Error outputDisconnected: 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:
- Make sure the
authorized_keysfile and the private key itself have the correct permissions and ownership.
- Check that key-based authentication is allowed by the server.
- Make sure the private key is readable by the SSH client. If you're using PuTTY, make sure your SSH keys are properly configured for the session. If you're using an OpenSSH client, be sure your private SSH key has the proper permissions.
- Make sure the
authorized_keysfile contains the matching public key. You will want to check that your public key is added to the Droplet.
- You may be using a private key that is no longer supported on the OpenSSH service. This commonly impacts OpenSSH 7+ servers (like our FreeBSD image) when using a private SSH DSA key. You'll need to update the server configuration to allow this key type.
Password Does Not Work In Console
If you are not able to recover access to the console, this could indicate issues with the file system that impact the authentication mechanism or configuration issues within the PAM subsystem. This would also impact attempts to reset the root password for the Droplet and log in through the console.
From the console, you'll see this login prompt:
PromptUbuntu 14.04.4 LTS server tty1 server Login: Password:
But when you enter the correct password, you might get this error:
After a password reset, you'll get this prompt like this:
PromptYou 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 will then be prompted to enter the new password twice:
PromptEnter new UNIX password: Retype new UNIX password:
However, if after entering the same new password twice your session restarts (i.e., you're sent back to the prompt for login again) or you see an error, it typically means that there's a problem with one of the critical files used in managing your authentication data.
In this scenario, you will want to 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.
Below are some troubleshooting methods and solutions to common SSH authentication errors.
Checking Available Authentication Methods
If you use verbose SSH client output or logging, check that the message outlining authentication methods includes
publickey in the list:
Outputdebug1: 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
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:
~./sshpermissions should be
~./sshshould be owned by your account
~/.ssh/authorized_keyspermissions should be
~/.ssh/authorized_keysshould be owned by your account
Client environments should additionally have the following permissions and owners:
~/.ssh/configpermissions should be
~/.ssh/id_*permissions should be
These changes may need to be made through the Droplet web 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-keygen -y -f ~/.ssh/id_rsa
This will generate a public key, like this:
In PuTTY environments, the
PuTTYgen.exe command will load 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 will contain 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 will collapse the
+ characters that it shows, and produce the public key.
Outputssh-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 with OpenSSH 7 (FreeBSD and CoreOS, by default), any older DSA-based keys will not be 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
For steps on successfully setting up key based authentication, the following guides are great references:
- SSH Essentials: Working with SSH Servers, Clients, and Keys
- How To Use SSH Keys with DigitalOcean Droplets
If you need further help authenticating via SSH, you can open a ticket with our Support Team. Make sure to include:
- The username, host, and port you are using to connect
- The authentication mechanism you expect to use
- The full output of the errors linked to the stage of error, including verbose output of the SSH client
- All of the information you've gathered from troubleshooting so far
- Anything you were unclear about while referencing this article
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.