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 may mean 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 force it to ask for the password (instead of trying a key) with:

ssh \
  -o BatchMode=no \
  -o PreferredAuthentications=password \
  -o PubkeyAuthentication=no \
  example.com@example.com

If that works, and you want your computer to always ask you for a password when connecting to example.com without trying to use a key, you can make this change permanent in your local ssh configuration file (normally located at ~/.ssh/config) like this:

HostName example.com
 BatchMode no
 PreferredAuthentications password
 PubkeyAuthentication no

After doing that, a simple ssh example.com@example.com will always ask for the password.

If instead you’re trying to use key based login but you’re 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 and SSH reaches the limit for failed login attempts before it has a chance to try all of them. To fix this, you can specify the correct key to use 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:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
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
X/t1ww0k8xxfamGqSZMaxZsn6SnwEm6T1KApsA9fKiY.

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, cryptocurrency miners, or SETI@home, are not allowed.

Please contact us if you have any questions.