Explanation: Deciding Whether to Permit the Use of an SSH Connection

The SSH server connection setting specifies if an SSH connection can be used when the console communicates with an endpoint. There are potential security risks when using an SSH connection, so before making a decision, it is important to understand how and when SSH is used within Security Controls.

Background Information

The first thing to know is that Security Controls uses the SMB protocol to communicate with Windows machines and the SSH protocol to communicate with Linux machines. When attempting to discover and communicate with unknown machines, the console will first try SMB; if that fails, SSH is used. SSH provides secure communication between two endpoints. If an endpoint responds to the SSH request, an attempt is made to authenticate to the endpoint using credentials that are provided by the console.

Although SSH provides encrypted transport, any data sent using SSH, including user names and passwords, are visible and available to the SSH server. To ensure the security of data that is sent using an SSH connection, many organizations require that the client validate the authenticity of the remote system it is connecting to before sending any data. Security Controls does not currently support the use of SSH server authentication. This means you must decide whether to block the SSH connections from happening or allow the console to skip the SSH server authentication process.

How to Decide

Your decision on how to configure the SSH server connection setting boils down to whether the machines you are configuring are trusted machines in your network. The setting appears in two places within the Security Controls user interface, and the scope and impact of the setting is different for each area.

In a machine group on the Machine Name, Domain Name, IP Address/Range and Organizational Unit tabs

When performing discovery operations on machines defined in a machine group, you often have no idea what type of machine might be listening on the other end. It is possible that you might know that the machines defined by a certain IP range in your network are trusted Linux machines. For those machines, you might choose to allow the SSH connection by either skipping the authentication process or requiring each machine to undergo a validation step. When adding domains or organizational units to a machine group, however, it is very likely that you are not as certain about the operating system type of the machines or about their trustworthiness. In this case, you should choose to block the SSH connections, The downside, of course, is that you won't be able to manage your Linux machines in the normal manner, but there are workarounds available.

On the Machine Properties dialog

Unlike machines in a machine group that have yet to be discovered, machines in Machine View or Scan View are known to the console. The amount of information about a machine, however, may be limited if the discovery operation was performed while SSH connections were blocked. There may be clues about a machine, such as an address that you recognize as a static IP, that enable you to determine if a machine is a trusted machine. In this situation, you might use the Machine Properties dialog to change the SSH server connection setting from Block to either Validate Against Known Hosts File or Skip Server Authentication. This will enable you to perform a complete power status scan and then a push installation of an agent to the Linux machine.

Summary of Your SSH Server Connection Options

Block: Choose this if:

You don't have any Linux machines in your environment
You have Linux machines, but you are not certain that all SSH servers in your network are trusted and safe
You are uncertain about the OS type of machines that will be discovered

You will not be able to perform a power status scan of the machines or perform a push installation of an agent to the machines. Choosing Block has no effect on listening agent commands or on results being returned to the console.

Validate Against Known Hosts File: Choose this if you want to use the known_hosts file to validate each target machine before allowing an SSH connection. The known_hosts file resides on the console machine and is unique to the user who is currently logged on to the console. The validation process performed by Security Controls is as follows:

An SSH client must be installed on the Security Controls console in order to use this process. You may need to manually download and install an SSH client if your console is on an older version of Windows or Windows Server.

Look for the known_hosts file on the console machine.

The file will be located in the C:\Users\<username>\.ssh path. If the file does not exist, the SSH connection will be blocked.

You can create the known_hosts file by opening a PowerShell prompt on the Security Controls console and manually initiating an SSH connection to the target machine. During the process, the target machine's host key is acknowledged and then added to a newly created known_hosts file.

If the known_hosts file exists and an entry for the target machine is contained in the file, then query the target machine for its SSH key. Security Controls will compare that key with the one in the known_hosts file. If the two keys match, then allow the connection.

The key known by Security Controls is originally created using the user name and password credential that is specified for the machine.

Skip Server Authentication: Choose this only if you are certain that the machines are trusted and safe Linux machines.

Work-Around Solutions if You Choose Blocked

Power status scans

If a Linux machine is in a machine group, the machine will be discovered, but no operating system information will be detected by the scan. If you determine that the machine is a known device in your network and is known to be safe, you can go to the machine Properties dialog to change the SSH server connection setting to either Validate Against Known Hosts File or Skip Server Authentication. Future scans of the machine will complete as expected and will provide full details about the machine.

Installing a Linux Agent

You will not be able to perform a push installation of an agent to a Linux machine if the SSH connection to that machine is blocked. You can, however, manually install an agent on the machine. After that, the agent will function normally, as regular communication with the console does not use an SSH connection.