Unix Shell (SSH) Access

This page is showing a generic answer.
To see a more detailed answer customized for you, type your domain name here:

This page is intended for technically advanced users. It describes how you can connect to the command-line Unix shell for your account using SSH.

The Unix shell, or “bash shell”, gives you direct access to the Linux operating system of our servers. While most of our customers will never need to use the shell, advanced customers may need it to install scripts, manipulate databases, etc.

If you need shell access, we assume you basically know what you're doing. Use of the shell is a topic that could (and does) fill many books; however, many sites on the Internet offer tutorials that cover some of the basics, such as LinuxCommand.org.

Keep in mind that the Unix shell is very powerful. If you're not careful, it's easy to damage your website or email. Although you can usually restore your files if you make a mistake, that may not be possible if the file has been changed since the last backup. We recommend making an extra manual backup in our My Account control panel before making changes.

SSH connection instructions

Please enter your domain name in the yellow box above to see detailed instructions.

Do you support telnet?

Like most hosting companies, we no longer support the older, insecure telnet method of connecting to the command-line. You should always use SSH instead.

Why do I get a “too many authentication failures” message without being prompted for a password, or when I send the correct password repeatedly?

This probably means you’ve configured your SSH program to only make connections using keys, but the key isn’t matching, isn’t present on the server, or isn't being sent correctly by your copy of SSH. If you’re using the command line terminal, you can try forcing it to ask for the password with:

ssh \
  -o BatchMode=no \
  -o PreferredAuthentications=password \
  -o PubkeyAuthentication=no \

If you're intentionally using key based login and seeing this error, the issue might be that your local copy of SSH isn't using the correct private key when making a connection. This can happen if you have many keys on your local machine, since SSH will try all of them until it hits a limit for failed login attempts. If it doesn't happen to try the correct one before then, you will see this error. To fix this, you should specify the key to use for our servers in your local ssh configuration file (normally located at ~/.ssh/config) like this:

HostName example.com
  IdentityFile ~/.ssh/<your ssh private key>
  IdentitiesOnly yes

Why do I see an error message saying “REMOTE HOST IDENTIFICATION HAS CHANGED”?

If you’ve previously connected to a different server named “example.com”, or if your SSH software gets upgraded and makes a different type of connection, you may see an error message like this:

Someone could be eavesdropping on you right now
(man-in-the-middle attack)! It is also possible that the
host key has just been changed.
The fingerprint for the key sent by the remote host is

These messages look frightening, but all it’s really saying is that it saw one “fingerprint” the last time you connected to “example.com”, and it’s seeing a different fingerprint now.

You can compare the fingerprint it lists to the fingerprint described earlier on this page to see if it’s a valid fingerprint at our servers. If it is, this is just a glitch, and not harmful; you can remove the bad key by typing:

ssh-keygen -R example.com

If the fingerprint is different, it’s still probably not malicious in most cases — it’s more likely that you’re using a network or firewall that intercepts and modifies connections, or something similar. You’re welcome to contact us with the exact error message and we’ll try to help.

Shell access policy

We provide shell access to our customers so that advanced users can easily configure their websites and send and receive email. Other uses of the servers, including running software unrelated to your account, or running background programs like IRC Bots, "eggdrops", or SETI@home, are not allowed.

Please contact us if you have any questions.