Troubleshooting SSH

Private key doesn't work

The most common case for a private key not working is that the permissions are set incorrectly on your .ssh directory. In particular, the .ssh directory, as well as your authorized_keys file, must both be set to only be readable by your user. If you're having issues, please try running the following:

[server]$ chmod 700 ~/.ssh
[server]$ chmod 600 ~/.ssh/authorized_keys

Too many failed attempts

If you are receiving the error 'too many failed attempts' when attempting to log into your server via SSH, try adding the -v flag to view the output of the connection. For example:

[server]$ ssh -v

In the output, look for lines with the text 'Trying private key' to view how many keys are being used to connect. Over time it's possible that too many were added to your SSH configuration causing the SSH agent to attempt too many keys before defaulting to Password Authentication. You can view and remove any outdated keys on your computer in the .ssh directory.

No password prompt appears after connecting

If you do not see a password prompt after connecting to the server, make sure your username is configured as a shell user. View the following article for instructions on how to enable shell access on your user:

Directory/filenames which contain non-English/Asian characters show up as ?????? or are corrupt

If you are having problems with your filenames or content not showing up correctly, you can add the following to your .bash_profile file to enable UTF support. View the creating and editing a file via SSH article for instructions on how to edit your existing .bash_profile.

export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8
export LANGUAGE=en_US.UTF-8

UTF-8 is most likely enabled already. You can check in your terminal by entering the command locale:

[server]$ locale 

You can see the first line is LANG=en_US.UTF-8. If for some reason this still doesn’t work, it’s most likely the terminal client you’re using. For instructions on how to configure this in PuTTY please visit the following article:

Server unexpectedly closed network connection

If you get this error when attempting to SSH, this can mean your IP has been blocked. Contact support to see if your IP is blocked. If so, support is able to whitelist it. If you don't know your IP, visit

[User] is not in the sudoers group

DreamHost does not allow regular shell users sudo access on shared servers for security purposes. While many tasks can be accomplished without the use of sudo, if you do need sudo access, you must upgrade to a Dedicated Server and create an admin user.

Idle connections are getting dropped

DreamHost and other ISPs may kill ssh connections that remain idle longer than a certain number of minutes. The fix is simple in Linux or OSX. All you need to do is set up keep-alive by editing the /etc/ssh/ssh_config or ~/.ssh/config file on your computer. In that file, add the following:

  Host *
      ServerAliveInterval 15
      ServerAliveCountMax 4

Now, the ssh client asks the server for a sign of life every 15 seconds, thus keeping the connection open.

For instructions on how to configure this setting in PuTTY, visit the following article:

Operation timed out

If you receive an 'Operation timed out' error when attempting to log into your server via SSH, check for typos in the username or password, keeping in mind that your username and password are case sensitive.

If you are using your domain name instated of the name of the DreamHost server to connect, ensure that your domain’s DNS is pointed to DreamHost. View the following article for instructions on finding the DNS records that your site should point to:

If you continue having issues after going through the troubleshooting steps, please contact support.


Running processes via SSH that consume large quantities of memory and/or processor power may lead them to be "Killed" – see the following article for further information:

See also

Did this article answer your questions?

Article last updated PST.

Still not finding what you're looking for?