Skip to content

Troubleshoot SSH

The following topic describes the various methods available to resolve common issues that may occur when adding an Agentless node via SSH. For more information on how to add an SSH node, see Network Device Node.

Connection Refused

If the SSH connection was refused, this indicates that you were able to reach the node, but sshd was not running. This could be because sshd is not configured to run automatically, or because it is starting to run and then erroring out. Troubleshooting options include confirming the service is configured to start automatically and reviewing sshd logs. If you are experiencing trouble with your SSH connection, there are some general troubleshooting steps you can take, see below for more information.

Can You SSH into the Machine?

First, confirm that you can SSH into your node from another SSH client with the given connection details. This will confirm whether the node can accept connections, before going on to diagnose network or firewall issues. If you can’t connect to the node from one of your own machines, then you will need to troubleshoot the SSH daemon and/or verify routing and firewall configurations. The steps for this are outside the scope of this topic, but are easily located online.

Can You SSH into the Machine from the Internet? Hosted Only

If you can connect, then you will need to confirm that you can perform the same action from a machine outside of your node’s network. If your node is in a private network behind a company firewall, a desktop or laptop behind a home router, in a virtual machine running with a custom local network, or a node in the cloud with specific network security settings, then you should consider the following issues:

  • Proper port forwarding from externally exposed ports to the port of your node.
  • Allowing connections on SSH port 22 to your node, or through your network device or firewall, but only from the white listed IP address provided.

Connection Could Not Be Established

This error occurs if an initial connection to your node could not be established after attempting for 30 seconds. This situation is similar to the Connection Refused error, but the server or network device that is preventing a connection isn’t deliberately reporting back to us that the connection is being blocked. For more advice on how to solve this problem, see Connection Refused above.

SSH Authentication Failed

If a network connection could be established to your node but the SSH session was disallowed, a common cause of this problem is due to a missing or corrupt Guardian public key entry in the authorized keys file of the user you specified in the connection details. To confirm the correct SSH public key entry exists, log into your node under the user account you specified in the connection details form. Once logged in, you can confirm a Guardian public key entry exists in that user’s authorized keys file by running the following command.

$ grep guardian $HOME/.ssh/authorized_keys

If no SSH record is printed to the command prompt, or if you want to confirm that the entry is correct, you can check against the public key presented in the Guardian web application. To access the public key, complete the following process.

  1. In the Guardian web application, navigate to the Add Nodes tab (Inventory > Add Nodes). The Add Nodes page is displayed.

  2. Search for any SSH-based node type using the search bar.

  3. Select the node and click the Go Agentless button to proceed. The Connect Agentlessly to [Host] page is displayed.

  4. First, select the correct Connection Manager group from the drop-down list.

  5. Then, select the SSH Key radio button to display the SSH key.

CentOS Permissions

If StrictModes is set to 'Yes' in /etc/ssh/sshd_config (the default), then you need to set the following permissions.

$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys

CentOS / SELinux

There is a bug in CentOS 6/SELinux that results in all client presented certificates to be ignored when SELinux is set to 'Enforcing'. To fix this bug, run the following command on the target node.

$ restorecon -R -v /root/.ssh
restorecon reset /root/.ssh context system_u:object_r:ssh_home_t:s0->system_u:object_r:home_ssh_t:s0
restorecon reset /root/.ssh/authorized_keys context unconfined_u:object_r:ssh_home_t:s0->system_u:object_r:home_ssh_t:s0

Hostname Invalid / DNS Lookup Failed

If the hostname you provided could not be resolved to an IP address, there are multiple potential causes for this. Depending on your deployment type, there are two questions you need to answer before proceeding.

Is the Hostname Set Correctly?

First, you need to check whether the node hostname has been set correctly. To check the node's hostname, complete the following process.

  1. In the Guardian web application, navigate to the Monitored tab (Inventory > Monitored).

    Here, a list of all monitored nodes are displayed and categorised by Node Groups.

  2. Select the node that you want to check. Then, click to Edit. The Edit [Node-Name] page is displayed.

  3. Navigate to the Hostname / IP Address field and check that the correct value has been set. If needed, amend the value in the Hostname / IP Address field and click to Update Node.

If the hostname was changed, a confirmation message is displayed. If the node's hostname is set correctly, your instance of Guardian is hosted by Cloudhouse, and you are still unable to resolve the hostname to an IP address, contact helpdesk@cloudhouse.com to speak to a Customer Success Engineer who will help you resolve the issue. For self-hosted instances of Guardian, see below for further remediation solutions.

Is the Hostname Configured Correctly? Hosted Only

For hosted instances of Guardian, the next step is to check that the hostname is not configured as an internal hostname only available to your local network. For instance, to confirm the hostname can be resolved from the Internet, you could run the following command on a machine outside of your local network. The command is to test whether the Guardian website can be resolved.

$ nslookup <you>.cloudhouse.com
...
Address: 50.18.168.209

In the example command above, <you>.cloudhouse.com was successfully resolved to an IP address. If your hostname cannot be resolved to a valid IP address then your output may be more similar to the example below.

$ nslookup nonexistent.cloudhouse.com
...
server can't find nonexistent.cloudhouse.com

One potential solution to this problem is to enter the IP address of the node, rather than the hostname. However, the IP address must be an Internet accessible IP address for it to work. Alternatively, you could add appropriate Internet accessible DNS records for your node. The steps for this are outside the scope of this topic, but many hosting providers provide this functionality.

Error Checks

For Fedora/Centos/RHEL, check the following directory for errors.

/var/log/secure

For Debian-based hosts, check the following directory for errors.

/var/log/auth

Agent-Based Alternative

If adding an Agentless node via SSH is proving difficult with your node, or your security policies do not allow an inbound connection of this type, Cloudhouse offer an alternative method of deploying your node. In this scenario, we recommend that you install an Agent on your node instead. In contrast to SSH mode, which uses inbound connections, the Unix Agent exclusively uses outbound network connections over the common HTTPS port (443). For more information, see Linux Agent.