How to SSH to your servers
We provide two different ways for you to SSH to your server - an automated way with the Cloud 66 toolbelt, or the manual way.
Cloud 66 toolbelt
You can use the Cloud 66 toolbelt to easily SSH to your servers. Once initialized, the following command can be used:
See toolbelt shortcuts, for information on how you can make this even easier.
Manual shell access
You can always have terminal access to your servers from your own server - just follow the steps below if you’re on a Linux-based operating system.
- Port 22 (SSH) is closed to outside traffic by default - so you need to add a firewall rule to your application to access it.
- Once the port is open, you can find your username and SSH key by visiting the server page for the specific server you would like to login to. The SSH key download link is located in the right sidebar of your server page.
- Change the access rights to the downloaded key to 0600:
- You can now connect to your server with the following command:
$ chmod 0600 /Users/xxx/Downloads/key.pem
$ ssh user_name@ip_address -i /Users/xxx/Downloads/key.pem
- Update your toolbelt version Toolbelt updates are normally applied automatically in the background, but in some cases these may not work. If so, you may need to update the toolbelt manually.
- Toolbelt SSH asking for password If your toolbelt SSH connection is asking for a password, there may be an issue with the local SSH key cache on your computer. To remove this cache, run the following commands: This moves the cached SSH keys to a temporary folder, so that they are downloaded again.
- Toolbelt exits command If the toolbelt SSH connection exits while running, it helps to check the output log from the command. To see this, simply prepend
- Toolbelt exit status 255 You may see this output from the bottom of the previous command:
- SSH timeout SSH connection time-outs typically happen when the firewall connection isn't open. The toolbelt opens the firewall to your current IP address automatically, but your external IP address may change between this request and the actual connection. To verify this, try the manual connection method and see if you can connect.
CXDEBUG=1to your command. For example, you can run: This will show at which point the command fails, and if you run this manually, you should see more error details.
Running Command /usr/bin/ssh with ([<username>@<ip_address> -i /Users/<username>/.ssh/cx_<id>_pkey -o UserKnownHostsFile=/dev/null -o CheckHostIP=no -o StrictHostKeyChecking=no -o LogLevel=QUIET -o IdentitiesOnly=yes -A -p 22]) 2015/04/23 17:41:12 error: exit status 255In this case, there has likely been an issue running the SSH command, though no logs are output from it (given the LogLevel=QUIET directive). We'll want to run that command directly (and switch the LogLevel to VERBOSE):
ssh <username>@<ip_address> -i /Users/<username>/.ssh/cx_<id>_pkey -o UserKnownHostsFile=/dev/null -o CheckHostIP=no -o StrictHostKeyChecking=no -o LogLevel=VERBOSE -o IdentitiesOnly=yes -A -p 22The output from that command should help you understand what the root cause of the issue is.