Onboard an SSH device to Security Cloud Control using SSH integration and Secure Device Connector. Configure the device connection and credentials to manage it from Security Cloud Control.

Generic SSH refers to the use of the Secure Shell (SSH) protocol as a standard method to securely access and manage network devices remotely. Devices such as Linux servers, Unix-based systems, or third-party network appliances accessible using SSH. It provides encrypted communication, replacing less secure protocols like Telnet. These devices are accessible using SSH that can be onboarded and managed through Security Cloud Control by specifying the device’s IP or FQDN, SSH port, and login credentials.

You can use the username and password of a highly privileged user stored on the SSH device to onboard the device.

Before you begin

Before you begin, make sure you have met these prerequisites:

Ensure that the ciphers your Cisco SSH device supports are supported by Security Cloud Control. At this time, Security Cloud Control supports a limited set of ciphers for onboarding Cisco SSH devices. The supported ciphers are: aes128-ctr, aes192-ctr, aes256-ctr, aes128-gcm, aes128-gcm@openssh.com, aes256-gcm, aes256-gcm@openssh.com. To determine the ciphers your server supports, log in to your SDC and run this command: ssh -vv <ip_address>.
You must have an on-premises Secure Device Connector (SDC) in your network to onboard a Cisco IOS device.

See About for a discussion of SDCs and links to deployment scenarios.
Before you onboard your device, review Connect to Security Cloud Control.

Procedure

In the left pane, click Security Devices.
Click the blue plus button to onboard a device.
Click the Integrations tile. If it is grayed-out, it means you do not have an active Secure Device Connector deployed in your network and used by your Security Cloud Control tenant.
Click the About button and select the SDC in your network that this device will communicate with. The default SDC is displayed but you can change it by clicking the SDC name.
Give the device a name.
In the Integrations drop-down menu, select Generic SSH.
Enter the device's location as either the FDQN or IPv4 address. The default SSH port is 22.
Click Go. Security Cloud Control locates the device and prepares to integrate the configuration.
Download the SSH fingerprint and save locally. If you've never connected to this device through SSH before, this fingerprint allows you to confirm the device.
Enter the Username and Password login credentials for the device you are onboarding. Security Cloud Control cannot successfully read the existing configuration without the correct login information.
(Optional) Enter the Enable Password if you've previously configured one for this device.
(Optional) Select a Configuration Command from the drop-down menu, or enter a custom command in the textbox. This command will be used as the configuration for the device; if OOB is enabled, Security Cloud Control checks for changes and you can view the current value of this in the Configuration page. Note that you can change this command once the device is successfully onboarded to Security Cloud Control.
Click Connect.

Note

If the login credentials were incorrect, you will be prompted to review the connection details. Here you can re-enter the login information. If you exit the review without correcting the credentials, the device has an integration instance in the Security Devices page but the device is not onboarded or synchronized.
(Optional) Add labels to this device.
Click Continue.
The device onboards to Security Cloud Control. Click Finish.
Return to the Security Devices page. After the device has been successfully onboarded, you will see that the Configuration Status is "Synced" and the Connectivity state is "Online."

Note

Once a device is onboarded, you can change the configuration command to be executed. You can use a custom command or create a macro.
(Optional) If you want you can write a note about the device by typing it in the device's notes page.

Need help?

Open a support case

(Requires a Cisco Service Contract)

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.