# How to Troubleshoot SSH Authentication Issues SSH is the primary method available for managing DigitalOcean Droplets. Dealing with SSH errors or failures can be frustrating because the errors themselves often prohibit you from accessing your servers. There are two prerequisites to troubleshooting SSH issues: 1. [**Should I troubleshoot SSH?**](#should-i-ts) Determine whether troubleshooting is the right decision or if migration/redeployment is more appropriate. 2. [**What should I do before troubleshooting SSH?**](#before-ts). Make sure the issue is truly with SSH, then review the information and skills necessary to resolve SSH issues, like having root access to the server and understanding how to access and edit files. ## When to Consider Migration or Redeployment To resolve your issue quickly, first determine whether troubleshooting the connection is the right solution for your problem or if you should instead focus on [recovering your data for redeployment](https://docs.digitalocean.com/products/droplets/how-to/recovery/recovery-iso/index.html.md). Some issues, such as an accidental recursive `rm` or `chmod` command or incorrect network configuration, can lock you out of a Droplet permanently. Other issues may seem like connection problems, but are actually more complex issues with no clear resolution, like corrupted file systems, incorrect file permissions and ownership, and broken system packages and required libraries. You can typically identify boot errors through the Droplet console startup output. File system issues and startup failures that prevent [a working console login session](https://docs.digitalocean.com/products/droplets/how-to/connect-with-console/index.html.md) are signs that troubleshooting your network configuration may not be the better option. In situations like this, the best approach is to salvage what you can. In some cases, a good [backup](https://docs.digitalocean.com/products/backups/index.html.md) or [snapshot](https://docs.digitalocean.com/products/snapshots/index.html.md) strategy is the fastest way back to your previous working environment. ## What to Do Before Troubleshooting If you’ve decided that troubleshooting is right for your situation, go through the following steps: 1. **Check the control panel.** Before anything else, make sure there are no [ongoing issues](https://status.digitalocean.com/), like an outage in the region impacting your Droplet. 2. **Check if Droplet is disabled because of abuse.** Droplets are sometimes disabled due to the detection of abusive activity. If your Droplet has been disabled, an email has been sent to the email address linked to your DigitalOcean account with the title `Networking Disabled: `. You can also log in to the [support portal](https://cloudsupport.digitalocean.com) to see if any support tickets have been created for your resources. If your Droplet has been disabled due to suspected abuse, [contact our support team](https://www.digitalocean.com/support) for further information. 3. **Recover root access.** If you do not have the current root password, reset it using the [reset root password](https://docs.digitalocean.com/support/how-do-i-reset-my-droplets-root-password/index.html.md) function in the control panel. 4. **Access the Recovery Console.** If you cannot log in to the Droplet, [the Recovery Console](https://docs.digitalocean.com/products/droplets/how-to/recovery/recovery-console/index.html.md) is another way to gain access (as long as your Droplet is running and you have a working root password). 5. **Reboot your Droplet.** Many connectivity problems can be resolved after a reboot. If you’re experiencing connectivity issues, try rebooting the Droplet and see if this resolves the issue. Before rebooting your Droplet, [we highly recommend taking a snapshot of it](https://docs.digitalocean.com/products/snapshots/how-to/snapshot-droplets/index.html.md). This allows you to [redeploy your Droplet in its current configuration](https://docs.digitalocean.com/products/snapshots/getting-started/quickstart/index.html.md#create-droplets-and-volumes-from-snapshots) if rebooting the Droplet causes more serious problems. To reboot your Droplet, log in to it and run the following command: ``` sudo reboot ``` 6. **Review file management and permissions.** Some of these solutions may require you to [review or edit files](https://www.digitalocean.com/community/tutorials/basic-linux-navigation-and-file-management) on the system or [manage permissions](https://www.digitalocean.com/community/tutorials/an-introduction-to-linux-permissions). 7. **Check logs.** Once you can get into the Droplet, check the system’s log files for more information to identify the error so you can then look up a solution. You can learn more about the logs on your server with [this Linux logging tutorial](https://www.digitalocean.com/community/tutorials/how-to-view-and-configure-linux-logs-on-ubuntu-and-centos) and [this journalctl and systemd logging tutorial](https://www.digitalocean.com/community/tutorials/how-to-use-journalctl-to-view-and-manipulate-systemd-logs). 8. **Use verbose SSH output.** The level of detail an SSH client provides about the SSH session is generally quiet by default. It’s helpful to have more information when debugging an issue. For the OpenSSH client, you can use the `-v` option with multiple `v` entries to increase the verbosity of the output, as in `ssh -v user@203.0.113.0`. While most issues are revealed with a single `v`, some issues may benefit from `-vvv`. The PuTTY client supports an Event Log accessible from the context icon in the application window bar. There’s also an option for configuring session logging from the settings page when initiating the connection. After you decide to troubleshoot an SSH issue instead of migrating or redeploying, you can identify and resolve specific SSH errors based on which [phase of a successful SSH connection](https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process) you need to debug. Once the SSH 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 walk-through covers the two most common: password and private/public key pair. ## Errors ### Permission Denied With Password **Note**: If you assigned an SSH key when creating your Droplet, `PasswordAuthentication` is disabled for your Droplet and you need to use your SSH key to log in. You might see these errors in both PuTTY and OpenSSH clients when attempting to log in to a Droplet with a password: ``` root@203.0.113.0's password: Permission denied (publickey,password). ``` ``` root@203.0.113.0'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 could be broken, so check if the Recovery Console supports password login. If it doesn’t, [attempt a password reset](https://docs.digitalocean.com/support/how-do-i-reset-my-droplets-root-password/index.html.md) or [focus on recovering your data instead](https://docs.digitalocean.com/products/droplets/how-to/recovery/recovery-iso/index.html.md). - Check that [password authentication is allowed by the server](#checking-available-authentication-methods). ### Permission Denied With Key This login method uses cryptographic keys to authenticate a user. Learn more about how SSH keys work in [SSH Essentials](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys). 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: - Make sure the `authorized_keys` file and the private key itself have [the correct permissions and ownership](#fixing-key-permissions-and-ownership). - Check that [key-based authentication is allowed by the server](#checking-available-authentication-methods). - 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](https://docs.digitalocean.com/products/droplets/how-to/connect-with-ssh/putty/index.html.md). If you’re using an OpenSSH client, be sure your private SSH key [has the proper permissions](#fixing-key-permissions-and-ownership). - Make sure the `authorized_keys` file contains the matching public key. [Check that your public key is added to the Droplet](#checking-ssh-public-and-private-keys). - 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 need to [update the server configuration to allow this key type](#openssh-7-and-deprecated-key-algorithms). ### 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 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](https://docs.digitalocean.com/support/how-do-i-reset-my-droplets-root-password/index.html.md), you 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](https://docs.digitalocean.com/support/how-do-i-reset-my-droplets-root-password/index.html.md). If the problem persists after resetting the Droplet’s password, consider using the recovery environment to [prepare your data for re-deployment](#when-to-consider-migration-or-redeployment) 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: - `~/.ssh` permissions should be `700` - `~/.ssh` should be owned by your account - `~/.ssh/authorized_keys` permissions should be `600` - `~/.ssh/authorized_keys` should be owned by your account Client environments should additionally have the following permissions and owners: - `~/.ssh/config` permissions should be `600` - `~/.ssh/id_*` permissions should be `600` These changes may need to be made through [the Recovery Console](https://docs.digitalocean.com/products/droplets/how-to/recovery/recovery-console/index.html.md). ### 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_ed25519`. ```shell ssh-keygen -y -f ~/.ssh/id_ed25519 ``` This generates a public key, like this: ``` ssh-ed25519 EXAMPLEzaC1lZDI1NTE5AAAAIGKy65/WWrFKeWdpJKJAuLqev9bb9ZNofcMrR/OnC9BM ``` 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. 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](https://docs.digitalocean.com/products/droplets/how-to/add-ssh-keys/index.html.md) or read [SSH Essentials: Working with SSH Servers, Clients, and Keys](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys). If you need further help, you can [open a support ticket](https://cloudsupport.digitalocean.com). Make sure to include the following information: - 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. ## Related Topics [How to Troubleshoot SSH Connectivity Issues](https://docs.digitalocean.com/support/how-to-troubleshoot-ssh-connectivity-issues/index.html.md): Problems with SSH connectivity include hostname resolution errors and connections being refused or timing out. [How to Troubleshoot SSH Protocol Issues](https://docs.digitalocean.com/support/how-to-troubleshoot-ssh-protocol-issues/index.html.md): Problems during SSH protocol initiation include the client suddenly getting dropped or closed, the client returning errors about cipher negotiation, or issues with an unknown or changed remote host. [How to Troubleshoot SSH Shell Environment Issues](https://docs.digitalocean.com/support/how-to-troubleshoot-ssh-shell-environment-issues/index.html.md): Problems with SSH shell environments include being unable to fork a process, the system reporting it’s not a valid shell, or issues reaching the home directory.