Cisco :: Manually Add SSH Public Key’s to FXOS Devices -

Background

In this article, I want to cover the process of adding SSH host key’s to the FXOS chassis’. This process doesn’t seem to be widely documented hence the reason for wanting to capture and share the process.

When configuring SSH on a Firepower chassis, you’re given the ability to configure strict host key checking. If your not aware of what strict host key checking is, let me quickly break it down.

Strict host key checking is a method of enforcing security on public keys by ensuring a public key is stored in the client’s database before allowing secure communication with the client. When an SSH session is initiated from a client (with strict host key checking enabled) to a server, the connection will fail if the servers public key is not already stored within the client’s database.

Strict host key checking is brilliant for enforcing security because of the inability to SSH to any device but as we know, with increased security often comes increased complexity. This means when there is a requirement to set up certain services on an FXOS device such as backup’s, we need to take strict host key checking into account, let me explain why in the use case!

Use Case

If you want to backup FXOS configurations to a backup server, you are required to configure the chassis to send its configurations rather than being able to connect from a server and have the configurations pulled. At the time of writing this article, the following transport methods that can be used are:

FTP – File Transfer Protocol (Port 20/21)
TFTP – Trivial File Transfer Protocol (Port 69)
SCP – Secure Copy Protocol (Port 22)
SFTP – Secure File Transfer Protocol (Port 22)

It makes sense that any organisation serious about security would want to transfer configuration files securely using either SCP or SFTP over the latter two protocols.

You probably see where I’m going with this now! If your trying to backup FXOS configurations using secure protocols while maintaining the upmost security in other areas such as strict host key checking, unless the public key of the backup server is recognised by the chassis, the backup will fail.

Of course, there are two more configuration options that can be used to circumvent having to verify server keys but for the purpose of this article, we’re going to focus on keeping strict host key checking enabled. However, it is worth mentioning all the options available:

Enable: Strict host key checking is enabled and host keys will need to be added manually in order to connect to other hosts using SSH
Prompt: When connecting to a host for the first time you will be prompted to either accept or reject the key. This is good if you have/want manual intervention but where you don’t want manual intervention of having to accept keys this isn’t the most suitable option.
Disable: This is the default method of the chassis. All public keys will automatically be accepted and stored, no prompt will be shown before connecting. This provides no security and isn’t the best way forward for any organisation trying to maintain security.

While some organisations might be happy enough to stick with ‘prompt’, others will require strict security enforcement throughout their infrastructure.

So you might be asking….How can I keep strict host key checking enabled while allowing SSH connections without manual intervention?

Well thankfully with Firepower devices, within the FXOS chassis’ we have the ability to configure and add ssh host key’s manually. Yes, this could be a tedious task depending on how many devices you have and also how many host keys you want to add to each device but at the same time maximum security in this particular area is maintained.

Configuration

This section assumes that the reader already has SSH configured on the chassis and that they wish to add SSH host keys manually.

scope system
scope services
enter ssh-host {ip address}
set key-string

Considerations

Where {ip address} this must be the IP address of the backup server. Take into consideration whether your environment uses NAT or not.

Make sure the host key length is in line with the chassis configurations.

You should find that once you have configured the chassis with the relevant host keys, you should now be able to SSH to those devices from the chassis.

Thank you for reading.