How to SSH to your servers
We provide two different ways for you to SSH to your servers - an automated way with Cloud 66 Toolbelt, or manual way.
Cloud 66 toolbelt
You can use Cloud 66 Toolbelt to easily SSH to your servers. Once you have installed Toolbelt the following command can be used from your terminal:
Full command
cx ssh [--gateway-key <<The path to the key of gateway server>>] [-s "your application name"] "your server name"|<<server ip>>|<<server role>>
Many of these parameters are optional or mutually exclusive. For example you don’t need to provide both the server name and the IP address.
Examples
cx ssh -s "My Awesome App" web
cx ssh --gateway-key ~/.ssh/bastion_key -s "My Awesome App" Lion -e productionSee toolbelt shortcuts, for information on how you can make this even easier.
Manual shell access
You can also access your servers manually via SSH from any Linux-based operating system (including Mac OS X). To do this:
- Add a firewall rule to your application to open port 22 (it is closed to outside traffic by default).
- Find your username and SSH key in the information page for the target server via your Dashboard. Click on the server group to see a list of servers and then on the name of the server you need to reach. The SSH key download link is located in the right-hand panel.
- Change the access rights to the downloaded key to 0600:
$ chmod 0600 /Users/xxx/Downloads/key.pem
- You can now connect to your server with the following command:
$ ssh user_name@ip_address -i /Users/xxx/Downloads/key.pem
Troubleshooting
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:
mkdir ~/.ssh/old_cx
mv ~/.ssh/cx_* ~/.ssh/old_cxThis 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 CXDEBUG=1 to your command. For example, you can run:
CXDEBUG=1 cx ssh -s "My Awesome App" webThis will show at which point the command fails, and if you run this manually, you should see more error details.
Toolbelt exit status 255
You may see this output from the bottom of the previous command:
Running Command /usr/bin/ssh with ([<username>@<ip_address> -i /Users/<username>/.ssh/cx_<id&tt;_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 255
In 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.
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 to see if you can connect.
Check the permissions of your /home and .ssh directories
The SSH utility requires a certain level of permissions to be set in the /home directory of your Linux user before it will work. Those permissions are:
/home/your_usernamemust be set to (at most)755 (drwxr-xr-x)/home/your_username/.sshmust be set to0700 (drwx------)
If these permissions are set too “open” (for example 0777) SSH will refuse to work as it sees this as insecure. Normally these directories are set to the correct permissions by default, but they can be changed by external processes or (unintentionally) by shell commands by team members.
