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 firstname.lastname@example.org
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 export G_FILENAME_ENCODING=UTF-8\
UTF-8 is most likely enabled already. You can check in your terminal by entering the command 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 whatismyipaddress.com.
[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: